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:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
#!/bin/bash # taki skrypt w cronie należy uruchamiać co trzy godziny: # 0 */3 * * * /czarodziejka/backup_home.sh LEVEL=$(( `date +%k` / 3 + `date +%w` * 8 )) # Ustawiamy poziom na (bieżąca godzina/3 + dzień tygodnia*8) # czyli w nocy z niedzieli na poniedziałek tworzymy pełną kopię # i przez resztę tygodnia co trzy godziny inkrementalne TIMESTAMP=`date +%F` FILENAME=`hostname`_home_${TIMESTAMP}_${LEVEL}.lzo # nazwa pliku z backupem # bardzo ważne jest zawarcie numeru poziomu w nazwie # znacznie ułatwi to nam późniejsze odzyskiwanie # dobrym pomysłem jest też użycie np. numeru dnia tygodnia zamiast timestampa lvcreate -s -nhome-snapshot -L10G /dev/vg/home # tworzymy snapshot wolumenu /dev/vg/home # 10GB powinno wystarczyć na zmiany w /home na czas tworzenia backupu mount -o ro /dev/vg/home-snapshot /home-snapshot # stworzyliśmy i zamontowaliśmy w read-only snapshot partycji /home dump -$LEVEL -y -u -f /backup/$FILENAME /home-snapshot # użyte opcje to: # -$LEVEL określa poziom <em>dump</em> # -y kompresuje za pomocą LZO # -u aktualizuje plik /etc/dumpdates po wykonaniu dumpa (WAŻNE!) # -f wskazuje plik docelowy # /home-snapshot to zamontowana partycja którą backupujemy umount /home-snapshot lvremove -f /dev/vg/home-snapshot # odmontowane, snapshot usunięty - posprzątane :) |
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.
0 1 2 3 4 |
umount /home mkfs.ext4 /dev/vg/home mount /home |
Potem należy wejść do katalogu i odtworzyć ostatnią pełną kopię, tą z poziomu 0.
0 1 2 3 4 5 |
cd /home restore rf /backup/czarodziejka_home_2012-12-12_0.lzo # r mówi że odzyskujemy cały system plików # f wskazuje plik źródłowy |
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? :)