Backup w chmurze: reguła 3-2-1, RPO/RTO i kopia, której nie skasuje ransomware

Blog WebDisk · kategoria: Bezpieczeństwo · czas czytania: ~9 minut

W skrócie:- Synchronizacja plików to nie backup – powiela także szkody. Kopia zapasowa musi być niezależna od oryginału i odporna na jedno nieszczęśliwe kliknięcie.- Reguła 3-2-1 (trzy kopie, dwa różne nośniki, jedna poza lokalizacją) wciąż obowiązuje; chmura domyka jej najtrudniejsze ogniwo – kopię poza firmą.- Backup, którego nigdy nie odtworzyłeś testowo, to hipoteza, nie zabezpieczenie. Test odtworzenia planuje się równie poważnie jak sam backup.

Utrata danych rzadko uprzedza o swoim przyjściu. Dysk odchodzi bez ostrzeżenia, ktoś nadpisuje jedyny egzemplarz umowy, a ransomware szyfruje wszystko, do czego zdoła sięgnąć – razem z udziałami sieciowymi. Dla firmy oznacza to przestój, straty finansowe, często także utratę reputacji, a bywa, że i konsekwencje prawne. Dlatego kopia zapasowa przestała być opcją – jest fundamentem bezpieczeństwa IT. Pod jednym warunkiem: że jest zrobiona z głową, a nie „bo trzeba coś mieć”.

W tym artykule porządkujemy ten fundament: czym backup różni się od synchronizacji, co naprawdę mówi reguła 3-2-1, jak przełożyć skróty RPO i RTO na decyzje zrozumiałe dla biznesu, dlaczego współczesny ransomware celuje najpierw w kopie zapasowe – i dlaczego test odtworzenia to obowiązek, a nie dobra praktyka „na kiedyś”. Piszemy dla mieszanej publiczności: skorzysta zarówno jednoosobowa firma, jak i zespół IT układający plan awaryjny.

Synchronizacja to nie backup (i RAID też nie)

Najczęstsze złudzenie bezpieczeństwa brzmi: „mam wszystko w OneDrive/Dropboxie, więc mam backup”. Nie masz. Synchronizacja robi dokładnie to, co obiecuje nazwa: utrzymuje wszędzie ten sam stan. Gdy plik zostanie usunięty, nadpisany albo zaszyfrowany przez ransomware na jednym urządzeniu, zmiana posłusznie popłynie na wszystkie pozostałe. Wersjonowanie wbudowane w takie usługi bywa ratunkiem dla pojedynczego dokumentu, ale nie jest planem odtworzenia firmy – nie obejmuje systemów, baz danych ani konfiguracji i nie ma zdefiniowanej procedury powrotu do działania.

Podobnie RAID i lokalne migawki: chronią przed awarią pojedynczego dysku, ale nie przed błędem człowieka, kradzieżą sprzętu, pożarem serwerowni ani atakiem, który sięga całej infrastruktury naraz.

Backup to coś innego: osobna, wersjonowana kopia danych w innym miejscu, wykonywana automatycznie według harmonogramu, z określonym czasem przechowywania i – co najważniejsze – z procedurą odtworzenia, którą ktoś przećwiczył.

Reguła 3-2-1: trzy kopie, dwa nośniki, jedna poza firmą

Klasyczna reguła planowania backupu mieści się w trzech cyfrach: przechowuj trzy kopie danych (produkcyjne plus dwie zapasowe), na dwóch różnych rodzajach nośników lub systemów, z czego jedną poza lokalizacją, w której działa firma. Logika jest prosta: każde ogniwo chroni przed innym scenariuszem. Druga kopia ratuje przy awarii pierwszej; inny nośnik – przy wadzie wspólnej dla całej technologii; kopia poza firmą – przy zdarzeniu, które niszczy całą lokalizację: pożarze, zalaniu, kradzieży, ataku obejmującym sieć lokalną.

