Co może pójść nie tak? Wszystko! Od zaszyfrowania środowiska IT przez hackerów z żądaniem okupu, po pożar w serwerowni, błąd oprogramowania czy zawalenie się budynku. Niemożliwe? Świat IT dzieli ludzi na tych, którzy już “umieją” w backup i tych, którzy zmienią podejście, gdy staną przed koniecznością reinstalacji systemów. Wyjaśniamy jak backup, snapshot i replikacja danych mogą uchronić przed potrzebą reinstalacji systemu.
O tym jak ważny jest backup wielu administratorów uświadamia sobie niestety dopiero w momencie awarii, gdy backupu nie ma lub jest on niemożliwy do odtworzenia. Samo wykonywanie backupu to dopiero początek przygody z poprawnym zabezpieczaniem danych na wypadek awarii. A jej przyczyn może być wiele: od błędu ludzkiego (pomyłka użytkownika), awarii sprzętowej, katastrofy naturalnej, budowlanej, po akty terroryzmu czy atak złośliwego oprogramowania.
Problem zapewnienia odpowiedniego poziomu bezpieczeństwa danych w firmach jest powszechny. Według badania KPMG w 2022 roku aż 58 proc. firm w Polsce odnotowało przynajmniej jeden incydent polegający na naruszeniu bezpieczeństwa, 33 proc. zauważyło wzrost intensywności prób cyberataków, a 20 proc. badanych organizacji stwierdziło wzmożoną aktywność cyberprzestępców w związku trwającą wojną w Ukrainie. Blisko jedna trzecia firm wskazała, że padła w przeszłości ofiarą ataku ransomware. Patrząc na te statystyki raczej nie należy zakładać, że “może nic się nie stanie”, tylko “kiedy coś się stanie” i czy jesteśmy na taką sytuację przygotowani.
Backup, czyli kopia zapasowa danych
Backup to inaczej kopia zapasowa danych, zwana też kopią bezpieczeństwa. Wykonuje się ją w celu zabezpieczenia przed utratą istotnych dla organizacji danych. Kopia ta powinna być odseparowana od podstawowego środowiska IT (tzn. backup powinien być przechowywany w miarę możliwości poza miejscem przetwarzania danych produkcyjnych). Dobrze skonfigurowana usługa backupu pozwala założyć, że w razie awarii da się sprawnie przywrócić środowisko, z minimalną lub bliską zeru utratą danych. Backup tworzy kopie kluczowych komponentów środowiska IT i składowanych danych. Jego zaletą jest całościowe zabezpieczenie aplikacji oraz danych, wadą może być rozmiar danych w przypadku pełnych kopii (full backup) lub czas odtwarzania w przypadku kopii przyrostowych.
Innym podejściem do zabezpieczenia danych jest snapshot (migawka), czyli zamrożony stan dysków maszyny wirtualnej w danej chwili jej pracy (włącznie ze stanem aktualnie uruchomionych aplikacji). Migawka może pomóc przywrócić jeden z ostatnich stanów w razie awarii, ale posiada też swoje ograniczenia. Przykładowo nie poradzi sobie z odtworzeniem baz danych; zazwyczaj liczba przechowywanych migawek na jednym obiekcie jest ograniczona przez wirtualizator i obniża wydajność maszyny wirtualnej. W przypadku backupu takie ograniczenia nie występują. Ponieważ snapshot nie jest kopią danych, nie może być uważany za jedyny sposób na zabezpieczenie danych i powinien być używany w połączeniu z backupem.
Kolejna metoda to synchronizacja danych, czyli przesłanie tylko zmodyfikowanej części środowiska do miejsca replikacji. Przeważnie zachowywana jest tylko ostatnia modyfikacja, a to oznacza, że w przypadku zaszyfrowania podstawowego środowiska, do miejsca replikacji o zadanym czasie również trafi zaszyfrowana wersja, a powrót do wcześniejszej nie będzie niestety możliwy.
Aby dobrze zabezpieczyć środowisko IT przed awariami, trzeba dobrze zrozumieć poszczególne metody, występujące między nimi różnice i to, jak odpowiednio ich używać. Backup umożliwia odtworzenie danych w przypadku ich utraty (skasowanie, atak ransomware) bądź awarii (np. sprzętowe uszkodzenie dysku). Snapshot zapewnia jedynie dostęp do starszej wersji danych z momentu jego utworzenia. Natomiast replikacja pozwala na przechowywanie tej samej wersji danych w wielu miejscach (np. u różnych dostawców chmur publicznych albo u jednego dostawcy, ale w różnych regionach). Jeżeli plik zostanie przypadkowo skasowany przez użytkownika bądź celowo zaszyfrowany przez przestępców, zmiana ta zostanie zapisana we wszystkich miejscach docelowych replikacji. W takiej sytuacji dane będą bezużyteczne - we wszystkich lokalizacjach będą znajdować się zmienione dane, bez możliwości przywrócenia poprawnej wersji. Analogicznie sytuacja wygląda przy składowaniu danych na dyskach skonfigurowanych jako lustrzane odbicie (RAID 1). Różnice te pokazują, jak istotną kwestią jest regularne tworzenie kopii zapasowych danych.
RPO i RTO
Tworząc plany backupu warto znać dwie ważne definicje:
- RPO (ang. Recovery Point Objective) - maksymalny czas utraty danych od utworzenia backupu do wystąpienia awarii; inaczej mówiąc RPO określa, jak często robimy kopię zapasową (np. co godzinę, 6 godzin, 24 godziny).
- RTO (ang. Recovery Time Objective) - określa w jakim czasie dane muszą zostać odtworzone z kopii bezpieczeństwa, aby przywrócić funkcjonalność systemu po awarii.
Czasy RPO i RTO muszą być odpowiednio dobrane do charakteru organizacji. Inne potrzeby ma firma, która działa tylko w biurze, inne firma produkcyjna czy sieć handlowa prowadząca tysiące placówek, a jeszcze inne organizacje działające w trybie ciągłym, takie jak elektrownia, szpital czy infrastruktura krytyczna państwa.
Zasada 3-2-1
Samo wdrożenie backupu w organizacji to krok w dobrym kierunku, ale trzeba wiedzieć, w jaki sposób przeprowadzić ten proces. Co z tego, że firma posiada backup, jeżeli zostanie on zaszyfrowany przez przestępców razem z całością środowiska IT? Backup serwera, który razem z podstawowym serwerem ulegnie zniszczeniu w wyniku awarii centrum danych (np. w wyniku katastrof takich jak powódź czy pożar), również na niewiele się zda.
Aby uchronić organizacje przed takimi sytuacjami powstała złota, choć niełatwa do osiągnięcia, zasada przechowywania danych kopii zapasowych: "Zasada 3-2-1". Opisuje ona sposób składowania danych czyli:
3 - przechowuj trzy kopie danych
Poza podstawowym źródłem danych należy mieć trzy kopie, które uratują nas w razie kłopotów. Pierwsza kopia to kopia podstawowa. Jest tworzona często i łatwo dostępna, pozwala np. szybko przywrócić stan sprzed wprowadzeniem zmian w przypadku błędu użytkownika. Druga kopia (dodatkowa) - tworzona zaraz po podstawowej kopii, może być trudniej dostępna, np. składowana w drugim centrum danych lub na taśmach. Trzecia kopia to rzadziej wykonywany (np. raz w tygodniu / raz w miesiącu) backup na naprawdę “ciężkie czasy”. Koniecznie powinna znajdować się poza siedzibą firmy. Pozwala uratować dane w przypadku bardzo poważnej awarii czy fizycznego uszkodzenia infrastruktury.
2 - dane przechowuj na dwóch różnych nośnikach danych
Jeżeli korzystasz z backupu w chmurze, umieść kopie danych u dwóch różnych dostawców usług. Jeżeli korzystasz np. z dysku NAS, dodatkową kopię umieść na innym rodzaju nośnika lub w chmurze obliczeniowej. Każda, nawet najbardziej niezawodna technologia, powinna być zabezpieczona przez inną, niezależną od niej. Nieprzypadkowo w lotnictwie kluczowe dla działania samolotów systemy są co najmniej zdublowane.
1 - kopia offsite, czyli przechowywana poza siedzibą firmy
Niestety ta zasada często jest ignorowana. Wystarczy pęknięta rura w pomieszczeniu, w którym znajduje się serwerownia albo awaria systemu chłodzenia, która doprowadzi do przegrzania urządzeń, żeby doprowadzić do całkowitej utraty danych. Backup? Często “Był, ale w tym samym pomieszczeniu.” W Polsce podczas powodzi tysiąclecia w 1997 r. na kilkanaście dni pod kilkumetrową wodą znalazły się całe osiedla, tak więc przeniesienie backupu do sąsiedniego budynku nie uratowałoby danych. Najbardziej ekstremalne przypadki tego typu zdarzeń to atak na World Trade Center czy trzęsienia ziemi w aktywnych sejsmicznie rejonach świata (np. Włochy, Turcja).
O ile w Polsce trzęsienie ziemi niszczące budynek jest dość mało prawdopodobne, o tyle zalanie pomieszczeń, wybuch gazu, pożar, to jak najbardziej realny scenariusz. Zagrożeniem może być nawet… system przeciwpożarowy, który niepotrzebnie się uruchomi i zacznie gasić nieistniejący ogień mgłą wodną, pianą czy gazem. Dyski talerzowe w serwerach to wrażliwe urządzenia, które mogą nie przetrwać takich sytuacji. Opisane zagrożenia to nie zmyślone scenariusze, ale prawdziwe zdarzenia, które miały miejsce w serwerowniach zlokalizowanych w Polsce.
Zasada 3-2-1 w sposób skrócony opisuje mechanizm przechowywania zapewniający backup oraz kopie DR.
O tym, jak ważny jest dobrze skonfigurowany system kopii zapasowych, można się przekonać w momencie awarii lub ataku. W 2017 roku doszło do globalnych ataków wirusa typu ransomware WannaCry oraz NotPetya, które zaszyfrowały dane wielu firmom i instytucjom państwowym. Firmie Maersk, jednemu z największych na świecie operatorów kontenerowych, powrót do pełnej funkcjonalności po takim ataku zajął blisko dwa tygodnie, co oznacza, że firmie brakowało wtedy skutecznego i szybkiego planu przywrócenia danych. Alternatywą dla backupu jest zapłacenie okupu - kosztowne, wątpliwe moralnie i nie dające gwarancji, że przestępcy po wpłaceniu faktycznie odszyfrują dane.
Wydarzenia tego typu podkreślają wagę znaczenia, jakie ma wykonywanie kopii zapasowych oraz przechowywanie jej w bezpiecznym miejscu. Brak tworzenia regularnych kopii zapasowych to w perspektywie czasu prosta droga do “nieszczęścia”, które potem kosztuje sporo nerwów i pieniędzy. Cofnięcie stanu maszyny do najnowszego snapshotu oznacza utratę wszelkich postępów od momentu jego utworzenia. Brak kopii zapasowych dla aplikacji czy serwerów w razie awarii może wymagać czasochłonnej reinstalacji danego komponentu czy środowiska. W najgorszym przypadku brak kopii zapasowych może się wiązać z utratą wszelkich zgromadzonych danych. Konsekwencje takiej sytuacji mogą być różne: od kosztów gromadzenia danych od nowa, braku możliwości analizy danych historycznych, po kary za niedotrzymanie umów, a nawet upadłość firmy. Aż 60 proc. przedsiębiorstw, które po ataku na World Trade Center nie potrafiły odzyskać danych operacyjnych, przestało istnieć.
Testuj backup
Bardzo ważną kwestią, oprócz wykonywania kopii, jest wykonywanie cyklicznych testów odtwarzania danych z backupu w celu weryfikacji procesu, poprawności oraz integralności zabezpieczonych informacji. Dzięki regularnym testom zyskujemy pewność, że w przypadku awarii jesteśmy w stanie odtworzyć dane we wskazanym środowisku w założonym czasie. Umożliwia to budowanie szczegółowego planu naprawczego "Disaster Recovery Plan", który powinien określać kolejność odzyskiwania usług w celu przywrócenia środowiska do pełnej sprawności. Każde środowisko przetwarzające dane powinno mieć swój własny DRP.
Backup jako usługa
Dzięki chmurze publicznej możliwe jest zbudowanie bezpiecznych mechanizmów kopii zapasowej w optymalnym kosztowo modelu. Chmura nie tylko eliminuje konieczność zakupu kosztownych pamięci do archiwizowania danych, ale równocześnie przenosi zarchiwizowane dane poza budynek firmy, często do innego geograficznie regionu. Podczas realizacji projektów Backup-as-a-Service (BaaS) wykorzystujemy do przechowywania danych zarówno naszą autorską Platformę OChK, jak i oferujemy dodatkowe zabezpieczenia w Google Cloud lub Microsoft Azure. Każda kopia umieszczona na Platformie OChK jest domyślnie składowana w dwóch, odrębnych centrach przetwarzania danych ulokowanych na terytorium Polski. Zabezpieczamy zarówno środowiska on-premise klienta, jak i chmurowe. Szczegółowe rozwiązania zależą m. in. od skali działania organizacji, jej lokalizacji czy potrzeb związanych z wspomnianymi wcześniej wartościami RPO i RTO. Im lepiej przygotowany i przetestowany będzie backup, tym mniej nerwów i kosztów poniesie organizacja w przypadku wystąpienia awarii lub włamania.
