Macie backup. Serwery działają. Polityka bezpieczeństwa gdzieś jest spisana. Wydaje się, że firma jest zabezpieczona. A potem przychodzi ransomware, który szyfruje nie tylko dane produkcyjne, ale też podłączone zasoby sieciowe z kopiami. Okazuje się, że odtworzenie systemów zajmuje nie godziny, lecz dni. Albo że backup wprawdzie jest, ale nikt nigdy nie sprawdził, czy da się z niego odbudować całe środowisko.
Disaster Recovery nie jest tematem wyłącznie dla korporacji z własnym centrum danych. Dotyczy każdej firmy, dla której przestój kosztuje więcej niż zaplanowane zabezpieczenie. A dla firm objętych dyrektywą NIS2 to już nie wybór, tylko obowiązek wynikający wprost z wymagań dotyczących ciągłości działania i odtwarzania systemów po incydencie.
Ten artykuł odpowiada na pytania, które nasi konsultanci słyszą najczęściej: ile realnie kosztuje disaster recovery dla średniej firmy, czym różni się od backupu, który już macie, i co konkretnie wynika z NIS2. Bez ogólników, z widełkami kosztów i podziałem na typy rozwiązań.
Dlaczego firmy unikają tematu Disaster Recovery?
Za unikaniem tematu stoją zwykle trzy przekonania:
- „To za drogie”. Panuje przekonanie, że DR to inwestycja rzędu kilkuset tysięcy złotych i projekt wymagający własnej serwerowni zapasowej. To mit, który przez lata funkcjonował jako fakt, bo tradycyjne rozwiązania oparte na fizycznej replikacji rzeczywiście były drogie. Chmura to zmieniła. Mechanizmy dostępne kiedyś tylko dla dużych organizacji działają dziś w modelu subskrypcyjnym, skalowanym do firmy zatrudniającej 50 czy 200 osób.
- „Przecież mamy backup”. To najczęstsze nieporozumienie: mylenie backupu z disaster recovery. Jeśli macie kopie, macie dane, ale nie macie gotowości operacyjnej. Backup odpowiada na pytanie, czy dane przetrwają awarię. Disaster recovery odpowiada na inne: ile czasu zajmie przywrócenie firmy do działania.
- „Ktoś się tym zajmuje”. Fałszywe poczucie bezpieczeństwa. Backup jest, ktoś go monitoruje, raporty przychodzą. Tyle że nikt nie przeprowadził testu odtworzenia środowiska produkcyjnego w warunkach zbliżonych do prawdziwej awarii. Gdy kontrola KSC pyta o plany ciągłości działania, sam fakt istnienia kopii nie wystarczy.
Backup a Disaster Recovery: różnica, która kosztuje dni przestoju
Backup i disaster recovery rozwiązują dwa różne problemy. Często współistnieją, ale nie są tym samym. Najprościej ująć to tak:
| Kryterium | Backup | Disaster Recovery |
|---|---|---|
| Na jakie pytanie odpowiada? | Czy dane przetrwają awarię? | Ile czasu zajmie przywrócenie firmy do działania? |
| Co obejmuje? | Kopię danych z określonego punktu w czasie | Procedury odtworzenia danych, konfiguracji, systemów i dostępów |
| Efekt | Odzyskane pliki | Działające środowisko produkcyjne |
| Kluczowe parametry | Częstotliwość i retencja kopii | RTO i RPO dla każdego systemu |
| Czy wymaga testów? | Zalecane | Konieczne (bez testu plan jest tylko dokumentem) |
Co daje backup?
Backup to kopia danych z określonego punktu w czasie, czyli po prostu kopia zapasowa danych, tworzona z myślą o ich odzyskaniu. Jeśli ktoś zaszyfruje Wam serwer z bazą, backup pozwala przywrócić dane sprzed ataku. Problem pojawia się przy pytaniu: ile zajmie odtworzenie całego środowiska, nie tylko danych, ale też konfiguracji serwerów, zależności między systemami i dostępu użytkowników? W firmach bez planu DR odpowiedź brzmi zwykle: nie wiemy. Dobrą praktyką jest trzymanie kopii również poza siedzibą firmy, w chmurze lub na nośniku w innej lokalizacji, na przykład na nośniku typu zewnętrzny dysk twardy, dokładnie tak, jak zakłada zasada backupu 3-2-1, która stanowi fundament każdego skutecznego odtwarzania. To także podstawa regularnego tworzenia kopii zapasowych, które ogranicza ryzyko utraty danych. Warto też pamiętać, że dane w chmurze Microsoftu również wymagają własnej kopii zapasowej, jeśli chcecie skutecznie chronić swoich danych i zadbać o bezpieczeństwo danych, bo sam Microsoft nie chroni ich przed skasowaniem czy ransomware.
Co daje Disaster Recovery i odzyskiwanie danych?
Plan odtworzenia po awarii (DRP) to udokumentowany i przetestowany zestaw procedur przywracania usług do określonego poziomu działania w określonym czasie, czyli także plan awaryjny dla infrastruktury IT. Opiera się na dwóch parametrach: ich określenie oznacza wyznaczenie celów odzyskiwania.
- RTO (Recovery Time Objective) to maksymalny dopuszczalny czas przestoju. Ile godzin firma może nie działać, zanim straty staną się nieakceptowalne?
- RPO (Recovery Point Objective) to maksymalna dopuszczalna utrata danych. Dane z ostatniej godziny? Doby? Tygodnia?
Dobry plan DR określa RTO i RPO dla każdego krytycznego systemu, aby w przypadku awarii umożliwić przywrócenie kluczowych systemów oraz odzyskiwanie danych, a następnie sprawdza, czy przyjęte rozwiązania techniczne faktycznie te wartości gwarantują. Jeśli chcecie zobaczyć, jak taki dokument buduje się od podstaw, pokazujemy to krok po kroku w artykule o tym, jak przygotować plan disaster recovery. Backup bez zdefiniowanego RTO i RPO nie zastępuje planu odzyskiwania.
Kiedy backup wystarczy, a kiedy nie?
Jeśli firma toleruje przestój 24 godzin i utratę danych z ostatniej doby, backup bywa wystarczający dla części systemów. Ocena zależy jednak od konkretnej tolerancji przestoju. Jeśli prowadzicie sprzedaż online, obsługujecie klientów przez CRM albo zarządzacie produkcją, każda godzina przestoju ma wymierny koszt. Wtedy potrzebujecie DR, nie tylko kopii plików.
Ile kosztuje Disaster Recovery? Realne widełki dla MŚP
Koszt zależy od czterech zmiennych: wielkości środowiska IT, wymaganego RTO i RPO, modelu wdrożenia (chmura, hybryda, własna kolokacja) oraz tego, czy zarządzacie DR samodzielnie, czy w modelu outsourcowanym. Trzy najczęściej wybierane modele różnią się kosztem i progiem wejścia:
| Model wdrożenia | Jak działa | Model kosztu | Dla kogo |
|---|---|---|---|
| DR w chmurze | Replikacja środowiska lokalnego do chmury, uruchamianego przy awarii lub teście | Miesięczna opłata za pojemność i replikację, bez inwestycji w sprzęt | Większość MŚP szukających elastyczności |
| Managed DR (zarządzany) | Zewnętrzny dostawca konfiguruje, monitoruje, testuje i uruchamia procedury | Miesięczna subskrypcja zależna od zakresu systemów i SLA | Firmy bez własnych kompetencji IT |
| Własna infrastruktura (on-premises / kolokacja) | Fizyczne centrum zapasowe utrzymywane przez firmę | Wysoki koszt wejścia i utrzymania | Rygorystyczne RTO lub wymogi co do lokalizacji danych |
Disaster Recovery w chmurze
Rozwiązania chmurowe pozwalają replikować środowisko lokalne do chmury, wspierając szybkie odzyskiwanie usług po awarii, i uruchamiać je w przypadku wystąpienia awarii. Kluczowa zaleta: płacicie za pojemność i czas replikacji, nie za utrzymywanie własnej infrastruktury zapasowej. Zasoby uruchamiają się dopiero w momencie awarii lub testu, co obniża koszty względem stałego centrum zapasowego. Pomaga w tym także architektura wysokiej dostępności oraz rozmieszczenie zasobów w różnych lokalizacjach. Znaczenie mają też połączenia sieciowe, które usprawniają przełączenie usług. Miesięczny koszt dla typowej firmy MŚP zależy przede wszystkim od liczby chronionych systemów i częstotliwości replikacji, a nie od jednorazowego zakupu sprzętu. W praktyce, zależnie od modelu, to jak systemy w chmurze działają wpływa na koszt i czas odtworzenia.
Disaster Recovery w modelu zarządzanym (Managed DR)
Firmy bez zasobów do samodzielnego zarządzania środowiskiem DR mogą zlecić je zewnętrznemu dostawcy. Taki wariant bywa oferowany jako „Disaster Recovery as a Service”. Taka usługa obejmuje konfigurację, monitorowanie replikacji, testowanie planu, regularne testowanie procedur oraz gotowość do uruchomienia działań w razie realnej awarii. Rozliczana jest w modelu miesięcznej subskrypcji, zależnie od zakresu systemów i parametrów SLA, a rozwiązanie można dopasować do konkretnych potrzeb twojej firmy. Dla większości MŚP takie rozwiązania disaster pomagają ograniczyć koszty budowy kompetencji i środowiska wewnętrznego od zera. Wiele zależy tu również od doboru narzędzia do kopii zapasowych, a różnice między popularnymi rozwiązaniami rozkładamy na czynniki pierwsze w porównaniu Veeam i Acronis.
Tradycyjna infrastruktura DR (on-premises lub kolokacja)
Własne centrum zapasowe lub zapasowe centrum danych, ewentualnie kolokacja, to opcja dla organizacji o bardzo rygorystycznych wymogach RTO albo szczególnych wymaganiach co do lokalizacji danych. Bariera wejścia jest tu istotnie wyższa niż w chmurze, bo może to oznaczać także zapasowe centrum lub recovery center utrzymywane poza główną lokalizacją. Warto pamiętać, że część sektora finansowego podlega odrębnie rozporządzeniu DORA, a nie ścieżce KSC. Taki model bywa wybierany jako Disaster Recovery Center dla środowisk o najwyższych wymaganiach.
Co realnie wpływa na cenę?
- Zdefiniowane RTO i RPO: im krótszy dopuszczalny przestój, tym droższe rozwiązanie, a same parametry powinny wynikać ze strategii disaster recovery.
- Liczba i złożoność systemów krytycznych objętych planem w obszarze IT.
- Częstotliwość replikacji: co godzinę, co 15 minut czy w trybie ciągłym.
- Wymagania co do lokalizacji danych wynikające z RODO lub regulacji branżowych.
- Zakres i częstotliwość testów odtworzenia w ciągu roku.
Dobrze przygotowany kompleksowy plan pomaga ograniczyć ryzyko strat finansowych i lepiej wspiera zapewnienie ciągłości działania.
Najlepszy sposób na ustalenie realnego kosztu to rozmowa z konsultantem, który przeprowadzi wstępną inwentaryzację środowiska. Jeśli chcecie zacząć od audytu zgodności z NIS2, sprawdzimy przy okazji stan Waszego backupu i realną gotowość do odtworzenia.
Z naszej praktyki: dla jednego z klientów zaprojektowaliśmy działające disaster recovery, którego łączny koszt uruchomienia zamknął się poniżej 2000 zł, dzięki wynajmowi serwerów zamiast zakupu i replikacji do chmury zamiast własnej serwerowni zapasowej. To pokazuje, że o koszcie DR decyduje architektura, a nie wielkość budżetu. (Szczegóły techniczne pomijamy ze względu na poufność.)
Co NIS2 mówi o Disaster Recovery?
Dyrektywa NIS2 wymienia disaster recovery wprost, w art. 21 ust. 2 lit. c, wśród środków zarządzania ryzykiem: „ciągłość działania, taka jak zarządzanie kopiami zapasowymi i odtwarzanie po awarii, oraz zarządzanie kryzysowe”. Rozporządzenie wykonawcze Komisji (UE) 2024/2690 rozbija ten obowiązek na ponad dwadzieścia konkretnych, możliwych do wykazania wymagań i to nim od cyklu audytowego z 2026 roku posługują się audytorzy. Polska nowelizacja ustawy o KSC weszła w życie 3 kwietnia 2026 roku i nakłada te obowiązki na podmioty ważne i kluczowe.
Ciągłość działania i zarządzanie kryzysowe
Firmy objęte NIS2 muszą posiadać i utrzymywać plany ciągłości działania (BCP, Business Continuity Plan) oraz plany odtwarzania po awarii (DRP). BCP odpowiada za business continuity i utrzymanie ciągłości biznesowej. Plan musi być udokumentowany i przetestowany, bo sam dokument bez dowodu skuteczności nie wystarczy przy kontroli. Więcej o tym, co dokładnie weryfikuje kontrola, opisujemy w artykule o zakresie i przebiegu audytu NIS2. Oba plany mają chronić kluczowe obszary funkcjonowania przedsiębiorstwa także w sytuacji kryzysowej.
Zarządzanie ryzykiem IT
NIS2 wymaga identyfikacji i oceny ryzyka oraz analizę ryzyka dla systemów informatycznych. Brak planu DR to udokumentowane ryzyko, które organizacja powinna mieć w rejestrze ryzyk i wobec którego powinna podjąć działania ograniczające jego skutki. To jeden z pierwszych obszarów sprawdzanych podczas kontroli. W praktyce obejmuje to także Business Impact Analysis, która pomaga oszacować wpływ incydentu i ich skutków dla organizacji.
Zgłaszanie incydentów i odtwarzanie usług
NIS2 i ustawa o KSC wymagają zdolności do zgłaszania poważnych incydentów w trzech etapach:
| Etap | Termin od wykrycia | Co zawiera |
|---|---|---|
| Wczesne ostrzeżenie | do 24 godzin | Wstępna informacja o incydencie |
| Pełne zgłoszenie | do 72 godzin | Ocena powagi, skutków i wskaźniki kompromitacji |
| Raport końcowy | do 1 miesiąca | Analiza przyczyn i podjęte działania naprawcze |
Jeśli firma nie ma przetestowanego planu DR, realny czas odtworzenia po poważnym incydencie lub poważnej awarii może przekroczyć nie tylko Wasze oczekiwania, ale i wymagania regulacyjne. Przygotowane procedury powinny jasno wskazywać, jakie działania należy podjąć w przypadku awarii i po wystąpieniu awarii usług. Konsekwencje bywają dotkliwe. Kary za brak zgodności z NIS2 sięgają 10 mln € lub 2% obrotu dla podmiotów kluczowych i 7 mln € lub 1,4% dla ważnych, a odpowiedzialność ponosi też osobiście zarząd.
Audyt backupu i DR jako element audytu NIS2
Jeśli zamawiacie audyt zgodności z NIS2, weryfikacja backupu i gotowości do odtworzenia jest jego integralną częścią. To obszar, w którym firmy najczęściej ujawniają luki: backup istnieje, ale nie ma zdefiniowanego RTO, przetestowanego procesu odtworzenia ani dokumentacji potwierdzającej skuteczność. Jak zebrać dokumentację i przygotować zespół, tłumaczymy w poradniku o tym, jak przygotować się do audytu NIS2.
Jak wdrożyć Disaster Recovery? Praktyczny punkt startowy
Wdrożenie DR nie zaczyna się od wyboru technologii, tylko od odpowiedzi na pytania, które większość firm pomija.
Krok 1: Zidentyfikuj systemy krytyczne
Które systemy, jeśli przestaną działać na cztery godziny, realnie wpłyną na przychody lub obsługę klientów? ERP, CRM, systemy transakcyjne, serwery produkcyjne, kluczowe bazy danych — czyli systemy krytyczne, formalnie zaliczane do kluczowych systemów. Lista powinna być krótka i precyzyjna. Próba objęcia planem całego środowiska naraz to najczęstsza przyczyna niepowodzeń w MŚP. Chodzi o priorytetyzację zasobów twojej firmy zgodnie z ich realnym wpływem na działalność.
Krok 2: Zdefiniuj RTO (recovery time objective) i RPO dla każdego systemu
Ile czasu firma może nie działać bez nieakceptowalnych strat i ile danych może utracić, należy ustalić na podstawie konkretnych potrzeb biznesu. Te parametry determinują wybór technologii i bezpośrednio wpływają na koszt. To podstawowy etap tworzenia planu disaster dla najważniejszych usług. Bez nich każda rozmowa o DR to rozmowa bez budżetu.
Krok 3: Oceń istniejący backup pod kątem realnego odtworzenia
Czy ktokolwiek w firmie przeprowadził test odtworzenia środowiska produkcyjnego w ciągu ostatnich 12 miesięcy? 93% firm bez dostępu do danych przez 10 dni upada. Czy backup pozwala odbudować pełny serwer lub aplikację w nowym środowisku, a nie tylko odczytać pojedynczy plik, lecz także przywrócić pełne kopie zapasowe i kopii bezpieczeństwa potrzebne do odtworzenia środowiska? Jeśli nie, nie znacie swojego rzeczywistego RTO, a problem może wynikać także z awarie sprzętu albo błędu pracownika.
Krok 4: Wybierz model wdrożenia adekwatny do skali i budżetu
Dla większości MŚP optymalnym startem jest replikacja do chmury z RTO na poziomie od dwóch do ośmiu godzin. W praktyce różne rodzaje disaster recovery dobiera się tu do skali firmy, budżetu i krytyczności systemów. Nie wymaga własnej infrastruktury zapasowej i można ją wdrażać stopniowo, zaczynając od systemów o najwyższym priorytecie; wybrany model powinien też wspierać zapewnienie ciągłości działania także w wypadek awarii najważniejszych usług.
Krok 5: Udokumentuj disaster recovery plan i testuj go regularnie
Plan DR bez testów to dokument, nie zabezpieczenie, dlatego skuteczny dokument powinien zawierać Disaster Recovery Plan z opisem procedur i odpowiedzialności. Przetestowane procedury, zapisany wynik testu i harmonogram kolejnych testów mają realną wartość dowodową podczas audytu NIS2 lub kontroli KSC. Zespół odpowiedzialny za odzyskiwanie powinien mieć jasno określone role. Po każdej istotnej zmianie w infrastrukturze IT plan trzeba zaktualizować. Bez tego nawet dobrze skonfigurowane środowisko nie wystarczy do wykazania zgodności, bo potrzebne jest także regularne przeprowadzanie testów oraz aktualizacji po zmianach w środowisku.
Podsumowanie: disaster recovery to decyzja biznesowa, nie zakup sprzętu
Największe nieporozumienie wokół disaster recovery polega na tym, że traktuje się je jak drogi projekt infrastrukturalny, a nie jak odpowiedź na proste pytanie: ile kosztuje Was godzina przestoju? Gdy zestawicie ten koszt z ceną dobrze zaprojektowanego DR w chmurze lub w modelu zarządzanym, rachunek najczęściej wychodzi na korzyść przygotowania. A od kwietnia 2026 roku, dla firm objętych NIS2, to już nie kalkulacja opłacalności, tylko obowiązek, którego brak kontrola potrafi wychwycić w pierwszej kolejności.
Nie musicie zaczynać od dużego wdrożenia. Wystarczy jeden krok: policzcie, które systemy naprawdę muszą działać, ustalcie dla nich RTO i RPO, a potem sprawdźcie, czy Wasz obecny backup faktycznie pozwala je odtworzyć. Jeśli odpowiedź brzmi „nie wiemy”, to najlepszy moment, żeby to zmienić, zanim zrobi to za Was awaria albo audytor. Umówcie się na audyt NIS2, a przejdziemy tę drogę razem z Wami, od inwentaryzacji środowiska po gotowy, przetestowany plan.