Od Redakcji: artykuł pochodzi z wrześniowego wydania Linux Magazine. Kompletną listę artykułów możecie znaleźć na stronach miesięcznika.

O ironio! Przygotowując ten właśnie artykuł, straciłem dane z poprzedniego miesiąca. Testowałem wykonywanie kopii zapasowych na serwerze WWW i udało mi się usunąć przez przypadek większość /var/ i cały katalog /home/. Nie byłoby to wielkim problemem gdyby nie fakt, że dzienne kopie bezpieczeństwa przechowywałem w /home/backups/. Ups!

Wykonywanie kopii != kopie zapasowe

Problem zwykle pojawia się w sytuacji, kiedy dane bądź przetwarzające je usługi nie są dostępne. W przypadku mojego serwera WWW brak katalogów /var i /home sprawił, że serwer stał się całkowicie bezużyteczny – jedyne, co w takiej sytuacji mógł serwować, to 404. Jeżeli nie chcemy utracić danych, powinniśmy robić kopie zapasowe. Brzmi to prosto, prawda? W rzeczywistości większość z nas (łącznie ze mną) rozumie to niewłaściwie – choć wykonujemy kopie zapasowe, de facto kopiujemy jedynie dane w inne miejsce, gdzie również możemy je utracić.
Popełniłem klasyczny błąd, polegający na przechowywaniu kopii zapasowych na tym samym systemie, na którym znajdują się dane źródłowe. Co gorsza, trzymałem je w często używanym katalogu – choć w rzeczywistości nie ma to większego znaczenia, bo przy jednym dysku twardym wystarczy pojedyncza awaria, by utracić wszystkie kopie zapasowe, choćby były rozsiane na różnych jego partycjach. Nawet gdybym zamontował w serwerze drugi dysk, jedno zdarzenie (awaria kontrolera, złośliwy włamywacz, pożar, powódź, kradzież) i straciłbym dane ze wszystkich dysków.

Czym naprawdę są kopie zapasowe?

Wykonywanie prawdziwych kopii zapasowych odbywa się w trzech krokach. Przede wszystkim musimy zadbać o to, by dane faktycznie zostały skopiowane. Często spotykam się z sytuacją, kiedy są zapisywane na płycie CD, DVD czy taśmie w niewłaściwy sposób, czego rezultatem są dane praktycznie nie do odzyskania. W idealnej sytuacji powinniśmy sprawdzić każdą wykonywaną kopię zapasową, jeśli jednak jest to niepraktyczne, powinniśmy przynajmniej od czasu do czasu testować różne miejsca, by sprawdzić, czy dane faktycznie można odzyskać.
Druga sprawa: kopie zapasowe powinny znajdować się z dala od danych źródłowych i być tak bardzo „tylko do odczytu”, jak tylko się da. Nie znaczy to, że muszą znajdować się w innym budynku (co zawsze jest dobrym pomysłem), powinny być jednak na tyle odseparowane, by pojedyncza awaria, taka jak sformatowanie macierzy czy utrata serwera, nie spowodowała równocześnie utraty danych głównych i zapasowych. Doskonałym przykładem takiej sytuacji (pomijając oczywiście moje nadmienione wcześniej faux pas) jest niedawna utrata przez AVSIM Online danych gromadzonych przez ostatnie trzynaście lat – z powodu jednego ataku [1].
AVSIM Online miał dwa serwery, między którymi kopiowane były dane – tak wyglądało ich zabezpieczenie. Jak wspomniałem, wielu z nas jedynie kopiuje dane, zamiast wykonywać kopie zapasowe. W tym przypadku atakujący włamał się na oba serwery (były niemal identyczne) i usunął wszystkie znajdujące się na nich dane. AVSIM Online utraciło swoją witrynę, archiwum poczty elektronicznej, fora internetowe itd. – wszystko zniknęło w jednej chwili i najprawdopodobniej nigdy nie wróci. Ja miałem szczęście – usunąłem tylko logi z ostatniego miesiąca, a mogłyby to być na przykład dane finansowe.
Trzecia zasada: zanim zaczniemy usuwać stare kopie zapasowe, by zwolnić miejsce na nowe, musimy być na sto jeden procent pewni, że nigdy nie będziemy potrzebować tych plików. Nie można traktować macierzy RAID z mirroringiem jako rozwiązania problemu kopii zapasowej: nawet jeśli awaria jednego lub kilku dysków nie spowoduje utraty danych, możemy je tak czy inaczej stracić przez zwykłą pomyłkę – na przykład usunięcie plików (rm), wyzerowanie ich bądź napisanie (na przykład mkfs, cat foo > bar itp.).

Jak najdalej

Na szczęście niemal każdy dojrzały system wykonywania kopii zapasowych obsługuje pobieranie danych od klienta i przechowywanie ich w innym miejscu – często na dedykowanym serwerze, macierzy, taśmie, płycie DVD itp. Pod Linuksem mamy do dyspozycji miedzy innymi Amandę [2], którą możemy znaleźć w niemal każdej dystrybucji, jak również BackupPC [3] i Baculę [4], opisywane w poprzednich numerach „Linux Magazine” [5] [6]. Mają one spore możliwości, wiele opcji konfiguracyjnych i naprawdę potrafią zabezpieczyć dane, jeśli wszystko właściwie przygotujemy. Możemy też użyć opcji „na szybko”: rsync (yum install rsync, apt-get install rsync itd.) [7].

Problem z rsyncem

