Przyrostowe backupy z dump(8) i LVM

Dump(8) to jedno z najstarszych, niesłusznie niedocenianych wśród linuksiarzy narzędzi do tworzenia kopii zapasowych. Po raz pierwszy pojawiło się w wersji 6 AT&T Unix (1975!) i oryginalnie przeznaczone jest do pracy z taśmami magnetycznymi.

Dump działa na poziomie wewnętrznej struktury systemu plików, więc w odróżnieniu od narzędzi tar(1)  albo cpio(1) jest przeznaczony do konkretnego filesystemu - dobrze nam znanego ext[2-4].  Omija on VFS (interfejs obsługi systemów plików w jądrze) co przekłada się na prędkość działania i generowane obciążenie. Nie modyfikuje atime, faktycznie w żaden sposób nie wpływa na system plików. Warto o tym pamiętać jeżeli mamy do czynienia z uszkodzonym systemem plików i chcemy zrobić kopię danych zanim damy fsck możliwość ostatecznego zniszczenia partycji. Dump z takiego filesystemu jest dużo szybszy i prostszy do wykonania niż np. dd z całej partycji.

Obsługa ext4 została wprowadzona dopiero w wersji 0.4b42. Wcześniejsze wersje przy pracy z ext4 bez cienia zdziwienia tworzą bezużyteczne kopie zapasowe w których pliki są uszkodzone - mimo że struktura katalogów wygląda poprawnie. Bardzo ważne jest upewnienie się że używamy odpowiednich i tych samych wersji zarówno do backupowania, jak i do odzyskiwania danych.

Ponieważ dump bezpośrednio skanuje urządzenie blokowe, nie ma on możliwości reagowania na zmiany w trakcie zrzucania kopii. Kopie pobrane z działającego systemu plików są bezużyteczne. Wcześniejsze strategie obejmowały np. przemontowanie systemu w read-only i zatrzymanie pracy serwera na czas tworzenia kopii - co dla większości z nas jest nieakceptowalne. Można się też pokusić o nadzieję że w trakcie robienia kopii ruch na serwerze będzie na tyle mały że nic się nie stanie, ale jest prostsze rozwiązanie.

O ile mamy i używamy LVM (większość nowoczesnych dystrybucji domyślnie instaluje się używając LVM) możemy zrobić momentalny snapshot filesystemu i w ten sposób wyeliminować kłopotliwy downtime, robiąc kopie zapasowe ze snapshota.

Główną zaletą dump jest jego umiejętność tworzenia inkrementalnych kopii, zapisując w kopii tylko zmienione od ostatniego przebiegu inode'y. Podczas tworzenia kopii wybieramy jej poziom, gdzie poziom 0 to pełna kopia a każdy następny tworzy zrzut zmian od ostatnio wykonanego dump'a niższego poziomu. Wykonanie dump z niższym niż ostatni poziom unieważnia ten wyższy - ta właściwość jest wykorzystywana przy pracy z taśmami by optymalnie wykorzystywać dostępne taśmy i minimalizować czasy odzyskiwania oraz tworzenia kopii.

Dump zapisuje informacje o dacie pobrania kopii i jej poziomie w pliku /etc/dumpdates, a zmiany znajduje opierając się o czas modyfikacji inode. Proces ten jest bardzo szybki i nie obciąża serwera, w odróżnieniu od np. rsync'a który jak opisywał Patryk potrafi doprowadzić do śmierci maszyny, a jego używanie na systemie z dużą ilością katalogów i plików potężnie obciąża procesor, pamięć oraz VFS.

Historyczne podejście do wybierania strategii tworzenia inkrementalnych kopii polega na takim wyborze kolejności poziomów by zużywać stałą ilość taśm. Najczęściej używany algorytm tworzenia kopii jest blisko związany ze słynną Wieżą Hanoi, nie będę go jednak tutaj omawiał - biorąc pod uwagę że większość z nas trzyma kopie zapasowe na dyskach twardych w serwerach, a algorytm ten przydatny jest w przypadku używania taśm magnetycznych. Więcej szczegółów na temat algorytmu Wieży Hanoi i nie tylko można znaleźć na wiki pod hasłem "Backup rotation scheme".

W zamian proponuję prosty schemat z którego sam korzystam - tworzenie pełnych kopii raz w tygodniu i pobieranie kolejnych inkrementalnych kopii w wybranych odstępach czasu. Ponieważ dump jest szybki a kopie nie zajmują wiele miejsca, można je wykonywać często, na przykład co kilka godzin.

Przykładowy skrypt do robienia backupów w systemie tygodniowych snapshotów i inkrementalnych co 3 godziny może wyglądać następująco:

Odzyskiwanie z takiego backupu przebiega w kilku prostych krokach. Po pierwsze należy upewnić się że używamy tych samych wersji narzędzi co na oryginalnej maszynie. Należy rozpocząć od przygotowania partycji - musi ona być czysta, więc najlepiej sformatować ją chwilę przed odtwarzaniem.

Potem należy wejść do katalogu i odtworzyć ostatnią pełną kopię, tą z poziomu 0.

Następnie tym samym poleceniem należy po kolei odtwarzać kolejne dumpy w kolejności ich poziomów. Po skończeniu można usunąć plik restoresymtable w którym restore trzyma informacje o odtwarzanych plikach.

Narzędzia dump i restore pozwalają na o wiele więcej niż jest tutaj opisane, można ich używać np. do zmiany rozmiaru bloku albo odtwarzania pojedynczych plików.

Lektura dokumentacji na pewno nasunie Wam dziesiątki pomysłów, jak można je wykorzystać. A może już jakiejś macie? :)

  • PJ

    http://backup2l.sourceforge.net/
    backup2l - low-maintenance backup/restore tool

    jak dla mnie to narządzie jest idealne do robienia codziennego backupu na dysk, a potem via rsync na następne serwery. W rsyncu można ograniczyć pasmo, co powinno mieć pozytywny wpływ na obciążenie maszyny kosztem wydłużenia czasu synchronizacji

  • s.w.

    a nam każą kupować niesamowicie drogie i zasobożerne narzędzia do backupów znanych i drogich firm...:]
    Jedyny minus jaki mi się nasuwa po przeczytaniu to brak centralnego zarządzania, chociaż i to dałoby się obejść. No ale co klikologia to klikologia, ciężko to wyplenić :D

  • @PJ

    Metoda którą opisałem pozwala sprawnie backupować wolumeny na których bałbyś się uruchamiać rsynca.

    Oprócz tego łapie konsystentny (!) snapshot, z chwili a nie z czasu tarowania.

    I ponieważ lata po blokach to niestraszna jej żadna struktura katalogów :)
    Nie generuje loada (oprócz surowego I/O i kompresji)

    Rsyncowanie dobrze się nadaje do mniejszych rzeczy :)

    pozdr.V

  • MKR

    Ciekawe i pouczające, nie znałem tej metody. Dzięki!