Jak zaprojektować niezawodny backup? RPO, RTO i Retencja

Backup, którego nikt nie sprawdza 

W wielu organizacjach MŚP backup po prostu jest. Zadanie uruchamia się każdej nocy, raport przychodzi „na zielono”, a temat wraca dopiero wtedy, gdy trzeba coś rzeczywiście odtworzyć. Problem polega na tym, że sama obecność kopii zapasowej niewiele mówi o tym, czy w razie awarii uda się odzyskać to, co naprawdę jest potrzebne – i to w czasie, na który biznes może sobie pozwolić. 

Najczęstszym błędem nie jest brak backupu, lecz brak zróżnicowania. Wszystkie systemy są kopiowane tą samą metodą, z taką samą częstotliwością, bez zastanowienia, czy dany zasób rzeczywiście wymaga takiego poziomu ochrony. Efekt bywa paradoksalny – przepłaca się za zabezpieczenie danych, których utrata przez tydzień nie miałaby większego znaczenia, a jednocześnie zbyt słabo chroni się systemy, bez których firma dosłownie przestaje działać. Pytania „ile danych stracimy?” i „jak długo będziemy offline?” pojawiają się dopiero w trakcie awarii, czyli w najgorszym możliwym momencie na szukanie odpowiedzi. 

Dobra strategia backupu nie zaczyna się od wyboru narzędzia, lecz od świadomego zadania trzech pytań dla każdego systemu z osobna: ile danych organizacja może stracić, jak długo może funkcjonować bez danego systemu oraz jak długo należy przechowywać kopie, aby spełnić wymagania biznesowe i prawne. 

Wolisz posłuchać? 

Inwentaryzacja jako punkt wyjścia 

Wybór technologii backupowej bez wcześniejszej wiedzy o tym, co i w jaki sposób należy chronić, w praktyce sprowadza się do zgadywania. Dlatego, zanim zapadnie jakakolwiek decyzja technologiczna, warto przeprowadzić rzetelną inwentaryzację – spisać systemy i aplikacje wraz z informacją, gdzie fizycznie lub logicznie się znajdują oraz kto po stronie biznesu odpowiada za decyzje dotyczące ich ochrony. Do tego dochodzi inwentaryzacja samych danych: baz danych i tempa ich przyrostu, plików oraz udziałów sieciowych, konfiguracji systemów, poczty elektronicznej, a także zależności między systemami. Przykładowo system ERP korzystający z bazy danych i usługi katalogowej należy odtwarzać w odpowiedniej kolejności, a nie równolegle i przypadkowo. 

Nie trzeba robić tego od zera – udostępniamy gotowy, sparametryzowany inwentarz systemów z kalkulatorem zapotrzebowania na pojemność backupu.

Na tej podstawie można pokusić się o klasyfikację krytyczności. Systemy krytyczne to te, bez których biznes dosłownie staje – na przykład system sprzedaży, produkcji czy poczta elektroniczna. Systemy ważne utrudniają pracę, ale zwykle istnieje dla nich obejście, jak choćby CRM czy pliki działowe. Z kolei systemy pomocnicze, takie jak archiwa lub dane historyczne, są niewygodne w przypadku niedostępności, ale nie blokują bieżącego funkcjonowania organizacji. 

Taka klasyfikacja ma bezpośrednie przełożenie na kolejne kroki. Poszczególne systemy powinny mieć różne wartości RPO, RTO i retencji, ponieważ z perspektywy kosztów oraz potrzeb biznesowych nie każdy z nich wymaga tego samego poziomu ochrony. 

RPO (Recovery Point Objective) – ile danych możemy stracić 

Recovery Point Objective (RPO) określa maksymalny akceptowalny okres, z którego dane mogą zostać bezpowrotnie utracone w razie awarii. Warto podkreślić, że RPO nie mówi nic o tym, jak szybko system wróci do działania – określa wyłącznie, ile pracy zostanie utracone między ostatnią poprawnie wykonaną kopią zapasową a momentem awarii. 

W praktyce różnica bywa bardzo odczuwalna. Przy RPO wynoszącym 24 godziny ostatnia kopia mogła zostać wykonana poprzedniego wieczoru, więc awaria w południe oznacza utratę nawet pół dnia pracy całego zespołu. Przy RPO liczonym w godzinach strata ogranicza się do danych powstałych od ostatniej kopii, czyli zwykle jest znacznie mniejsza. Z kolei RPO bliskie zeru, oparte na replikacji ciągłej, sprawia, że utrata danych praktycznie nie występuje – jednak takie rozwiązanie ma swoją cenę. 

