hardlinkowanie zajmuje dużo miejsca

3

Stworzyłem skrypt przyrostowej kopii zapasowej rsync dla mojego serwera, który skopiuje kopię zapasową bazy danych MySQL i określoną ścieżkę folderu na serwer zdalny. Oto kod na Github.

Fragment kodu z wierszy 53-57:

############### Create most current hand link

echo "Creating most current hard link on backup server $most_recent_backup_link"
ssh $remote_backup_server rm -rf ${most_recent_backup_link}
ssh $remote_backup_server cp -alv ${remote_backup_folder}/backup-${backup_folder_name}/ ${most_recent_backup_link}

Mam problem z tworzeniem najnowszych twardych dowiązań na serwerze kopii zapasowych (wiersze 53-57 w programie). Wszystko działa, a rsync kopiuje tylko około 1-2 MB danych. Ale proces kopiowania twardego łącza wykorzystuje około 30 MB danych. Otrzymuję ogromną listę plików do prania, które nie uległy zmianie, a jedyne, które uległy zmianie, są bardzo małe. Zwykle nie stanowi to problemu, ale podczas tworzenia kopii zapasowej co godzinę kopia zapasowa powinna być jak najmniejsza.

Na przykład podczas ostatniej kopii zapasowej rsync przesłał 1,3 MB. Ale katalog kopii zapasowych zwiększył się o 35 MB.

Dlaczego twarde łącza zajmują tyle miejsca na dysku twardym?

shell shell-script hardlink

— mr_schlomo
źródło

Ile katalogów? Każdy katalog zajmuje pewną ilość miejsca.

Uruchomiłem find -mindepth 1 -type d | wc -li znalazłem, że moja kopia zapasowa ma 1706 wszystkich katalogów.

— mr_schlomo

Może to zająć około 6 MB przy 4KB na katalog, ale na pewno nie 34 MB. Nie jestem pewien, skąd pochodzi równowaga.

1

Może katalogi zawierają wiele plików, więc na dane katalogu potrzeba więcej niż 4 KB?

— Wyzard

1

patrząc na kod (w git hub) wygląda na to, że tworzysz jeden plik .sql.gz na kopię zapasową. nawet jeśli jest tylko 1 lub 2 MB zmian, kopia zapasowa będzie zupełnie nowym plikiem, jeśli chodzi o rsync, więc rozłączy plik, aby utworzyć nowy, ponieważ są one teraz różne.

prawdopodobnie będziesz chciał wykonać kopię zapasową katalogów mysql bezpośrednio (co będzie wymagało zatrzymania mysql podczas wykonywania tej operacji), aby uzyskać pożądaną oszczędność miejsca. Jeśli zejdziesz tą drogą, prawdopodobnie będziesz chciał uruchomić serwer podrzędny, aby wykonać kopię zapasową, w ten sposób baza danych pozostanie bezczynna i tylko serwer podrzędny zostanie zatrzymany podczas tworzenia kopii zapasowej.

— Cwissy
źródło

-2

Powinieneś zajrzeć do storeBackup (storeBackup.org). Tworzy zduplikowane kopie zapasowe za pomocą dowiązań twardych i jest bardzo wydajny.

Ma więcej funkcji niż rsync do tworzenia twardych kopii zapasowych. W przypadku cogodzinnych kopii zapasowych możesz rozważyć opcję storeBackup „lateLinks”, która opóźni utworzenie wszystkich twardych dowiązań. Możesz albo wykonać jedną codzienną kopię zapasową wszystkich twardych łączy. (Lub możesz połączyć wszystkie odroczone kopie zapasowe później, jeśli zdecydujesz się zachować każdą cogodzinną kopię zapasową).

storeBackup posiada również funkcję, która pozwoli ci zdecydować, które kopie zapasowe zachować. Na przykład możesz powiedzieć mu, aby zachowywał wszystkie cogodzinne kopie zapasowe tylko przez ostatnie 24 godziny, i aby wykonywał codzienną kopię zapasową przez ostatnie 30 dni, a także by utrzymywał pierwszą kopię zapasową z miesiąca późniejszego. W ten sposób nie zmarnujesz tyle miejsca.

— MountainX
źródło

To może (ale nie musi) rozwiązać problem PO, ale nie odpowiada na pytanie.

— Keith Thompson

To dosłownie prawda. Jego pytanie brzmiało: „Dlaczego twarde łącza zajmują tyle miejsca na dysku twardym?” i trzymam go, jak mógłby robić kopie zapasowe, które chce robić, a twarde łącza zajmują mniej miejsca. Myślę więc, że podałem potencjalne rozwiązanie, jeśli nie odpowiedź na ściśle dosłowne pytanie.

— MountainX