Chmura nie jest backupem. Co musi się stać, żeby odzyskanie danych było realne
Wysoka dostępność, replikacja i przechowywanie danych w SaaS pomagają, ale nie są tym samym co niezależna kopia możliwa do odtworzenia po błędzie lub ataku.
Dane mogą znajdować się w bardzo odpornej infrastrukturze i nadal nie mieć dobrego backupu. To jedno z najczęstszych nieporozumień związanych z usługami chmurowymi.
Dostępność chroni przed innym problemem niż backup
Replikacja może pomóc, gdy awarii ulegnie dysk lub część infrastruktury. Wysoka dostępność może utrzymać usługę mimo problemu pojedynczego komponentu. Jeżeli jednak administrator skasuje dane, złośliwy proces je zaszyfruje albo błędna synchronizacja nadpisze poprawną wersję, replikacja może równie sprawnie powielić błąd.
Backup ma inny cel. Ma pozwolić wrócić do wcześniejszego, użytecznego stanu. Dlatego liczą się retencja, wersjonowanie, możliwość odtworzenia i odpowiednia separacja od środowiska produkcyjnego.
Konto w SaaS też może potrzebować osobnej kopii
To, że dostawca utrzymuje własne mechanizmy redundancji, nie musi oznaczać, że klient może odtworzyć dowolny obiekt sprzed kilku tygodni. Zakres przywracania zależy od funkcji usługi, planu, retencji i umowy.
CISA w poradniku dotyczącym ransomware zaleca częste wykonywanie kopii oraz rozważa kopie offline lub cloud-to-cloud. Wskazuje również na wersjonowanie oraz mechanizmy chroniące obiekty przed skasowaniem lub nadpisaniem.
Backup istnieje dopiero wtedy, gdy da się go odtworzyć
Samo oznaczenie zasobu jako „backup” nie wystarcza. Kopia może być niekompletna, szyfrowana kluczem, którego już nie ma, zależna od tego samego konta albo tak duża, że czas przywracania jest nieakceptowalny.
Test odtworzenia odpowiada na pytanie, czy kopia jest rzeczywiście użyteczna. W praktyce trzeba wiedzieć nie tylko gdzie dane są zapisane, ale też kto może je odtworzyć, ile to trwa i jakie zależności są potrzebne.
Chmura może być elementem strategii backupu. Nie powinna być z nią automatycznie utożsamiana.
RPO i RTO porządkują rozmowę o odzyskiwaniu
RPO opisuje, ile danych organizacja może zaakceptować jako utracone po awarii. Jeżeli RPO wynosi godzinę, kopia wykonywana raz na dobę jest za rzadka. RTO opisuje natomiast, jak długo może trwać przywrócenie działania. Kopia, której odtworzenie zajmuje trzy dni, nie spełni wymagań systemu, który powinien wrócić w ciągu dwóch godzin.
Te dwa parametry pomagają odróżnić samo posiadanie kopii od planu odtwarzania. Warto je testować razem z rzeczywistą procedurą, bo deklarowany czas przywrócenia bez próby odtworzenia jest tylko założeniem.