Wymagane RPO zależy przede wszystkim od tego, ile danych i transakcji powstaje w określonym czasie, czy dane można odtworzyć ręcznie (na przykład ponownie wprowadzając faktury), czy są one bezpowrotnie tracone, jak przebieg rozmowy z klientem lub podjęta decyzja biznesowa, a także od tego, czy koszt ich utraty uzasadnia inwestycję w częstsze wykonywanie kopii zapasowych. 

Przeczytaj także: Skuteczny backup dancyh w firmie. Jak rozmawiać z Biznesem? 

Backup wykonywany raz dziennie bywa w zupełności wystarczający dla archiwów i rzadko zmienianych plików. W przypadku systemów transakcyjnych, takich jak sprzedaż czy produkcja, utrata całego dnia pracy zwykle jest jednak nieakceptowalna. Backup wykonywany kilka razy dziennie lub w trybie przyrostowym stanowi rozsądny kompromis dla większości systemów biznesowych o średniej krytyczności, choć wymaga częstszego wykonywania zadań oraz większej przestrzeni na przechowywanie kolejnych wersji. Replikacja lub migawki zapewniające RPO liczone w minutach wiążą się natomiast z bardziej zaawansowaną technologią, wyższymi kosztami infrastruktury oraz większymi wymaganiami dotyczącymi przepustowości łącza. Takie rozwiązania mają uzasadnienie przede wszystkim w przypadku systemów rzeczywiście krytycznych, takich jak bazy transakcyjne czy systemy płatnicze. 

RTO (Recovery Time Objective) – jak długo możemy być offline 

Recovery Time Objective (RTO) określa maksymalny akceptowalny czas potrzebny na przywrócenie systemu do działania od momentu wystąpienia awarii. W odróżnieniu od RPO parametr ten nie odnosi się do utraconych danych – określa wyłącznie, jak szybko organizacja powinna wrócić do pracy. 

RTO wynoszące 24 godziny oznacza akceptację sytuacji, w której system może pozostawać niedostępny przez cały dzień. RTO liczone w godzinach wymaga już przygotowanych procedur oraz zasobów pozwalających przywrócić działanie w ciągu kilku godzin. RTO poniżej jednej godziny to zupełnie inna liga – wymaga gotowej infrastruktury zapasowej, a nie tylko samej kopii danych. 

Wymagane RTO zależy przede wszystkim od kosztu przestoju liczonego w godzinach – utraconej sprzedaży, zatrzymanej produkcji czy kar umownych. Istotne jest również to, czy podczas przestoju istnieje alternatywny sposób pracy, choćby w formie papierowej, oraz czy organizację obowiązują wymagania wynikające z umów SLA lub regulacji. 

Odtwarzanie z backupu na nowy lub naprawiony sprzęt, obejmujące zamówienie urządzeń, instalację systemu i przywrócenie danych, jest najtańszym rozwiązaniem i sprawdza się w przypadku systemów o niskiej krytyczności. Gotowa infrastruktura zapasowa, na której wystarczy uruchomić wcześniej przygotowaną maszynę i odtworzyć dane, stanowi typowe rozwiązanie dla większości systemów biznesowych. Z kolei środowiska pracujące w trybie wysokiej dostępności z automatycznym mechanizmem failover wymagają utrzymywania zdublowanej infrastruktury działającej przez cały czas. To kosztowne rozwiązanie, dlatego warto je rozważać wyłącznie dla systemów absolutnie krytycznych. 

Warto również pamiętać, że RPO i RTO są od siebie niezależne. Można mieć dane replikowane niemal w czasie rzeczywistym, a mimo to wysokie RTO, jeśli brakuje gotowej infrastruktury do ich uruchomienia. Można też bardzo szybko przywrócić system do działania, ale z nieco starszą wersją danych, ponieważ backup wykonywany jest rzadziej. Dlatego oba parametry należy określać świadomie i niezależnie dla każdego systemu, nie zakładając, że jeden automatycznie wynika z drugiego. 

Oba parametry bywają mylone, bo w obu chodzi o czas. Różnica polega na tym, w którą stronę ten czas biegnie względem momentu awarii – RPO patrzy wstecz, na ostatnią wykonaną kopię, a RTO naprzód, do chwili przywrócenia działania. 

	RPO (Recovery Point Objective)	RTO (Recovery Time Objective)
Odpowiada na pytanie	Ile danych stracimy?	Jak długo będziemy offline?
Kierunek na osi czasu	Wstecz – od awarii do ostatniej poprawnej kopii	Naprzód — od awarii do przywrócenia działania
Determinuje	Częstotliwość wykonywania kopii zapasowych	Maksymalny czas przywrócenia danych
Obniżenie wymaga	Częstszych backupów, migawek lub replikacji	Zaostrzenia polityk, szybkich mediów na kopie bezpieczeństwa, w niektórych przypadkach nadmiarowej infrastruktury
Główny koszt	Przestrzeń dyskowa	Przepustowość i nadmiarowa infrastruktura
Wartość „4 godziny” oznacza	Tracimy dane najwyżej z 4 godzin pracy	Wracamy do pracy najpóźniej po 4 godzinach

 