To właśnie ostatnie ogniwo było historycznie najtrudniejsze – wymagało wożenia taśm czy dysków do drugiej lokalizacji. Backup w chmurze domyka je naturalnie: kopie trafiają automatycznie do zdalnego centrum danych, bez fizycznych nośników i logistyki, a przestrzeń rośnie wraz z potrzebami. Dla firm, dla których ma znaczenie, gdzie fizycznie leżą dane, dodatkowym argumentem bywa chmura działająca w Polsce – kopia jest poza firmą, ale wciąż w znanej jurysdykcji.

Uczciwie trzeba dodać: chmura jest jednym z ogniw reguły 3-2-1, nie jej zamiennikiem. Kopia wyłącznie w jednej chmurze to nadal jedna kopia.

RPO i RTO po ludzku: ile możesz stracić i jak długo możesz stać

Dwa skróty, które porządkują każdą rozmowę o backupie:

• RPO (Recovery Point Objective) – ile danych możesz stracić, licząc wstecz od awarii. RPO to w praktyce odpowiedź na pytanie: „jak stara może być ostatnia kopia, żeby dało się z nią żyć?”. Backup raz na dobę oznacza RPO 24 godziny – w najgorszym razie przepada cały dzień pracy.
• RTO (Recovery Time Objective) – jak długo firma może czekać na odtworzenie, zanim przestój zacznie boleć naprawdę. To czas od decyzji „odtwarzamy” do ponownego działania systemu.

Obie wartości ustala się per system, nie jedną dla całej firmy. Archiwum dokumentów zniesie RPO liczone w dobach; baza zamówień sklepu internetowego – raczej w godzinach lub minutach. Dopiero od tych liczb zaczyna się dobór techniki: częstotliwość kopii, kopie przyrostowe (zapisujące tylko zmiany od poprzedniej kopii – dzięki czemu częsty backup nie oznacza przesyłania wszystkiego od zera), priorytety odtwarzania.

I jedna rzecz, o której rzadko mówią materiały reklamowe: im ambitniejsze RPO i RTO, tym wyższy koszt – częstszych kopii, większej przestrzeni, szybszego łącza. A realnego RTO nie da się zadeklarować: odtworzenie trwa tyle, ile pozwolą wolumen danych i przepustowość. Dlatego RTO się mierzy w testach, a nie wpisuje w prezentację.

Ransomware najpierw szuka kopii zapasowych

Współczesny atak ransomware rzadko zaczyna się od szyfrowania. Napastnik, który uzyskał dostęp do infrastruktury, najpierw rozgląda się w niej – i metodycznie namierza backupy. Kasuje je, szyfruje albo cicho psuje, bo wie, że firma ze sprawnym backupem nie zapłaci okupu. Dopiero potem szyfruje produkcję.

Wniosek z tysięcy takich incydentów: kopia zapasowa, którą da się usunąć tymi samymi uprawnieniami, którymi ją zapisano, nie jest zabezpieczeniem przed ransomware. Potrzebna jest kopia niezmienna – zapisana w trybie WORM (write once, read many – „zapisz raz, czytaj wiele razy”) – blokady, której przez zadany okres nie zdejmie żadnym standardowym żądaniem ani napastnik z przejętym kontem administratora, ani omylny skrypt, ani my sami w złym dniu. W świecie magazynów S3 realizuje to mechanizm blokady obiektów – opisaliśmy go szczegółowo w artykule o S3 Object Lock (WORM).

Na razie wystarczy zapamiętać zasadę: repozytorium backupu powinno być niezmienne przez cały okres retencji, a dostęp do niego – oddzielony od kont, którymi na co dzień administruje się produkcją. W usłudze WebDisk Backup kopie trafiają do naszego magazynu obiektowego S3.

Dlaczego object storage to dobry cel dla backupu?

Skoro kopia ma leżeć poza firmą, gdzieś musi fizycznie trafić. Coraz częściej tym miejscem jest object storage – magazyn obiektowy z interfejsem S3, czyli standardowym API, którym potrafi dziś mówić praktycznie każde narzędzie backupowe. Ma cechy, które pasują do backupu wyjątkowo dobrze: przestrzeń dokupuje się w miarę potrzeb, bez inwestowania z góry w macierz, a wersjonowanie i blokada obiektów dają ochronę przed nadpisaniem i usunięciem.

