Backup danych – czy warto?
Backup danych – czy warto?
Stare przysłowie informatyczne głosi:
“Ludzie dzielą się na tych co backupy robią oraz tych co robić BĘDĄ”
Aby nie ulec automatycznej kwalifikacji do grupy drugiej zapoznajmy się z kilkoma zawartymi poniżej zasadami.
Z jakiego powodu należy tworzyć backup danych?
Kopie bezpieczeństwa danych są prawie tak stare jak świat IT – zawodność używanych materiałów, możliwość pomyłki przy wprowadzaniu danych oraz zwykłe wypadki losowe na równi z działaniem siły wyższej spowodowały, iż do dnia dzisiejszego popularne kopie zapasowe i archiwizacja stanowią istotny fragment polityki bezpieczeństwa każdej firmy czy instytucji.
Łatwość z jaką mogą zniknąć dane w postaci cyfrowej każe nam solidnie przemyśleć co, gdzie i z jaką częstotliwością będziemy składować.
Zazwyczaj politykę wykonywania kopii zapasowych stanowi wypadkowa: ilości danych, czasu koniecznego do skutecznego odzysku danych oraz po prostu dostępnych środków finansowych. Błędy popełnione na etapie projektowania zazwyczaj są nieodwracalne, warto więc usiąść i odpowiedzieć sobie na następujące pytania:
- Jaki wolumen danych muszę zabezpieczyć w postaci kopii zapasowych?
- Co jaki okres czasu muszę wykonywać backup danych?
- Czy wystarczy mi kopia pełna (snapshot) czy z uwagi na ograniczenia infrastruktury mogę wykonywać kopie różnicowe lub przyrostowe?
- Kompresować dane czy nie?
- Jaki jest czas, w którym dane muszą zostać odzyskane i przywrócone?
- Czy mogę odzyskiwać dane częściowo (np. pojedyncze pliki) czy w całości (baza danych, kompletny komputer, maszyna wirtualna)?
- Gdzie mogę/muszę przechowywać kopie zapasowe?
Ilość danych
Jeden z kluczowych parametrów oceny – jaki jest wolumen i z jakich źródeł spływają dane, które jesteśmy zobligowani do zabezpieczenia.
Dlaczego kluczowy? Gdyż warunkuje metodykę, sprzęt i oprogramowanie, których możemy użyć. Dla przykładu: jeżeli ilość danych objętych naszymi działaniami przekracza możliwości przesyłu naszego łącza internetowego – wiemy iż metoda backupu do chmury zostanie przesunięta na kolejny etap.
Podobnie jeżeli ilość danych wyklucza używanie wciąż popularnych napędów taśmowych – to nawet posiadając taki na stanie musimy przemyśleć czy nie wykorzystać go w końcowym etapie archiwizacji, wyselekcjonowanych danych naprawdę kluczowych.
Analogicznie – jeżeli ilość danych przekracza nasze możliwości pod względem wolnego miejsca – musimy zastanowić się nad wdrożeniem kompresji lub metod kopii różnicowych lub przyrostowych, zmienić schemat wykonywania kopii zapasowych, wdrożyć np. mechanizmy kompresji czy też deduplikacji.
Częstotliwość backupu
Dla każdego przypadku stosowane są inne zasady wykonywania kopii, nie istnieje jeden uniwersalny schemat postępowania. Musimy sbie jednak odpowiedzieć na pytanie: jak aktualne dane powinniśmy posiadać? Czy wystarczy nam kopia realizowane codziennie (np. na zakończenie dnia pracy), czy przynajmniej 2 razy dziennie, czy też w grę wchodzi jedynie replikacja (na poziomie poszczególnych transakcji).
Na tym etapie warto również podzielić dane wg. priorytetu: dane produkcyjne zazwyczaj są o wiele bardziej krytyczne niż pliki czy nawet poczta elektroniczna użytkowników.
Ustalając schemat można natomiast kierować się dobrymi praktykami.
Dla przykładu: backup danych wykonywany w schemacie tygodniowym:
- poniedziałek-sobota kopie przyrostowe lub różnicowe
- niedziela – kopia pełna
- ostatni dzień miesiąca – kopia pełna
- ostatni dzień roku – kopia pełna
Dla tygodnia roboczego: pn-pt
- poniedziałek-czwartek kopie przyrostowe lub różnicowe
- piątek – kopia pełna
- ostatni dzień miesiąca – kopia pełna
- Czas konieczny na odtworzenie danych.
Często pomijany przy rozważaniach parametr, pozostawiany do “jakoś to będzie”. Musimy jednak zdawać sobie sprawę iż jeżeli na okno backupowe poświęcamy np. 8h w nocy, to mało prawdopodobne aby udało się nam odzyskać te same dane w czasie relatywnie krótszym. Czas ten wzrasta niemalże wykładniczo w przypadku np.kopii przyrostowych lub odtwarzania danych w inne miejsce niż źródłowe.
Odzysk całości czy pojedynczych plików.
Łatwo wyobrazić sobie sytuację, w której przywrócenie plików dla jednego z użytkowników oznacza także nadpisanie pozostałych plików wcześniejszymi wersjami. Nasz plan kopii powinien więc zawsze zakładać możliwość odtworzenia plików w inne miejsce niż ich źródłowe pochodzenie, a także możliwość ekstrakcji poszczególnych plików.
Przechowywanie plików kopii zapasowych
Jeżeli tylko mamy taką możliwość – wyprowadźmy przynajmniej jeden z poziomów backupu poza miejsce w których nasze dane zazwyczaj rezydują. Chociaż ekonomicznie ciężkie do uzasadniania w przypadku utraty np. pomieszczenia serwerowni z uwagi na wypadek losowy (pożar, zalanie, kradzież) do dyspozycji zostają nam kopie przechowywane w miejscu zewnętrznym.
Współczynniki
Oto kilka współczynników, których wartości musimy uzgodnić przed projektowaniem i bieżącym wykonywaniem kopii zapasowych. Celem naszych operacji jest przecież bezpieczne i szybkie odtworzenie danych w sytuacjach awaryjnych.
Oto dwa magiczne skróty RTO i RPO oraz termin ‚okno backupowe/okno kopii zapasowych’
- RTO – Recovery Time Objective określa nam interwał czasowy jaki jest niezbędny aby przywrócić nasz system do pełnej lub założonej częściowej funkcjonalności. W skrócie jest to czas poświęcony zarówno na próby diagnostyki, naprawy, przywracania funkcjonalności oraz udanego odtworzenia danych z kopii zapasowej.
- RPO – Recovery Point Objective określa nam maksymalny okres czasu z jakiego dane mogą zostać utracone. Dla przykładu RPO na poziomie 24 godzin oznacza iż organizacja poradzi sobie z brakiem lub ręcznym nadrobieniem zmian jakie zostały dokonane w danych przez ostatnie 24h. Doskonałym przykładem jest tu firma, która przetwarza dziennie kilka lub kilkanaście dokumentów – ich ponowne wprowadzenie do systemu jest rozwiązaniem akceptowalnym i tańszym niż skomplikowane plany wykonywania zabezpieczeń.
Z kolei trudno mówić o interwale 24godzinnym wspominając na przykład instytucje finansowe – tu ciężko sobie wyobrazić konieczność uzupełniania danych z takiego interwału – dane te są częścią większego systemu np. rozliczeń międzybankowych, nie ma więc mowy o zwłoce na nadrobienie strat.
- Okno kopii zapasowych jest z kolei interwałem, w którym nasze zaplanowane operacje mają szanse się wykonać. Podczas wykonywania kopii należy się liczyć z realokacją zasobów (czas procesora, operacje dyskowe, operacje sieciowe) na korzyść procesów wykonywania tychże operacji, jak również wziąść pod uwagę iż różnica czasowa pomiędzy plikami z początku okna kopii zapasowych może być dosyć znaczna. Oba te powody wpływają na wybór najczęstszego terminu wykonywania kopii – godziny nocne.
Bardzo ważnym jest aby te parametry, często narzucane przez część biznesową firmy, były po pierwsze: realne, po drugie: dotrzymywane. Nic nam nie da trzymanie się schematu kopii co godzinę wg. nierealnego planu, gdy okna kopii zapasowych będą się na siebie nakładać, w praktyce uniemożliwiając zabezpieczenie czegokolwiek.
Poprawnie wykonana kopia zapasowa w schemacie dobowym (np. o północy) pozwala na zabezpieczenie RPO na poziomie 24 godzin, przy współczynniku RPO wynoszącym 12h, (podczas pracy organizacji od 6 do 18). Oznacza to, iż kopie powinniśmy robić przynajmniej dwa razy dziennie.
Dla potrzeb artykułu zakładamy następujące wartości: organizacja pracuje od 06:00 do 18:00, RTOna 6h, RPO na 12h, I okno kopii zapasowych od godziny 10:00 do 14:00, II okno kopii zapasowych od godziny 22:00 do 02:00.
Powyższe współczynniki zależą głównie od technologicznych możliwości danej organizacji oraz ilości danych, które jesteśmy zmuszeni zabezpieczyć. Wartości te są przykładowe i dobrane tylko i wyłączne w celu demonstracji poniższego schematu – mogą być jednak łatwo adapotowalne.
RPO 12h, RTO 6h oznacza to, iż w przypadku awarii mamy 6 godzin na przywrócenie funkcjonalności systemu, nasze dane mogą być maksymalnie sprzed 12 godzin. W pierwszej kolejności oznacza to, iż nasze zaprojektowane okna kopii zapasowych uruchamiane są o godzinach 10:00 i 22:00, każde z nich trwa nie więcej niż 4h.
Skąd kluczowa wartość 4h? W RPO mamy czas na odtworzenie sprzętu, systemu oraz danych aplikacji – okno kopii zapasowych trwające np. 11h wyklucza interwał 6h RPO gdyż po prostu znacząco go przekracza. Zakładamy więc iż w 1h odtworzymy hardware (czy poprzez naprawę czy podstawienie), w kolejne 30 minut wykonamy odtworzenie BareMetal Recovery (MBR/GPT, tablice partycji, hidden MBR Data, system operacyjny, pliki/dyski wymiany itp), w kolejne 3-4h odtwarzamy dane i pozostaje nam ok. 30 minut na weryfikację całości.
W naszym schemacie zakładamy iż kompresja naszych przykładowych danych jest sporo wolniejsza od procesu dekompresji i przesłania danych w miejsce docelowe (pozwala nam to zaplanować odtwarzanie danych w czasie szybszym niż ich kopiowanie).