W skrócie: RPO decyduje o tym, jak często wykonujemy kopie, a RTO o tym,  jak szybko je odtworzymy. Pierwszy parametr kupuje się przestrzenią, drugi – przepustowością i nadmiarowym sprzętem.

Retencja – jak długo przechowujemy kopie zapasowe 

Retencja określa, jak długo przechowywane są kopie zapasowe oraz jak często zachowywane są ich kolejne wersje. Parametr ten nie chroni przed samą awarią sprzętu, lecz przed problemami wykrytymi zbyt późno, takimi jak błąd użytkownika sprzed kilku tygodni, uszkodzenie danych, które rozprzestrzeniło się, zanim ktokolwiek je zauważył, czy konieczność spełnienia wymogów prawnych dotyczących przechowywania dokumentacji. 

Długość retencji zależy przede wszystkim od wymogów prawnych i podatkowych dotyczących dokumentacji finansowej lub kadrowej, czasu, po którym zwykle wykrywany jest dany problem – niekiedy dopiero po wielu tygodniach lub miesiącach – oraz potrzeb biznesowych związanych z możliwością odtworzenia stanu sprzed konkretnego zdarzenia. 

Prosta retencja, na przykład obejmująca ostatnie 30 dni, jest łatwa do zrozumienia, ale przy krótkich interwałach backupu może zajmować dużo miejsca, a po upływie określonego czasu najstarsza kopia zostaje bezpowrotnie usunięta. Retencja warstwowa (GFS – dziadek–ojciec–syn) przechowuje kopie dzienne przez krótki okres, tygodniowe dłużej, miesięczne jeszcze dłużej, a roczne zgodnie z wymaganiami prawnymi. Dzięki temu znacznie efektywniej wykorzystuje dostępną przestrzeń niż proste podejście. 

W praktyce schemat GFS wygląda najczęściej tak: 

Typ kopii	Częstotliwość	Okres przechowywania
Dzienna („syn”)	raz na dobę	7 dni
Tygodniowa („ojciec”)	raz w tygodniu	4 tygodnie
Miesięczna („dziadek”)	raz w miesiącu	12 miesięcy
Roczna	raz w roku	zgodnie z wymaganiami

 

Krótka retencja bywa wystarczająca dla danych o niewielkiej wartości historycznej. Retencja warstwowa jest obecnie standardem w większości organizacji, choć wymaga przemyślanej konfiguracji i odpowiednich możliwości narzędzia backupowego. Z kolei długa retencja, liczona w latach, jest niezbędna dla danych finansowych, kadrowych czy medycznych objętych obowiązkami ustawowymi. Takie kopie zwykle warto przechowywać na tańszych, wolniejszych nośnikach, ponieważ nie muszą być dostępne natychmiast. 

Jak te parametry przekładają się na architekturę 

Dopiero po ustaleniu RPO, RTO i retencji dla poszczególnych systemów sensowne staje się projektowanie architektury oraz dobór odpowiednich technologii. Niższe RPO oznacza konieczność częstszego wykonywania kopii zapasowych lub zastosowania replikacji, co przekłada się na większe obciążenie infrastruktury oraz łączy komunikacyjnych. Z kolei niższe RTO często wymaga utrzymywania gotowej infrastruktury zapasowej, co zwiększa koszty niezależnie od samego rozwiązania backupowego. Dłuższa retencja oznacza natomiast większe zapotrzebowanie na przestrzeń dyskową, co naturalnie prowadzi do warstwowania nośników – szybkiego storage’u dla najnowszych kopii oraz tańszych rozwiązań dla danych archiwalnych. 

W praktyce dla organizacji liczącej kilkudziesięciu użytkowników macierz wymagań może wyglądać przykładowo następująco: 

System	Krytyczność	RPO	RTO	Retencja
System sprzedaży / ERP	krytyczny	1 godzina	4 godziny	warstwowa, do 7 lat (wymogi prawne)
Poczta elektroniczna	krytyczny	kilka godzin	kilka godzin	warstwowa, zgodnie z polityką firmy
Pliki współdzielone	ważny	24 godziny	kilka godzin	warstwowa, kilkanaście miesięcy
Archiwum dokumentów	pomocniczy	1 miesiąć	1–2 dni	długa, wiele lat

.

Kolejność, która ma znaczenie 

Projektowanie strategii backupu warto rozpocząć od inwentaryzacji systemów i danych, następnie przejść do określenia ich krytyczności, a dopiero później definiować wymagania dotyczące RPO, RTO i retencji dla poszczególnych obszarów. Dobór technologii oraz architektury spełniającej te wymagania powinien być ostatnim etapem tego procesu, a nie punktem wyjścia. 