Pisaliśmy o nim szerzej w artykule o Object Storage w WebDisk; magazyn jest zbudowany na Ceph, otwartej platformie przechowywania danych, i dostępny przez standardowe narzędzia S3 (s3cmd, aws CLI, boto3). Ten sam magazyn, który służy aplikacjom, jest też naturalnym celem kopii zapasowych.

Od pojedynczego pliku do disaster recovery

Backup w chmurze nie ogranicza się do dokumentów. Kopie plikowe chronią wybrane katalogi z systemów Windows, Linux i macOS i pozwalają odzyskać pojedynczy plik. Kopie blokowe obejmują cały system operacyjny wraz z konfiguracją, aplikacjami i bazami danych – i to one otwierają drogę do disaster recovery, czyli planu awaryjnego przywracania działania systemów IT.

Disaster recovery to bardziej filozofia niż technologia. Zakłada, że awaria zdarzy się na pewno – pytanie nie brzmi „czy?”, tylko „kiedy?” – więc z góry ustala, które usługi, w jakiej kolejności i gdzie zostaną uruchomione ponownie. Backup w chmurze jest tu czymś więcej niż magazynem kopii: środowisko odtworzone z kopii blokowej można uruchomić jako maszynę wirtualną w chmurze WebDisk – odtworzone serwery komunikują się po tych samych adresach wewnętrznych co przed awarią. Firma może działać w chmurze, zanim odbuduje własną infrastrukturę. Technicznie to zresztą bliski krewny migracji środowiska do chmury – tyle że wykonywany pod presją, dlatego tym bardziej warto przećwiczyć go wcześniej.

Test odtworzenia to obowiązek, nie opcja

Backup, którego nikt nigdy nie odtworzył, może się okazać bezużyteczny dokładnie w chwili, gdy będzie najbardziej potrzebny – a wtedy jest już za późno na poprawki. Zielony status „kopia wykonana” mówi tylko tyle, że coś się zapisało; nie mówi, że da się z tego wrócić. Minimalny, powtarzalny test wygląda tak:

1. Wybierz scenariusz – pojedynczy plik, baza danych, cały serwer. Testuj po kolei wszystkie, nie tylko ten najłatwiejszy.
2. Odtwarzaj do izolowanego środowiska, nigdy na produkcję – test nie może sam wywołać awarii.
3. Zmierz czas od startu do działającej usługi. To jest Twoje realne RTO – porównaj je z założeniami.
4. Sprawdź spójność: system startuje, baza się otwiera, aplikacja loguje użytkowników. „Pliki się skopiowały” to za mało.
5. Udokumentuj procedurę krok po kroku i powtarzaj test cyklicznie (na przykład co kwartał) oraz po każdej istotnej zmianie infrastruktury.

Do tej listy warto dopisać monitoring samego backupu: kopia, która po cichu przestała się wykonywać, to najpodstępniejszy tryb awarii – wszystko wygląda dobrze aż do dnia, w którym trzeba coś odzyskać.

Czego backup w chmurze nie załatwia?

• Fizyka łącza. Pierwsza pełna kopia i pełne odtworzenie dużego środowiska trwają tyle, ile pozwoli internet. Kopie przyrostowe i deduplikacja (przechowywanie powtarzających się bloków tylko raz) łagodzą codzienność, ale plan awaryjny musi uwzględniać czas pełnego odtworzenia – stąd wartość odtwarzania bezpośrednio w chmurze, blisko danych.
• Backup to nie archiwum. Backup służy odtworzeniu bieżącego stanu; archiwum – wieloletniemu przechowywaniu według wymogów prawnych. Mają inne retencje i inne koszty; mylenie ich prowadzi albo do luk, albo do przepłacania.
• Niezmienność chroni integralność, nie poufność. Kopia WORM przetrwa atak, ale napastnik z dostępem może dane odczytać. Od poufności jest szyfrowanie – w drodze i w spoczynku; w WebDisk Backup kopie są szyfrowane już u źródła i pozostają zaszyfrowane w magazynie.
• Chmura nie zwalnia z reguły 3-2-1. Kopia w chmurze to jedno ogniwo łańcucha – krytyczne dane wciąż powinny mieć więcej niż jedną kopię zapasową.
• Technologia nie zastąpi procedur. Harmonogram, retencja, monitoring wykonania i przećwiczone odtwarzanie są równie ważne jak sam magazyn – to one odróżniają backup od składowiska plików.