Rsync został zaprojektowany w celu synchronizacji dużych zestawów plików między różnymi katalogami lub serwerami, może więc posłużyć jako najprostsze narzędzie do wykonywania kopii zapasowych lub rozwiązanie pomocnicze. Zwykle do wykonywania kopii lokalnych używam kombinacji tar i mysqldump, umieszczając pliki w katalogu z datownikiem (za chwilę wyjaśnię dlaczego). Z rsynca korzystamy bardzo prosto: wystarczy w katalogu /etc utworzyć plik rsyncd.conf:

uid = backups
gid = backups
use chroot = yes
[backups]
        path = /backups/
        read only = yes

Następnie włączamy rsynca w pliku konfiguracyjnym inetd lub xinetd. Po stronie klienta używamy polecenia takiego jak rsync -a 10.1.2.3::backups/* /mybackups/, które kopiuje zawartość katalogu /backups/ na zdalnym serwerze 10.1.2.3 do lokalnego katalogu /mybackups/. Musimy zadbać o to, by nic naprawdę złego się nie zdarzyło – dlatego nie użyłem opcji –delete, która pozwala rsyncowi usuwać lokalne pliki, nieobecne na hoście zdalnym. Co złego może się wydarzyć? Jeżeli plik zostanie usunięty, nadal będę miał kopię lokalną. Jeśli jednak zostanie on wyzerowany przez atakującego bądź błąd w skrypcie wykonującym kopie (na przykład cat 0 > plik), wtedy kopia lokalna również zostanie wyzerowana. Innymi słowy, możemy łatwo pożegnać się z danymi. Rozwiązaniem jest tworzenie kopii przyrostowych, dlatego też codzienne umieszczam kopie w katalogu, którego nazwą jest dzisiejsza data, a następnie synchronizuję tylko ten katalog:

rsync -a 10.1.2.3::backups/`date +%Y-%m-%d` /my-backups/

Powłoka wykonuje polecenie date +%Y-%m-%d, a następnie wykorzystuje wynik. Oznacza to, że w najgorszym przypadku mogę utracić kopie zapasowe z jednego dnia, nie powinienem jednak stracić starszych, ponieważ znajdują się w oddzielnym katalogu, którego nigdy nie mogę zmodyfikować za pomocą rsynca.

Gdzie są moje kopie?

W tym momencie powinniśmy już mieć kopie zapasowe – skopiowane z serwera w inne miejsce, które powinno być bezpieczne. Ale czy faktycznie kopiowanie się powiodło? Automat może zawieść, adresy IP i nazwy hostów się zmieniają, konfiguracja rsynca jest modyfikowana, na partycji z kopiami zaczyna brakować miejsca itd. Dlatego ostatnim elementem układanki jest sprawdzenie poprawności wykonania kopii zapasowej. Wspomniane wcześniej programy (Amanda, Bacula itd.) obsługują powiadomienia, jak jednak zaimplementować wysyłanie komunikatów o błędzie w skrypt wykorzystujący rsynca? Rozwiązanie jest proste i eleganckie: wystarczy dodać do niego poniższy wiersz:

ls -la /my-backups/`date +%Y-%m-%d` | mail -s "Codzienny raport" nasz@adres.mailowy

To polecenie przesyła nam mailem listing katalogu z kopią zapasową, zawierający nazwy plików wraz z rozmiarami. Jeśli chcemy, możemy też wyświetlać pliki w archiwach za pomocą tar -t. W większości wypadków po uruchomieniu rsynca z opcją -v (tryb „gadatliwy”) powinniśmy ujrzeć wiersze podobne do poniższych:

receiving file list ... done
2009-05-27/
2009-05-27/home.tar.bz2
2009-05-27/etc.tar.bz2

Zwróćmy uwagę, że przy wykonywaniu skryptu z crona rezultat powinien zostać przesłany mailem użytkownikowi, który go uruchomił

Testowanie kopii zapasowych

Niektórzy twierdzą, że ten ostatni krok jest najważniejszy. Najpierw powinniśmy rozpakować archiwa, załadować je z taśmy itd. – wykonać wszystkie kroki potrzebne do odzyskania plików, w przeciwnym bowiem wypadku nigdy nie przekonamy się, czy wszystko działa, jak należy. Warto poświęcić jedną weekendową noc na przeprowadzenie symulacji awarii, połączonej z faktycznym odtwarzaniem kopii zapasowych. Potem będziemy mogli spać spokojnie, wiedząc, że żadna katastrofa (ani administrator-niezdara) nie zagrozi bezpieczeństwu naszych danych.

Zasady bezpieczeństwa
Trzy zasady bezpieczeństwa to: dostępność, integralność i poufność (tzw. triada AIC, od Availability, Integrity, Confidentiality). W skrócie: to co ma działać, musi działać, nie może być zmienione przez atakującego, zaś prywatne dane mogą być dostępne tylko dla odpowiednich osób.

• [1] James Anderson, Avsim.com Hacked – Total Data Loss, „Tech Fragments” 15.05.2009: http://techfragments.com/news/769/Tech/Avsim-com_Hacked_-_Total_Data_Loss.html
• [2] Amanda: http://www.amanda.org/
• [3] BackupPC: http://backuppc.sourceforge.net/
• [4] Bacula: http://www.bacula.org/
• [5] David Nalley, BackupPC, „Linux Magazine” 09(55)/2008, s. 72.
• [6] Jens-Christoph Brendel i Marc Schöchlin, Bacula, „Linux Magazine” 08-09 (19)/2005, s. 73.
• [7] rsync: http://samba.anu.edu.au/rsync/

Autor: Kurt Seifried