Nawet najlepiej zaprojektowane środowisko wymaga jednak regularnej weryfikacji. Testy odtworzeniowe pozwalają zweryfikować, czy przyjęte założenia rzeczywiście działają w praktyce, a nie tylko dobrze wyglądają w dokumentacji. 

Jednym z najczęstszych błędów jest traktowanie wszystkich systemów w organizacji w taki sam sposób. W efekcie firma może przepłacać za ochronę danych, których utrata nie miałaby większego wpływu na działalność, albo – co znacznie bardziej ryzykowne – pozostawić systemy krytyczne z niewystarczającym poziomem zabezpieczenia. 

RPO, RTO i retencja nie są wyłącznie parametrami technicznymi ustawianymi w narzędziu backupowym. To decyzje biznesowe, które powinien świadomie określić właściciel danego systemu. Zadaniem IT jest natomiast przełożenie tych wymagań na odpowiednią architekturę, wdrożenie zabezpieczeń oraz regularne sprawdzanie, czy w sytuacji awarii rzeczywiście można osiągnąć zakładane rezultaty. 

Podsumowanie 

Dobry backup nie zaczyna się od wyboru narzędzia, ale od zadania właściwych pytań – takich, na które znacznie łatwiej odpowiedzieć na spokojnie niż w trakcie rzeczywistej awarii. 

Inwentaryzacja i klasyfikacja systemów pokazują, jakie zasoby wymagają ochrony oraz jaki poziom zabezpieczenia jest dla nich uzasadniony. RPO, RTO i retencja przekładają te założenia na konkretne, mierzalne wymagania wobec architektury. Dopiero taka kolejność sprawia, że backup przestaje być procesem wykonywanym każdej nocy „na wszelki wypadek”, a staje się świadomie zaprojektowanym elementem odporności organizacji – z jasną odpowiedzią na pytanie, ile danych i czasu firma rzeczywiście może sobie pozwolić stracić. 

W ESVS pomagamy organizacjom MŚP projektować i zarządzać skutecznymi strategiami backupu – od inwentaryzacji zasobów i określenia zakresu ochrony, przez przygotowanie polityki ciągłości działania oraz konfigurację polityk backupu, aż po wymagane rekonfiguracje, regularne testy odtworzeniowe, disaster recovery i odtwarzanie systemów oraz danych po awarii. 

Zapraszamy do kontaktu.

Najczęstsze pytania 

Czym różni się RPO od RTO? 

RPO określa, ile danych możemy stracić – czyli jak daleko wstecz sięga ostatnia kopia. RTO określa, jak długo możemy być offline, czyli ile czasu zajmie przywrócenie systemu. Parametry są od siebie niezależne: można mieć bardzo niskie RPO i jednocześnie wysokie RTO, jeśli dane są objęte backupem, ale brakuje sprzętu, na którym można je odtworzyć. 

Jakie RPO jest rozsądne dla małej firmy? 

Dla archiwów i rzadko zmienianych plików backup raz na tydzień zwykle wystarcza. Dla systemów transakcyjnych – sprzedaży, produkcji, fakturowania – utrata całego dnia pracy najczęściej jest nie do przyjęcia, więc rozsądnym punktem wyjścia jest kilka kopii dziennie. RPO liczone w minutach ma sens wyłącznie tam, gdzie koszt utraty danych realnie przewyższa koszt replikacji. 

Jak długo trzeba przechowywać kopie zapasowe? 

Nie ma jednej odpowiedzi – okres wynika z trzech rzeczy: wymogów prawnych i podatkowych dla danego rodzaju dokumentacji, czasu, po jakim zwykle wykrywa się problem w danej organizacji, oraz wartości historycznej danych. Dokumentacja finansowa i kadrowa wymaga lat, pliki robocze zwykle miesięcy. 

Czy backup wykonywany raz dziennie wystarczy? 

Zależy od systemu. Jeśli awaria w południe oznaczałaby utratę pół dnia pracy całego zespołu i nikt nie jest w stanie tych danych łatwo wprowadzić ponownie, to nie wystarczy. Jeśli dane zmieniają się rzadko albo można je łatwo odtworzyć z innego źródła – najczęściej tak. 

Co to jest retencja GFS? 

GFS (dziadek-ojciec-syn) to warstwowy schemat przechowywania kopii: dzienne trzymane są krótko, tygodniowe dłużej, miesięczne jeszcze dłużej, a roczne zgodnie z indywidualnymi wymaganiamii. Pozwala sięgnąć daleko wstecz bez przechowywania wszystkich kopii dziennych, więc zużywa znacznie mniej przestrzeni niż prosta retencja.