Posiadasz kopię zapasową swojego biznesu?
Potężny pożar w serwerowni OVH wywołał ogromne zamieszanie nie tylko w środowisku IT, ale także w sporej części polskiego internetu. W jeszcze większą panikę wpadli wszyscy klienci OVH, którzy swój biznes prowadzą w sieci, a o kopiach zapasowych tylko słyszeli w porannej audycji radiowej lub babcia opowiadała im o tym do snu.
Zapisz się do newslettera, aby nie przegapić aktualizacji tego wpisu.
Spis treści
Jak często płoną serwerownie?
Żartownisie mówią, że tego typu zdarzenia pojawiają się średnio co 4 lata. Ostatnia poważna awaria w OVH wystąpiła w 2017 roku, kiedy uszkodzeniu uległa sieć szkieletowa i zabrakło zasilania w centrum danych w Strasburgu. Nie działały wtedy takie serwisy jak wirtualnemedia.pl, jakdojade.pl, pkp.pl, joemonster.org, kwejk.pl, niezalezna.pl.
W 2021 dokładnie ta sama serwerownia została zniszczona przez pożar. Uszkodzeniu uległo wiele serwerów, macierze z kopiami zapasowymi a sąsiednie budynki zostały pozbawione prądu ze względów bezpieczeństwa.
Incydent w OVH jest czymś naprawdę niespotykanym, dlatego nie należy wpadać w panikę. Data Center są chronione specjalnymi systemami, których zadaniem jest zduszenie pożaru, nim się rozprzestrzeni. Po wykryciu pożaru w komorze z serwerami następuje uwolnienie specjalnych gazów do pomieszczenia w celu redukcji zawartości tlenu w powietrzu z 21% obj do około 11% obj. Zapobiega to rozprzestrzenianiu się ognia.
Jako środek gaśniczy wykorzystuje się mieszkanki gazów takie jak INERGEN (IG-541), dwutlenek węgla, FM-200 lub NOVEC-1230. INERGEN jest nowoczesnym rozwiązaniem skomponowanym z azotu, argonu i dwutlenku węgla. Wpuszczony do płonącej serwerowni, obniża poziom tlenu, dzięki czemu ogień gaśnie a jednocześnie pozwala oddychać przebywającym tam technikom.
Taki pożar jak w Data Center w OVH to naprawdę coś, co nie zdarza się często i trudno było go przewidzieć, zwłaszcza że wpłynął również na sytuację w niezależnych podobno budynkach.
Jakie dane należy backupować?
Dane dzielimy na te, które zabezpieczamy kopią zapasową i te nieważne. W taki sposób możemy podejść do tego pytania. Danych, na których nam nie zależy - nie kopiujemy. O ile pamiętamy lub ktoś za nas pamięta o robieniu kopii zapasowej naszej strony internetowej, to o wielu innych danych już zapominamy. A przecież powinny być dla nas ważne!
Co warto backupować:
- plik danych z hasłami, jeżeli przechowujemy je w specjalnym programie,
- dokumenty księgowe, jeżeli korzystamy z systemów księgowych online,
- listę zakładek w przeglądarce,
- dane, z których korzystamy w systemach typu SaaS,
- ustawienia systemu, aplikacji i oprogramowania, z którego korzystamy,
- procedury, checklisty, dokumentację oraz listę zadań do wykonania,
- to co posiadamy na komputerze,
- ... a w gruncie rzeczy wszystko to, na czym nam zależy.
Jak często wykonywać kopie zapasowe?
Tak często jak to jest wymagane i opłacalne. Wyobraź sobie, że posiadasz sklep internetowy, którego kopię zapasową wykonujesz raz dziennie około północy. W ciągu dnia klienci składają w Twoim sklepie średnio 4 zamówienia. Uszkodzenie bazy danych nastąpiło pod koniec dnia.
Kiedy przywrócisz stan sklepu z kopii zapasowej, będzie w nim brakowało całego roboczego dnia. W przypadku 4 zamówień dziennie nie powinno stanowić to żadnego problemu. Możemy sprawdzić np. w wysłanych mailach jakie złożono zamówienia i ręcznie dodać je do systemu. Analogiczny problem można było zaobserwować w systemie BaseLinker:
UWAGA - przywrócony został stan systemu z wtorku o godzinie 1 w nocy. Przez cały wtorek system działał normalnie, jednak paczek i faktur z tego okresu nie ma w aktualnej wersji systemu. Zamówienia z wtorku zostaną pobrane ponownie jako nowe. Należy uważać, by nie obsłużyć ponownie zamówień z wtorku! Wgląd do nich będzie dopiero po przywróceniu przez OVH całego systemu. Zalecamy założenie nowych serii numeracji dla faktur i paragonów, tak aby nie było konfliktu z numerami wystawionymi we wtorek.
Co innego kiedy takich zamówień mamy tysiące. Ręczne ich dodanie będzie już problematyczne. W takim przypadku warto robić kopię zapasową częściej niż raz dziennie lub skorzystać z innych mechanizmów jak np. replikacja bazy danych. Wtedy mamy dane kopiowane w pewnym zakresie na żywo na inny serwer.
Częstotliwość wykonywania kopii zapasowych oraz to, ile ich będziemy przechowywać, będzie wiązała się z większymi kosztami infrastruktury serwerowej. Jeżeli nasza baza danych zajmuje 100 MB, a backup wykonujemy co godzinę i chcemy trzymać kopie z ostatnich 7 dni, wtedy potrzeba nam 100 × 24 × 7 = 16,8 GB dysków na kopie.
Zasada 3-2-1
Ważne zasady, przepisy czy procedury mają w swoim życiu odpowiednie liczby. Tak jak przepis na bimber ma swoje 1410 (1 kg cukru, 4 litry wody, 10 deka drożdży), tak kopie zapasowe mają 3-2-1. Zapamiętaj ten ciąg liczb, bo mówi on o:
- Miej co najmniej trzy egzemplarze danych...
- ...które są zapisane na dwóch różnego rodzaju nośnikach...
- ...z czego minimum jeden znajduje w oddzielnej lokalizacji.
Regułę ten wymyślił i spopularyzował fotograf Peter Krogh, który uważał, że prędzej czy później dysk z kopią zapasową zdjęć ulegnie awarii. Co dokładnie oznaczają te liczby?
Jeżeli ważne dla nas dane przechowujemy na dysku twardym, którego awaria zdarza się raz na 10 miesięcy, a kopię zapasową przechowujemy na takim samym urządzeniu to prawdopodobieństwo awarii obu urządzeń wynosi:
1/10 × 1/10 = 1/100
Natomiast jeżeli posiadamy dwie kopie na takich samych dyskach, to prawdopodobieństwo awarii wszystkich trzech równa się 1/1000.
Skoro posiadanie dużej liczby kopii zapasowych, bardzo zmniejsza ryzyko utraty wszystkich z nich, to skąd wymóg robienia ich na różnych nośnikach?
Tego samego typu urządzenia mogą mieć takie same wady fabryczne i być podatne na takie same rodzaje uszkodzeń. Dlatego warto jedną kopię przechowywać np. na dysku twardym a drugą na taśmie magnetycznej. W przypadku zalania serwerowni wodą taśmy mają zdecydowanie większą szansę na zachowanie danych, niż dysk twardy.
I tutaj pojawia się ostatnia liczba, czyli minimum jedna oddzielona lokalizacja. W przypadku zalania serwerowni, albo wystąpienia pożaru, mamy bezpieczną kopię zapasową w zupełnie innej lokalizacji. Jedną w górach a drugą nad morzem.
Formuła 3-2-1 rozszerza się o liczbę 0, czyli 3-2-1-0, gdzie ostatnia liczba oznacza zero problemów z odzyskaniem danych z kopii zapasowej.
Zrobiłem kopię. Co teraz?
Jak mówi stare powiedzenie: Ludzie dzielą się na tych, którzy robią kopie zapasowe i tych, którzy będą je robili. Jeżeli już posiadasz kopię zapasową to jesteś dopiero w połowie drogi do zabezpieczenia swoich danych. Teraz czas na rollback!
No cóż, za każdym razem kopiowałeś jedynie pierwsze 1000 maili i proces kopiowania się przerywał, nie pokazując błędu. Niepełny plik pobierał się poprawnie.
Kiedy takie rzeczy wyjdą w czasie awarii, możemy uznać, że nie masz kopii zapasowej a cały poświęcony czas na kopiowanie danych, był stracony. Takie same rzeczy przytrafiają się użytkownikom wtyczek do WordPressa, robiących kopie zapasowe. Często pliki, które one generują, nie zawierają wszystkich wymaganych danych do odzyskania strony lub są po prostu uszkodzone.
Disaster recovery plan
Disaster recovery, czyli odtwarzanie awaryjne, to zestaw polityk, dokumentów i procedur, które pomogą w powrocie do normalnego działania po wystąpieniu incydentu. Z praktycznego punktu widzenia, powinien być to dokument, w którym opiszemy procedury, które powinniśmy zastosować w przypadku utraty dostępu do danych.
Warto w takim dokumencie zapisać, gdzie przechowujemy kopie zapasowe, w jaki sposób odzyskujemy z nich dane oraz gdzie uruchomimy zapasowe usługi w przypadku utraty dostępu do obecnych na przykład:
- W przypadku awarii systemu mailingowego trwającego do dwóch godzin:
- Nie podejmujemy żadnych działań, poza monitorowaniem statusu usługi.
- W przypadku awarii systemu mailingowego trwającego dłużej niż 2 godziny:
- Zakładamy konto w innym systemie mailowym (lub już je posiadamy),
- importujemy listę subskrybentów z ostatniej kopii zapasowej, którą przechowujemy w Dropboxie,
- poprawiamy formularze rejestracyjne do newslettera na nowy system.
- Jeżeli awaria zakończy się w ciągu 24 godzin to:
- Eksportujemy z zapasowego systemu mailingowego wszystkich subskrybentów,
- importujemy ich do poprzedniego systemu,
- cofamy zmiany w formularzach rejestracyjnych.
- Jeżeli awaria nie zakończyła się w ciągu 24 godzin:
- Na stałe przełączamy się na nowy system mailingowy,
- odtwarzamy mailing automation w nowym systemie przy pomocy procedury i wymagań jakie zapisane są w dokumencie.
Dla każdego systemu, biznesu czy osoby taki plan będzie wyglądał zupełnie inaczej. Ważne jest, żeby zawrzeć w nim informacje w stylu: "co zrobimy jeśli to się wydarzy". Oczywiście wraz z rozwojem biznesu, dodawaniem nowych usług lub zmianą ważności danych, taki dokument powinien być aktualizowany, aby w razie poważnego incydentu był narzędziem, które pomoże odzyskać sprawność działania naszych usług.
Przykład podejścia do Disaster Recovery przez firmę BaseLinker, która ucierpiała przez incydent w OVH.
Większość naszych serwerów znajduje się w blokach, które nie uległy uszkodzeniom, jednak są aktualnie niedostępne.
Czekamy na uruchomienie tych bloków przez OVH, jednocześnie na wszelki wypadek pracujemy nad uruchomieniem systemu w innej serwerowni na podstawie backupu, który przechowywany jest w Polsce.
Dane trzymam w chumrze. Czy muszę robić kopie?
Tak. Chyba że nie zależy Ci na Twoich danych lub jesteś w stanie je wytworzyć ponownie. Należy pamiętać, że usługi w chmurze to nadal jakieś serwery w jakiś serwerowniach. A jak już wiemy, one potrafią spłonąć.
Czy zastanawiałeś się nad wykonaniem kopii zapasowej systemu mailingowego typu Mailerlie lub Mailchimp? A jak często ściągasz kopie zapasowe faktur z wfirma.pl, fakturownia.pl i innych? Czy Twoje notatki, jakie masz w Notion a może Evernote posiadają backup? Dokumenty w chmurze, poczta gdzieś na jakimś serwerze?
A teraz wyobraź sobie, że usługi te działają w oparciu o jednego dostawcę usług serwerowych, który z jakiegoś powodu przestaje działać. Może to być na skutek ataku terrorystycznego na budynek serwerowni, pożaru a może powodzi? W 2010 roku Onet walczył z powodzią w swoim data center:
Zdecydowaliśmy się na wyłączenie core’owych macierzy dyskowych i serwerów, ponieważ nagła utrata zasilania mogła doprowadzić do uszkodzenia danych lub samych urządzeń. (…) W międzyczasie poziom wody wokół data center podniósł się na tyle, że zostało ono odcięte od świata wraz z całym zespołem, który tam pracował. W tej sytuacji urządzenia zeszły na dalszy plan a problemem stała się ewakuacja ludzi z podtopionego budynku.
Usługi typu AWS S3 również nie dają 100% dostępności i trwałości danych tam przechowywanych. Mimo że zapewniają wysoki poziom bezpieczeństwa, należy pamiętać, że dane nie są wieczne.
Wiele usług typu SaaS posiada funkcje exportu danych do popularnych formatów plikowych. Na przykład w Mailerlite, możemy wyeksportować listę subskrybentów do formatu CSV. Tak przygotowany plik, możemy zapisać na dysku komputera lub innej usłudze w chmurze. Taką operację można wykonać raz na jakiś czas, dzięki czemu w razie poważnej awarii, będziemy posiadać własną kopię danych, na których nam zależy. Niestety nie każda usługa pozwala na taką operację. Wtedy warto pomyśleć o innej metodzie archiwizowania danych, jakie do niej wysyłamy np. wykonanie kopii, zanim zapiszemy je w SaaS.
Czy warto szyfrować kopie zapasowe?
Tak! Pamiętaj, że dobrze wykonana kopia zapasowe, jest przechowywana w innej lokalizacji niż dane, z której jest wykonywana. Może to być zewnętrzny dysk, pendrive lub inny serwer. W przypadku kradzieży sprzętu z kopią lub włamania na serwer, atakujący będzie miał dostęp do Twoich danych. Kiedy są one zaszyfrowane, taki dostęp będzie utrudniony lub niemożliwy.
Pamiętaj także, że RODO nakłada na Ciebie obowiązek wdrożenia odpowiednich środków technicznych i organizacyjnych, zapewniających bezpieczeństwo przetwarzanych w stopniu odpowiadającym ryzyku ich naruszenia. Jednym z tych kroków jest właśnie szyfrowanie danych.
Podsumowanie
Rób kopie zapasowe!
Testuj je!
Utrata danych jest kwestią czasu. Możne ona być spowodowana przez awarię systemu, infekcję malware, atak cyberprzestępców, zwykły ludzi błąd czy różnego rodzaju kataklizmy.