Popularnym przekonaniem (szczerze mówiąc – nie mam pojęcia skąd to się wzięło) jest ślepa wiara w konieczność wykonywania kopii TYLKO danych aplikacji lub TYLKO systemu. Tak połowicznie zaprojektowana i wykonana praca może niestety przynieść więcej szkody niż pożytku – wie o tym każdy administrator walczący z niezgodnością odtworzonych danych z zainstalowaną od nowa aplikacją.
Zaprojektujmy więc skromny 3-poziomowy scenariusz Disaster Recovery, będący podstawowym planem backupowym w naszej organizacji w uzupełnieniu do warunków RPO/RTO/Backup Window jakie narzuciliśmy sobie w poprzedniej części. Dla przypomnienia:
RTO – 6h
RPO – 12h
Backup Window – 10:00-14:00, 22:00-02:00
Ilość danych do zabezpieczenia – ok 200GB (100 GB system/aplikacje, 100GB dane – bazy i pliki)
Opis schematu:
Etap I – Baremetal Recovery
Tym mianem określa się zestaw czynności, który pozwoli nam zabezpieczyć całość wskazanego komputera/serwera do poziomu systemu operacyjnego, pozwalających na uruchomienie kolejnego etapu odtwarzania.
W poprzedniej części opisywaliśmy je jako min.: MBR/GPT, tablice partycji, hiden MBR data, wolumen SYSTEM, wolumen Boot, dane systemowe – wszystko co pozwala na komfortowe uruchomienie OS celem dalszej pracy ratunkowej. Zakładamy iż nasze dane zmieniają się stosunkowo rzadko (np. miesięczny lub dłuższy system aktualizacji OS) – wystarczy nam kopia realizowana co 3 miesiące (lub rzadziej). Oczywiście, nic nie stoi na przeszkodzie aby podczas każdego okna serwisowego wykonywać świeży zestaw DR.
Nasz wybrany model powinien pozwolić na odtworzenie dowolnego ze wspomnianych elementów, bez konieczności używania pozostałych (np. tylko MBR, lub tylko wolumen Boot, bez nadpisywania pozostałych). Również, w celu osiągnięcia najbardziej optymalnych parametrów odtwarzania, powinien zezwolić na kompresję jedną z kilku wskazanych metod, podział utworzonego archiwum na wolumeny, generowanie sum kontrolnych, pomijanie przy kompresji plików typu swapfile, partycji wymiany itp.
Na nasze szczęście wszystkie te wymagania spełnia projekt open-source Clonezilla oraz jej serwerowa wersja – DRBL (Diskless Remote Boot Linux).
Etap II – System state
Tym terminem określamy całość danych które należy odtworzyć aby otrzymać system operacyjny wraz z aplikacjami (lub opcjonalnie danymi) z czasu określanego RPO. W założonym przez nas schemacie, dane te są zabezpieczane dwa razy dziennie, o g. 10:00 oraz 22:00.
Odpowiednio w systemach z rodziny Windows SystemState za pomocą wykorzystania usługi VSS (Volume Shadow Copy Service) możemy wykonać wykorzystując dołączone oprogramowanie Backup & Restore lub Windows Server Backup.
Dla systemów z rodziny Linux możemy posiłkować się systemowymi aplikacjami jak: tar, cpio, rsync, archiwizerami: gzip/arj/rar/lha czy też dojrzałymi systemami jak: Amanda, Bacula, fwbackups itp.
Przykładowe użycie tar, pozwalające na zabezpieczenie systemu Linux:
tar -cfzvp nasz_backup.tar.gz –exclude=/nasz_backup.tar.gz –exclude=/proc –exclude=/dev –exclude=/sys –exclude=/mnt –exclude=/media –exclude=/run –exclude=/var/run –exclude=/tmp /
Etap III – Dane aplikacji nie zabezpieczone w etapie I lub II
Przykładowe bazy danych MSSQL/MYSQL/PostgreSQL, wykonywane o g. 11:00 oraz 23:00
mysqldump -u root -pnaszehaslo –all-databases|gzip -v /tmp/all-database.sql.gz
Operacja odtwarzania systemu również przebiega 3-etapowo:
W etapie pierwszym, na wskazanej nowej maszynie, lub czystym wolumenie odtwarzamy dane zabezpieczone za pomocą Etapu I – BM recovery. W praktyce, korzystając z opcji domyślnych (NTFS/ext3/ext4, kompresja pgzip) na obecnej generacji sprzętu jesteśmy w stanie odtwarzać dane z prędkością ok.3-4GB/min. Dla wolumenu 100 GB daje nam to ok 30 minut, po których posiadamy system, wraz z aplikacjami z dnia i godziny wykonania ostatniego Etapu I.
Jeżeli w systemie nie dokonywano żadnych większych zmian (aktualizacje OS, zmiany ustawień, modernizacja aplikacji) w praktyce często możemy przeskoczyć do etapu finalnego – odtwarzanie danych. Jeżeli nie jesteśmy pewni zachowania naszego systemu, wykonajmy odtworzenie etapu II, dopiero po skutecznym zakończeniu przechodzimy do etapu III.
Wstępna kalkulacja:
– próby naprawy, podstawienie nowej maszyny lub dysków – 30 minut
– odtworzenie OS+aplikacji z dnia wykonania etapu I – ok. 30 minut (ok. 100 GB)
– odtworzenie danych z etapu II – w zależności od rozmiaru archiwum – ok 1-2h,
– odtworzenie danych z etapu III – w zależności od rozmiaru archiwum ok. 1-2h,
Przypominając: ilości danych, godziny pracy, dane RPO i RTO są przykładowe. Oznacza to iż powinno się przejrzeć i zmodyfikować powyższy schemat dopasowując go do swojej organizacji. Mam nadzieję iż prezentując powyższy schemat naświetliłem temat i zachęciłem was do eksperymentów.
___
Artykuł powstał dzięki CORE – polskiemu dystrybutorowi antywirusów AVAST i AVG. Zobacz dobry antywirus AVAST Internet Security dla osób oczekujących pełnego bezpieczeństwa online.