Częste pytania

Czy OneDrive albo Dropbox wystarczy jako backup firmy? Nie. Synchronizacja powiela stan bieżący – także usunięcia i skutki ransomware. Wersjonowanie w takich usługach ratuje pojedyncze pliki, ale nie odtworzy serwera, bazy ani konfiguracji i nie daje żadnych gwarancji czasu powrotu do działania.

Na czym polega reguła backupu 3-2-1? Przechowuj trzy kopie danych (produkcyjne plus dwie zapasowe), na dwóch różnych rodzajach nośników lub systemów, z czego jedną poza lokalizacją firmy. Każde ogniwo chroni przed innym scenariuszem – od awarii pojedynczego urządzenia po zdarzenie niszczące całą lokalizację. Backup w chmurze domyka ostatnie, historycznie najtrudniejsze ogniwo: kopię poza firmą.

Co oznaczają RPO i RTO? RPO (Recovery Point Objective) mówi, ile danych możesz stracić, licząc wstecz od awarii – backup raz na dobę oznacza RPO 24 godziny. RTO (Recovery Time Objective) to czas od decyzji „odtwarzamy” do ponownego działania systemu. Obie wartości ustala się osobno dla każdego systemu, a realne RTO poznaje się w testach odtworzenia, nie w deklaracjach.

Jak często wykonywać kopie zapasowe? Tak często, jak wynika z RPO danego systemu: jeśli utrata czterech godzin pracy jest akceptowalna, backup co cztery godziny wystarczy; jeśli nie – potrzebujesz częstszych kopii przyrostowych. Zacznij od pytania biznesowego „ile możemy stracić?”, nie od możliwości narzędzia.

Czy ransomware może zaszyfrować także backup w chmurze? Może próbować – i jeśli repozytorium kopii jest zwykłym zasobem dostępnym na pełnych uprawnieniach z zaatakowanej sieci, bywa skuteczny. Dlatego repozytorium backupu powinno być niezmienne (WORM) przez okres retencji i oddzielone od codziennych kont administracyjnych. Szczegóły mechanizmu blokady obiektów S3 (Object Lock) opisujemy w osobnym artykule na blogu.

Ile kosztuje backup w chmurze? Usługi tego typu działają w modelu subskrypcyjnym – płaci się miesięcznie za chronione urządzenia i wykupioną przestrzeń, bez inwestycji we własne biblioteki taśmowe czy macierze. Aktualne plany i ceny WebDisk Backup znajdziesz na stronie usługi.

Od czego zacząć, jeśli dziś nie mam żadnego backupu? Od inwentaryzacji: co jest naprawdę krytyczne? Ustal RPO i RTO dla dwóch–trzech najważniejszych systemów, uruchom dla nich automatyczny backup do lokalizacji poza firmą – i w pierwszym miesiącu wykonaj test odtworzenia. Jeden przetestowany backup wart jest więcej niż pięć nieprzetestowanych.

Podsumowanie

Backup w chmurze to nie pojedynczy produkt, lecz strategia: reguła 3-2-1 wyznacza architekturę, RPO i RTO tłumaczą ją na język biznesu, niezmienne repozytorium broni kopii przed ransomware, a regularny test odtworzenia zamienia nadzieję w sprawdzoną procedurę. Chmura domyka w tej strategii najtrudniejsze elementy – kopię poza firmą i miejsce, w którym środowisko można uruchomić ponownie po awarii.

Dokładnie tak zbudowaliśmy WebDisk Backup: kopie plikowe systemów Windows, Linux i macOS, kopie blokowe serwerów i maszyn wirtualnych oraz backup środowisk Kubernetes, oparte na rozwiązaniach firmy Veeam, przyrostowe i deduplikowane, szyfrowane u źródła, przechowywane w naszym Object Storage – z możliwością odtworzenia całego środowiska jako maszyn wirtualnych w chmurze WebDisk. Chcesz przegadać plan backupu albo test odtworzenia w swojej organizacji? Napisz do nas.