FAQ powstał na bazie paru artykułów i dyskusji na forum.
Zacznijmy od definicji i błędnego przekonania, że NAS to juz BackUp. NAS jest to Dysk Sieciowy (Network Attached Storage) a nie BackUp.
Zatem co to jest Backup?
Kopia bezpieczeństwa (ang. backup copy) – w informatyce dane, które mają służyć do odtworzenia oryginalnych danych w przypadku ich utraty lub uszkodzenia.
10 przykazań BACKUP'u:
Kopie bezpieczeństwa mają ma sens tylko wtedy, kiedy w razie potrzeby łatwo odtworzymy utracone dane.
1. Na kopie tylko to, co potrzebne
Zbędne pliki, takie jak przestarzałe programy czy nieudane zdjęcia sprawiają, że backup trwa długo, a więc sortujmy.
2. Regularność to podstawa
Im krótsze odstępy czasu pomiędzy kopiami, tym mniej danych stracimy w razie awarii. Polecamy backupy automatyczne.
3. Redundancja to nic złego
Oprócz regularnych backupów czasami powinniśmy tworzyć kopie na nośnikach o długim czasie użytkowania np. BD-R.
4. Zachowuj stare wersje
Aby zabezpieczyć się przed nadpisaniem albo skasowaniem plików, musimy mieć dostęp do ich wcześniejszych wersji.
5. Obszerne kopie bezpieczeństwa
Niektóre aplikacje zapisują dane w folderze programu lub w katalogu »Nazwa użytkownika | Dane aplikacji«. Tak się dzieje np. z listami odtwarzania.
6. Przestrzenna separacja kopii
Włamanie lub pożar to zdarzenia losowe, ale nawet wtedy nie musimy tracić cyfrowej kolekcji zdjęć. Przechowujmy więc ich kopię również u przyjaciół.
7. Zabezpieczanie systemu
Instalacja systemu operacyjnego to żmudna praca. Obraz systemu może jej zaoszczędzić w razie awarii dysku.
8. Swobodny dostęp do kopii
Niektóre programy do zabezpieczania danych zapisują pliki w formie kontenerów, które można otworzyć tylko za pomocą oryginalnego narzędzia. Lepsze są kopie danych ze swobodnym dostępem.
9. Prawidłowe składowanie
Nośniki optyczne z kopiami bezpieczeństwa należy przechowywać w miejscach chłodnych i suchych, najlepiej zapakowane w oddzielne pudełka.
10. Sprawne korzystanie z chmury
Zostawiajmy wiadomości na serwerze dostawcy, a programu pocztowego używajmy do tworzenia lokalnych kopii, które zabezpieczamy z innymi danymi.
Od siebie dodam, ze mój Backup nie jest idealny, ale zdaje egzamin:
W tym miejscu chciałbym przytoczyć artykuły Michała Melewskiego, który wymienił (chyba) wszystkie możliwe błędy:
Do znudzenia powtarzać będę, że w całej tej zabawie, którą tutaj opisujemy chodzi o bezpieczeństwo informacji. Właśnie informacji, a nie o bezpieczeństwo komputerów, kabli czy pracowników. Informacje trzeba chronić. Ponieważ w dzisiejszym świecie zagrożeń mamy całkiem sporo, dlatego też wiele jest sposobów ochrony. Bardzo ważnym elementem strategii ochrony danych, jest odpowiednia polityka zarządzania kopiami zapasowymi. Chyba nie ma sensu przekonywać was, że problem istnieje.
W trakcie moich wizyt w różnego rodzaju firmach widziałem naprawdę wiele systemów przeznaczonych do tworzenia kopii zapasowych. Ponieważ są one znacznie powszechniejsze i bardziej istotne (z punktu widzenia firmy, niekoniecznie bezpieczeństwa) niż inne systemy zapewniające bezpieczeństwo, dlatego też ich jakość była wyraźnie lepsza niż systemów Firewall, nie wspominając już o innych mechanizmach bezpieczeństwa. Oczywiści i tutaj nie obeszło się bez błędów. Postaramy się omówić te kilka najważniejszych.
Błąd 0 - niewykonywanie kopii zapasowych
Mam wrażane, że w tym przypadku komentarz jest zbędny. Mawia się, że ludzi dzielimy na dwie kategorie - na takich, którzy wykonują kopie zapasowe, oraz na takich, którzy będą wykonywać kopie zapasowe. Pytanie tylko, w której grupie chcesz się znaleźć.
Błąd 1 - brak strategii wykonywania kopii zapasowych
W firmach świadomość pewnych rzeczy pojawia się zazwyczaj niespodziewanie i w różnych miejscach struktury organizacyjnej. Im wyżej na drabinie decyzyjnej i im gwałtowniej świadomość taka się pojawia, tym gorzej (wiem, to bardzo niesprawiedliwe uogólnienie - ale chodzi tutaj o demonstrację pewnych wzorców). Pewnego dnia, jakiś dyrektor, pomiędzy porannym papierosem i kawą nagle dochodzi do wniosku: O Boże! Przecież my mamy ważne dane. Trzeba je archiwizować. Czasami też zdarza się, że administrator wraca z jakiejś konferencji z wizją tworzenia systemu kopii zapasowych.
O ile same wizje nie są niczym złym, Ba!, są nawet jak najbardziej pożądane, to już sama realizacja takich wizji pozostawia najczęściej wiele do życzenia. Archiwizuje się byle co, byle czym i byle jak. Sprawę systemu tworzenia kopii zapasowych trzeba starannie przemyśleć. Na początek wystarczy stworzyć krótki plan, który zawierać będzie następujące punkty:
1. Jakie dane chcemy archiwizować i dlaczego?
2. W jaki sposób chcemy przeprowadzać archiwizację?
3. Jak często będziemy archiwizować dane?
4. W jaki sposób zamierzamy testować kopie zapasowe?
5. Gdzie zamierzamy przechowywać nośniki z kopiami?
6. Czy chcemy zastosować jakieś inne środki ostrożności?
Stopniowa realizacja tego planu znacznie zwiększa szanse skutecznego wdrożenia.
Błąd 2 - RAID to nie backup
Dość popularnym błędem jest mylenie mechanizmu RAID z tworzeniem kopii zapasowych. Wielokrotnie słyszałem stwierdzenia, że skoro mamy RAID 5, to nie potrzebne są nam już żadne kopie zapasowe. Myślenie to ma jedną zasadniczą wadę - RAID nie chroni nas w żaden sposób przed celowym skasowaniem danych. Jeśli potencjalny napastnik uzyska dostęp do systemu, to po wykasowaniu plików z danymi RAID niewiele nam pomoże, natomiast dane te można będzie odzyskać z kopii zapasowej. Z drugiej jednak strony kopia zapasowa trzymana w sejfie starzeje się - im dłuższy okres od jej wykonania, tym kopia mniej aktualna. W przypadku awarii dysku może okazać się, że straciliśmy dane z ostatnich 12 godzin - często ich odtworzenie może być niemożliwe. Przed takimi sytuacjami chroni nas właśnie mechanizm RAID.
Wniosek jest jeden - mechanizm RAID i system tworzenie kopii zapasowych nie służą do tego, żeby się wzajemnie zastępować, a po to, żeby się uzupełniać.
Błąd 3 - niewłaściwy sposób wykonywania kopii zapasowych
Zacznijmy od anegdotki - miałem kiedyś przyjemność odbywać praktykę (oj dawno dawno) w firmie, w której bazę danych archiwizowano poprzez kopiowanie plików na tzw. "żywca"
. Dopóki system obsługi klientów działał w oparciu bazę MySQL wszystko było w porządku - baza archiwizowana była w godzinach nocnych, w tym czasie nie odbywały się żadne operacje, więc wszystko szło całkiem dobrze. Nawet próbowano odtwarzać dane z takich kopii i próby te zakończyły się sukcesem. W pewnym jednak momencie w firmie pojawiła się też baza PostgreSQL. Niestety, sposób archiwizacji pozostał ten sam. Dramat rozpoczął się pół roku później, kiedy po widowiskowym padzie dysku (brak mechanizmów RAID) zaszła konieczność odtworzenia bazy danych. Niestety okazało się to niemożliwe.
Powyższa opowieść ma wskazać jeden ważny aspekt - zawsze należy odpowiednio dobrać sposób wykonywania kopii zapasowej. Najczęściej najlepszym wyjściem jest archiwizacja na zimno - wyłączamy usługę, kopiujemy dane i ponownie uruchamiamy usługę. Dlaczego sugerowany jest taki sposób? Ponieważ minimalizuje on prawdopodobieństwo uszkodzenia kopiowanych danych przez aplikację, która w danym momencie może pisać do kopiowanego pliku (lub bazy danych). Oczywiście istnieje wiele systemów, których zatrzymanie w zasadzie nie wchodzi w grę. Kopia na gorąco niesie ze sobą jednak pewne ryzyko - jeśli mówimy o bazach danych, to problem ten może zostać rozwiązany poprzez mechanizmy transakcyjności, natomiast jeśli aplikacja operuje na dużej ilości plików, to istnieją pewne rozwiązania, które dbają o to, aby dany plik był otwarty albo przez system backupu, albo przez aplikację. Skuteczność tego rozwiązania niestety jest średnia. Pamiętać też należy o tym, aby jednak przeczytać, co producent danego rozwiązania ma do powiedzenia na temat sugerowanych sposobów wykonywania kopii zapasowych. Twórcy bazy PostgreSQL zalecają użycie polecenia pg_dump, zamiast cp.
Błąd 4 - brak testowania kopii zapasowych
Przytoczę kolejną anegdotkę - w pewnej firmie wdrożono system wykonywania kopii zapasowych. Duże zintegrowane rozwiązanie firmy HP. Każdej nocy wykonywana była kopia systemu SAP (bodajże na taśmy Ultrium), drukarka wypluwała raport, a operator co jakiś czas wymieniał taśmy. Sielanka trwała pół roku, aż doszło do sytuacji, w której zaszła konieczność przywrócenia danych z jednej z kopii. Operator zaczął przeglądać taśmy, tylko po to, aby odkryć, że wszystkie są puste. Oczywiście panika, wzywanie serwisu i obgryzanie paznokci. Serwisant przyjechał, wziął do ręki raport z drukarki i czyta. W raporcie widniał komunikat - Backup failed. Disk write protected.
Nie wiem, na ile opowieść ta jest prawdziwa (tak to zwykle bywa z opowieściami znajomych znajomych), ale dobrze ilustruje pewien problem - nikt tak naprawdę nie weryfikuje poprawności wykonania kopii zapasowych. Obecnie problem jest dużo mniejszy niż kiedyś - zautomatyzowane systemy wykonywania kopii zapasowych dbają o weryfikację poprawności zapisu danych na nośnikach i próbują odtwarzać pewne próbki danych z archiwum celem weryfikacji. To jednak nie rozwiązuje wszystkich problemów. Często trzeba się upewnić, że poprawnie zarchiwizowane dane mogą być użyte w aplikacji, z której zostały pobrane. Przykładem może być opisywany już przeze mnie problem archiwizacji bazy danych.
Błąd 5 - sposób przechowywania kopii zapasowych
Ludzie mają również dość dziwne podejście do nośników zawierających już wykonaną kopię zapasową. O ile same dane chronione są całkiem dobrze, to potem kasetki z kopiami zapasowymi walają się na biurku administratora. Niewiele ma to wspólnego z bezpieczeństwem, prawda? A przecież to dokładnie te same dane.
W przypadku nośników zawierających kluczowe dane firmy powinniśmy uwzględnić trzy kwestie:
Sposób oznaczenia - nośnik zawierający kopie zapasową należy odpowiednio oznaczyć. Szkoda potem czasu, na poszukiwanie danych. Każda płyta lub taśma powinna zawierać informacje określające skąd pochodzą dane (nazwa systemu) oraz datę wykonania kopii. Oczywiście nie namawiam nikogo do pisania flamastrem jak strasznie tajne dane znajdują się na danym nośniku, ale przykładowo zapis tengwarem (dla fanatyków) lub kod kreskowy powinien być niemal niemożliwy do odczytania dla osób postronnych.
Sposób przechowywania - bardzo ważną sprawą jest zapewnienie bezpieczeństwa fizycznego dla nośników kopii zapasowych. W żadnym razie nie należy przechowywać kopii zapasowych w tym samym pomieszczeni, w którym znajdują się serwery zawierające te same dane. Jeśli jednak tak robimy, to weźmy pod uwagę fakt, że po pożarze nie będzie już czego zbierać. Jeśli bardzo zależy nam na bezpieczeństwie danych, to warto przechowywać jeden zestaw kopii w siedzibie, natomiast drugi zestaw poza siedzibą, na przykład w skrytce bankowej. Warto również rozważyć, w przypadku krytycznych danych przechowywanie nośników w sejfie. Sejf taki powinien być również ekranowany, aby zapobiec szkodliwemu wpływowi impulsów elektromagnetycznych.
Sposób transportu - jeśli nasze nośniki zawierające kopie zapasowe opuszczają teren naszej firmy, to należy przyjąć założenie, że mogą one zostać skradzione. Przygotowując się na taką ewentualność należy dane szyfrować. Na rynku dostępne są rozwiązania zapewniające transparentne szyfrowanie archiwizowanych danych. Urządzenia te mają również możliwość odszyfrowania danych po włożeniu specjalnej karty deszyfrującej. Warto również dokładnie przeanalizować sposób transportu omawianych nośników. Nośniki powinny być przenoszone w odpornych na siłowe otwarcie walizkach przez co najmniej dwie osoby. Dane o znacznej wartości powinny być powierzane wyspecjalizowanym firmom konwojującym. W tym temacie wykraczamy jednak znacznie poza zakres tego artykułu. Przypominam też, że warto zadbać o możliwość odszyfrowania zaszyfrowanych danych.
Błąd 6 - brak środowiska do odtwarzania danych
Jeśli nie popełniłeś powyższych 6 błędów, to znakomicie - możesz naprawdę być z siebie dumny. Załóżmy, że zdarzyła się katastrofa i utraciłeś wszystkie dane. Dzięki Bogu przewidziałeś to i masz kopie zapasowe wszystkich danych. Zakładam oczywiście, że masz gdzie je odtworzyć. Nie masz? No to masz problem.
Trzeba zapamiętać, że same dane, bez środowiska do odtwarzania są niewiele warte. Ot, kawałek plastiku i kilkaset kilometrów taśmy. Dla krytycznych systemów warto mieć skonfigurowany system zapasowy, identyczny z systemem produkcyjnym (lub przynajmniej szybką procedurę przerobienia systemu testowego na produkcyjny). Niektóre systemy operacyjne mają możliwość wykonania kopii zapasowej do postaci bootowalnej płyty CD (lub DVD). Przy ewentualnej awarii systemy operacyjnego mamy możliwość szybkiego przywrócenia środowiska do stanu pierwotnego.
Kwestia zapewniania zapasowego sprzętu dla ważniejszych systemów IT wykorzystywanych w firmie wykracza już jednak poza ramy tego artykułu.
Konkluzja
W zasadzie wnioski z tego artykułu każdy powinien wyciągnąć sam, po tym jak zada sobie pytanie czy nie popełnia podobnych błędów.
Przydatne tematy w zasobach forum:
Kawa i herbata - Dane w RAID są bezpieczne? Obalamy mity!
Kawa i herbata - RAID 1 zabezpieczeniem na każdą okazję?
ponadto:
Kawa i herbata - Wybór dysku do serwera QNAP - czym się kierować?
Źródła:
Chip.pl - Komputery: recenzje, opinie, programy, testy
Wikipedia.pl - Wyszukiwarka polskiej Wikipedii
Bezpieczenstwo Informacji (SZBI, ISO 27001), Audyt teleinformatyczny, Ciaglosc dzialania (BS 25999), Ochrona danych osobowych
Mile widzane uwagi do art. by go wzbogacic
Zacznijmy od definicji i błędnego przekonania, że NAS to juz BackUp. NAS jest to Dysk Sieciowy (Network Attached Storage) a nie BackUp.
Zatem co to jest Backup?
Kopia bezpieczeństwa (ang. backup copy) – w informatyce dane, które mają służyć do odtworzenia oryginalnych danych w przypadku ich utraty lub uszkodzenia.
- Kopia bezpieczeństwa to nie to samo co archiwizacja danych. Nie jest to też alternatywa, a uzupełnienie dla redundantnych systemów przechowywania danych w pamięci masowej, np. RAID. Systemy redundantne nie chronią przed przypadkowym nadpisaniem danych, co często się zdarza głównie z winy osoby pracującej na takich danych. Wtedy dobrze jest mieć kopię bezpieczeństwa danych sprzed zmian (zamierzonych lub niezamierzonych).
- Niektóre edytory i procesory tekstu wykonują taką kopię automatycznie, aby umożliwić odtworzenie zawartości pliku w razie awarii komputera lub samego programu, a także aby umożliwić odtworzenie poprzedniej wersji pliku po stwierdzeniu dokonania niepożądanych zmian. W obu przypadkach kopia dokonywana jest automatycznie, w pierwszym wypadku jest wykonywana co pewien czas, a w drugim podczas zapisu. Taka krótkotrwała kopia jest najczęściej automatycznie nadpisywana przy wykonywaniu następnej kopii.
- Mechanizm kopii bezpieczeństwa spotykany jest najczęściej w środowiskach serwerowych, gdzie regularne i automatyczne tworzenie kopii ważnych danych jest podstawowym mechanizmem ochrony tych danych. W zadanych odstępach czasu specjalne oprogramowanie serwera automatycznie tworzy kopie chronionych danych na zewnętrznych nośnikach, np. taśmach magnetycznych, płytach CD/DVD lub zewnętrznych dyskach twardych i RDX Istnieją również specjalistyczne systemy, pozwalające na zdalne wykonywanie kopii bezpieczeństwa, np. przez sieć lokalną lub Internet (kopia bezpieczeństwa online); chronione w ten sposób dane umieszczane są na dyskach serwerów w odległych centrach przetwarzania danych. Taka metoda pozwala skutecznie chronić dane przed większością zdarzeń losowych jak: kradzieże sprzętu, pożary, powodzie, reinstalacja czy ludzki błąd.
- W języku polskim określenia: „backup” i „archiwizacja danych” są (często mylnie) stosowane zamiennie. Jednak w języku angielskim „backup” i „data archiving” określają różne działania. Podobnie w języku polskim kopia bezpieczeństwa i archiwizacja danych. „Backup” dotyczy tworzenia kopii bezpieczeństwa danych w celu ich odtworzenia po utracie lub uszkodzeniu, natomiast „data archiving” oznacza proces tzw. warstwowania danych, czyli ich dzielenia na dane aktywne, nieaktywne i referencyjne, a następnie zapisywania w odpowiednich obszarach zapisu.
- Dostęp do tak podzielonych danych można zróżnicować, np. dane transakcyjne będą miały krótki, a dane historyczne długi czas dostępu, co ma swoje uzasadnienie np. w przypadku prowadzenia działalności gospodarczej.
- Proces archiwizacji danych od kopii bezpieczeństwa odróżnia to, iż dane archiwizowane są przenoszone (np. na inny nośnik), ale przeważnie są nadal dostępne dla użytkowników w postaci referencji do tych danych. W procesie tworzenia kopii bezpieczeństwa dane są kopiowane w inne miejsce i nie są one bezpośrednio dostępne dla użytkowników, ale pierwotne dane nadal pozostają w oryginalnym miejscu.
- Dane zarchiwizowane nadal muszą podlegać procesom kopii bezpieczeństwa. W zależności od tego, czy archiwum jest tworzone jako tylko do odczytu, czy również do zapisu, kopię bezpieczeństwa wykonuje się raz lub z mniejszą częstotliwością niż dla danych niearchiwizowanych.
10 przykazań BACKUP'u:
Kopie bezpieczeństwa mają ma sens tylko wtedy, kiedy w razie potrzeby łatwo odtworzymy utracone dane.
1. Na kopie tylko to, co potrzebne
Zbędne pliki, takie jak przestarzałe programy czy nieudane zdjęcia sprawiają, że backup trwa długo, a więc sortujmy.
2. Regularność to podstawa
Im krótsze odstępy czasu pomiędzy kopiami, tym mniej danych stracimy w razie awarii. Polecamy backupy automatyczne.
3. Redundancja to nic złego
Oprócz regularnych backupów czasami powinniśmy tworzyć kopie na nośnikach o długim czasie użytkowania np. BD-R.
4. Zachowuj stare wersje
Aby zabezpieczyć się przed nadpisaniem albo skasowaniem plików, musimy mieć dostęp do ich wcześniejszych wersji.
5. Obszerne kopie bezpieczeństwa
Niektóre aplikacje zapisują dane w folderze programu lub w katalogu »Nazwa użytkownika | Dane aplikacji«. Tak się dzieje np. z listami odtwarzania.
6. Przestrzenna separacja kopii
Włamanie lub pożar to zdarzenia losowe, ale nawet wtedy nie musimy tracić cyfrowej kolekcji zdjęć. Przechowujmy więc ich kopię również u przyjaciół.
7. Zabezpieczanie systemu
Instalacja systemu operacyjnego to żmudna praca. Obraz systemu może jej zaoszczędzić w razie awarii dysku.
8. Swobodny dostęp do kopii
Niektóre programy do zabezpieczania danych zapisują pliki w formie kontenerów, które można otworzyć tylko za pomocą oryginalnego narzędzia. Lepsze są kopie danych ze swobodnym dostępem.
9. Prawidłowe składowanie
Nośniki optyczne z kopiami bezpieczeństwa należy przechowywać w miejscach chłodnych i suchych, najlepiej zapakowane w oddzielne pudełka.
10. Sprawne korzystanie z chmury
Zostawiajmy wiadomości na serwerze dostawcy, a programu pocztowego używajmy do tworzenia lokalnych kopii, które zabezpieczamy z innymi danymi.
Od siebie dodam, ze mój Backup nie jest idealny, ale zdaje egzamin:
- ważne/wrażliwe dane mam na laptopie a ich kopie na NASie (to nie jest jeszcze backup, a archiwizacja - dlaczego? ponieważ zdarza mi się, skasować to co mam na laptopie, albo poprostu ulega edycji i nie posiada juz kopi "bezpieczeństwa");
- teraz na NAS'ie nr 2 mam backup z NAS'a nr 1 (to już jest backup);
- z NAS'a nr 2 - dane są kopiowane na zewnętrzny dysk (to też już jest backup) przy użyciu stacji dokującej;
- teraz przydałoby się dane trzymać gdzieś indziej - inna lokalizacja geograficzna np. inne mieszkanie/kraj - opcje:
- chmura (google/chomik/co tam chcesz);
- fizyczna kopia w innym miejscu - inny serwer NAS, bądź nośnik np. HDD, DVD, CD, PenDrive, karty SDXC u "cioci" np. w sejfie
- UWAGA !!! Płyty CD/DVD/BluRay te tanie z "marketu" po około 2-3 latach może pojawić się problem z odczytem danych, gdyż są wrażliwe na wilgoć (rośnie czasem grzybek pomiędzy warstwami ) , zadrapania i utlenia się warstwa refleksyjna przez co matowieje;
- Nośniki magnetyczne rozmagnesowują się, jeżeli nie są używane po około 8 latach , dlatego "w dawnych czasach", gdy były powszechnie używane magnetofony szpulowe bądź później kasety magnetofonowe (MC/CC).
- UWAGA !!! Płyty CD/DVD/BluRay te tanie z "marketu" po około 2-3 latach może pojawić się problem z odczytem danych, gdyż są wrażliwe na wilgoć (rośnie czasem grzybek pomiędzy warstwami
W tym miejscu chciałbym przytoczyć artykuły Michała Melewskiego, który wymienił (chyba) wszystkie możliwe błędy:
Do znudzenia powtarzać będę, że w całej tej zabawie, którą tutaj opisujemy chodzi o bezpieczeństwo informacji. Właśnie informacji, a nie o bezpieczeństwo komputerów, kabli czy pracowników. Informacje trzeba chronić. Ponieważ w dzisiejszym świecie zagrożeń mamy całkiem sporo, dlatego też wiele jest sposobów ochrony. Bardzo ważnym elementem strategii ochrony danych, jest odpowiednia polityka zarządzania kopiami zapasowymi. Chyba nie ma sensu przekonywać was, że problem istnieje.
W trakcie moich wizyt w różnego rodzaju firmach widziałem naprawdę wiele systemów przeznaczonych do tworzenia kopii zapasowych. Ponieważ są one znacznie powszechniejsze i bardziej istotne (z punktu widzenia firmy, niekoniecznie bezpieczeństwa) niż inne systemy zapewniające bezpieczeństwo, dlatego też ich jakość była wyraźnie lepsza niż systemów Firewall, nie wspominając już o innych mechanizmach bezpieczeństwa. Oczywiści i tutaj nie obeszło się bez błędów. Postaramy się omówić te kilka najważniejszych.
Błąd 0 - niewykonywanie kopii zapasowych
Mam wrażane, że w tym przypadku komentarz jest zbędny. Mawia się, że ludzi dzielimy na dwie kategorie - na takich, którzy wykonują kopie zapasowe, oraz na takich, którzy będą wykonywać kopie zapasowe. Pytanie tylko, w której grupie chcesz się znaleźć.
Błąd 1 - brak strategii wykonywania kopii zapasowych
W firmach świadomość pewnych rzeczy pojawia się zazwyczaj niespodziewanie i w różnych miejscach struktury organizacyjnej. Im wyżej na drabinie decyzyjnej i im gwałtowniej świadomość taka się pojawia, tym gorzej (wiem, to bardzo niesprawiedliwe uogólnienie - ale chodzi tutaj o demonstrację pewnych wzorców). Pewnego dnia, jakiś dyrektor, pomiędzy porannym papierosem i kawą nagle dochodzi do wniosku: O Boże! Przecież my mamy ważne dane. Trzeba je archiwizować. Czasami też zdarza się, że administrator wraca z jakiejś konferencji z wizją tworzenia systemu kopii zapasowych.
O ile same wizje nie są niczym złym, Ba!, są nawet jak najbardziej pożądane, to już sama realizacja takich wizji pozostawia najczęściej wiele do życzenia. Archiwizuje się byle co, byle czym i byle jak. Sprawę systemu tworzenia kopii zapasowych trzeba starannie przemyśleć. Na początek wystarczy stworzyć krótki plan, który zawierać będzie następujące punkty:
1. Jakie dane chcemy archiwizować i dlaczego?
2. W jaki sposób chcemy przeprowadzać archiwizację?
3. Jak często będziemy archiwizować dane?
4. W jaki sposób zamierzamy testować kopie zapasowe?
5. Gdzie zamierzamy przechowywać nośniki z kopiami?
6. Czy chcemy zastosować jakieś inne środki ostrożności?
Stopniowa realizacja tego planu znacznie zwiększa szanse skutecznego wdrożenia.
Błąd 2 - RAID to nie backup
Dość popularnym błędem jest mylenie mechanizmu RAID z tworzeniem kopii zapasowych. Wielokrotnie słyszałem stwierdzenia, że skoro mamy RAID 5, to nie potrzebne są nam już żadne kopie zapasowe. Myślenie to ma jedną zasadniczą wadę - RAID nie chroni nas w żaden sposób przed celowym skasowaniem danych. Jeśli potencjalny napastnik uzyska dostęp do systemu, to po wykasowaniu plików z danymi RAID niewiele nam pomoże, natomiast dane te można będzie odzyskać z kopii zapasowej. Z drugiej jednak strony kopia zapasowa trzymana w sejfie starzeje się - im dłuższy okres od jej wykonania, tym kopia mniej aktualna. W przypadku awarii dysku może okazać się, że straciliśmy dane z ostatnich 12 godzin - często ich odtworzenie może być niemożliwe. Przed takimi sytuacjami chroni nas właśnie mechanizm RAID.
Wniosek jest jeden - mechanizm RAID i system tworzenie kopii zapasowych nie służą do tego, żeby się wzajemnie zastępować, a po to, żeby się uzupełniać.
Błąd 3 - niewłaściwy sposób wykonywania kopii zapasowych
Zacznijmy od anegdotki - miałem kiedyś przyjemność odbywać praktykę (oj dawno dawno) w firmie, w której bazę danych archiwizowano poprzez kopiowanie plików na tzw. "żywca"
. Dopóki system obsługi klientów działał w oparciu bazę MySQL wszystko było w porządku - baza archiwizowana była w godzinach nocnych, w tym czasie nie odbywały się żadne operacje, więc wszystko szło całkiem dobrze. Nawet próbowano odtwarzać dane z takich kopii i próby te zakończyły się sukcesem. W pewnym jednak momencie w firmie pojawiła się też baza PostgreSQL. Niestety, sposób archiwizacji pozostał ten sam. Dramat rozpoczął się pół roku później, kiedy po widowiskowym padzie dysku (brak mechanizmów RAID) zaszła konieczność odtworzenia bazy danych. Niestety okazało się to niemożliwe.Powyższa opowieść ma wskazać jeden ważny aspekt - zawsze należy odpowiednio dobrać sposób wykonywania kopii zapasowej. Najczęściej najlepszym wyjściem jest archiwizacja na zimno - wyłączamy usługę, kopiujemy dane i ponownie uruchamiamy usługę. Dlaczego sugerowany jest taki sposób? Ponieważ minimalizuje on prawdopodobieństwo uszkodzenia kopiowanych danych przez aplikację, która w danym momencie może pisać do kopiowanego pliku (lub bazy danych). Oczywiście istnieje wiele systemów, których zatrzymanie w zasadzie nie wchodzi w grę. Kopia na gorąco niesie ze sobą jednak pewne ryzyko - jeśli mówimy o bazach danych, to problem ten może zostać rozwiązany poprzez mechanizmy transakcyjności, natomiast jeśli aplikacja operuje na dużej ilości plików, to istnieją pewne rozwiązania, które dbają o to, aby dany plik był otwarty albo przez system backupu, albo przez aplikację. Skuteczność tego rozwiązania niestety jest średnia. Pamiętać też należy o tym, aby jednak przeczytać, co producent danego rozwiązania ma do powiedzenia na temat sugerowanych sposobów wykonywania kopii zapasowych. Twórcy bazy PostgreSQL zalecają użycie polecenia pg_dump, zamiast cp.
Błąd 4 - brak testowania kopii zapasowych
Przytoczę kolejną anegdotkę - w pewnej firmie wdrożono system wykonywania kopii zapasowych. Duże zintegrowane rozwiązanie firmy HP. Każdej nocy wykonywana była kopia systemu SAP (bodajże na taśmy Ultrium), drukarka wypluwała raport, a operator co jakiś czas wymieniał taśmy. Sielanka trwała pół roku, aż doszło do sytuacji, w której zaszła konieczność przywrócenia danych z jednej z kopii. Operator zaczął przeglądać taśmy, tylko po to, aby odkryć, że wszystkie są puste. Oczywiście panika, wzywanie serwisu i obgryzanie paznokci. Serwisant przyjechał, wziął do ręki raport z drukarki i czyta. W raporcie widniał komunikat - Backup failed. Disk write protected.
Nie wiem, na ile opowieść ta jest prawdziwa (tak to zwykle bywa z opowieściami znajomych znajomych), ale dobrze ilustruje pewien problem - nikt tak naprawdę nie weryfikuje poprawności wykonania kopii zapasowych. Obecnie problem jest dużo mniejszy niż kiedyś - zautomatyzowane systemy wykonywania kopii zapasowych dbają o weryfikację poprawności zapisu danych na nośnikach i próbują odtwarzać pewne próbki danych z archiwum celem weryfikacji. To jednak nie rozwiązuje wszystkich problemów. Często trzeba się upewnić, że poprawnie zarchiwizowane dane mogą być użyte w aplikacji, z której zostały pobrane. Przykładem może być opisywany już przeze mnie problem archiwizacji bazy danych.
Błąd 5 - sposób przechowywania kopii zapasowych
Ludzie mają również dość dziwne podejście do nośników zawierających już wykonaną kopię zapasową. O ile same dane chronione są całkiem dobrze, to potem kasetki z kopiami zapasowymi walają się na biurku administratora. Niewiele ma to wspólnego z bezpieczeństwem, prawda? A przecież to dokładnie te same dane.
W przypadku nośników zawierających kluczowe dane firmy powinniśmy uwzględnić trzy kwestie:
Sposób oznaczenia - nośnik zawierający kopie zapasową należy odpowiednio oznaczyć. Szkoda potem czasu, na poszukiwanie danych. Każda płyta lub taśma powinna zawierać informacje określające skąd pochodzą dane (nazwa systemu) oraz datę wykonania kopii. Oczywiście nie namawiam nikogo do pisania flamastrem jak strasznie tajne dane znajdują się na danym nośniku, ale przykładowo zapis tengwarem (dla fanatyków) lub kod kreskowy powinien być niemal niemożliwy do odczytania dla osób postronnych.
Sposób przechowywania - bardzo ważną sprawą jest zapewnienie bezpieczeństwa fizycznego dla nośników kopii zapasowych. W żadnym razie nie należy przechowywać kopii zapasowych w tym samym pomieszczeni, w którym znajdują się serwery zawierające te same dane. Jeśli jednak tak robimy, to weźmy pod uwagę fakt, że po pożarze nie będzie już czego zbierać. Jeśli bardzo zależy nam na bezpieczeństwie danych, to warto przechowywać jeden zestaw kopii w siedzibie, natomiast drugi zestaw poza siedzibą, na przykład w skrytce bankowej. Warto również rozważyć, w przypadku krytycznych danych przechowywanie nośników w sejfie. Sejf taki powinien być również ekranowany, aby zapobiec szkodliwemu wpływowi impulsów elektromagnetycznych.
Sposób transportu - jeśli nasze nośniki zawierające kopie zapasowe opuszczają teren naszej firmy, to należy przyjąć założenie, że mogą one zostać skradzione. Przygotowując się na taką ewentualność należy dane szyfrować. Na rynku dostępne są rozwiązania zapewniające transparentne szyfrowanie archiwizowanych danych. Urządzenia te mają również możliwość odszyfrowania danych po włożeniu specjalnej karty deszyfrującej. Warto również dokładnie przeanalizować sposób transportu omawianych nośników. Nośniki powinny być przenoszone w odpornych na siłowe otwarcie walizkach przez co najmniej dwie osoby. Dane o znacznej wartości powinny być powierzane wyspecjalizowanym firmom konwojującym. W tym temacie wykraczamy jednak znacznie poza zakres tego artykułu. Przypominam też, że warto zadbać o możliwość odszyfrowania zaszyfrowanych danych.
Błąd 6 - brak środowiska do odtwarzania danych
Jeśli nie popełniłeś powyższych 6 błędów, to znakomicie - możesz naprawdę być z siebie dumny. Załóżmy, że zdarzyła się katastrofa i utraciłeś wszystkie dane. Dzięki Bogu przewidziałeś to i masz kopie zapasowe wszystkich danych. Zakładam oczywiście, że masz gdzie je odtworzyć. Nie masz? No to masz problem.
Trzeba zapamiętać, że same dane, bez środowiska do odtwarzania są niewiele warte. Ot, kawałek plastiku i kilkaset kilometrów taśmy. Dla krytycznych systemów warto mieć skonfigurowany system zapasowy, identyczny z systemem produkcyjnym (lub przynajmniej szybką procedurę przerobienia systemu testowego na produkcyjny). Niektóre systemy operacyjne mają możliwość wykonania kopii zapasowej do postaci bootowalnej płyty CD (lub DVD). Przy ewentualnej awarii systemy operacyjnego mamy możliwość szybkiego przywrócenia środowiska do stanu pierwotnego.
Kwestia zapewniania zapasowego sprzętu dla ważniejszych systemów IT wykorzystywanych w firmie wykracza już jednak poza ramy tego artykułu.
Konkluzja
W zasadzie wnioski z tego artykułu każdy powinien wyciągnąć sam, po tym jak zada sobie pytanie czy nie popełnia podobnych błędów.
Przydatne tematy w zasobach forum:
Kawa i herbata - Dane w RAID są bezpieczne? Obalamy mity!
Kawa i herbata - RAID 1 zabezpieczeniem na każdą okazję?
ponadto:
Kawa i herbata - Wybór dysku do serwera QNAP - czym się kierować?
Źródła:
Chip.pl - Komputery: recenzje, opinie, programy, testy
Wikipedia.pl - Wyszukiwarka polskiej Wikipedii
Bezpieczenstwo Informacji (SZBI, ISO 27001), Audyt teleinformatyczny, Ciaglosc dzialania (BS 25999), Ochrona danych osobowych
Mile widzane uwagi do art. by go wzbogacic
