Niezmienne kopie zapasowe WORM i testy Disaster Recovery w uKSC i NIS2 – dlaczego zwykły backup to za mało?

Kopia zapasowa to nie plik zapisany na dodatkowym dysku. Kopia zapasowa to udowodniona zdolność powrotu firmy do normalnego działania po awarii lub cyberataku. W realiach znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa (uKSC) oraz dyrektywy NIS2 posiadanie zwykłego backupu w tej samej sieci co serwery produkcyjne daje jedynie złudne poczucie bezpieczeństwa. Współczesne grupy ransomware zaczynają atak od wyszukania i skasowania punktów przywracania, zanim zaszyfrują pierwszą bazę danych. Z kolei audytorzy weryfikujący zgodność z uKSC nie pytają już, czy firma „robi backup”, lecz żądają dowodów na odporność kopii przed usunięciem (WORM / Offline), separację lokalizacji oraz raportów z realnych testów odtworzeniowych, które potwierdzają, w ile godzin biznes faktycznie wróci do pracy.

Dlaczego zwykły backup znika razem z produkcją podczas ataku ransomware i nie przechodzi kontroli uKSC?

W niemal każdej firmie, która zgłasza się do nas po incydencie bezpieczeństwa lub przed audytem zgodności, słyszymy na początku to samo zdanie – „mamy ustawione automatyczne kopie zapasowe, robią się każdej nocy”.

Problem polega na tym, że większość tych systemów projektowano kilka lat temu z myślą o jednym, prostym scenariuszu – awarii pojedynczego dysku twardego albo przypadkowym skasowaniu pliku przez pracownika. W zderzeniu z dzisiejszymi metodami cyberprzestępców oraz wymogami prawa taka konstrukcja rozpada się w ciągu kilkunastu minut.

Jak działają współczesne grupy ransomware i dlaczego najpierw celują w kopie zapasowe?

Wyobrażenie o ataku hakerskim jako o złośliwym programie, który od razu po kliknięciu w załącznik blokuje ekrany komputerów, dawno straciło aktualność. Dzisiejsze ataki na firmy produkcyjne, platformy e‑commerce, spółki logistyczne czy dostawców IT to starannie zaplanowane operacje.

Gdy włamywacze dostaną się do wewnętrznej sieci firmy (np. przez przejęte hasło pracownika lub niezałątaną lukę w oprogramowaniu), nie uruchamiają szyfrowania od razu. Zamiast tego przez wiele dni po cichu rozpoznają środowisko, podnoszą swoje uprawnienia aż do poziomu głównego administratora i szukają odpowiedzi na jedno pytanie – gdzie ta firma trzyma swoje kopie zapasowe?

Napastnicy doskonale wiedzą, że dopóki zarząd dysponuje działającym backupem, nie zapłaci ani złotówki okupu, tylko odtworzy serwery i wróci do pracy.

Dlatego właściwe uderzenie przebiega zawsze w dwóch krokach. Najpierw przestępcy wykorzystują przejęte konto administratora, aby zalogować się do systemu backupu i bezpowrotnie usunąć wszystkie zapisane kopie, a dopiero chwilę później uruchamiają proces szyfrowania głównych serwerów produkcyjnych.

W tym momencie na jaw wychodzą trzy najczęstsze błędy w firmowej infrastrukturze:

• Kopia zapasowa na tym samym serwerze lub macierzy (tzw. lokalne migawki / snapshoty) – jeśli kopia leży na tych samych dyskach co działający system, pojedyncza awaria sprzętu, pożar w serwerowni lub zaszyfrowanie głównej maszyny niszczy jednocześnie dane produkcyjne oraz ich zapas.
• Wspólne hasła i jedna sieć dla produkcji oraz backupu – gdy serwer kopii zapasowych jest podpięty do tej samej sieci firmowej i korzysta z tego samego systemu logowania co reszta komputerów, włamywacz po zdobyciu hasła administratora ma otwartą drogę do wyczyszczenia całego archiwum jednym poleceniem.
• Brak kopii w innej lokalizacji geograficznej – przechowywanie wszystkich danych w jednym budynku lub w jednym centrum danych sprawia, że poważna awaria zasilania, zalanie czy pożar obiektu całkowicie zatrzymuje działalność przedsiębiorstwa.

Skutek biznesowy takiego scenariusza jest dramatyczny. Firma z dnia na dzień traci dostęp do systemu finansowo‑księgowego, bazy zamówień czy oprogramowania sterującego produkcją, nie mając z czego odtworzyć danych. Taki paraliż oznacza nie tylko ogromne straty z tytułu przestoju, ale też obowiązek natychmiastowego raportowania incydentu poważnego w 24h do CSIRT NASK oraz ryzyko dotkliwych kar finansowych dla spółki i zarządu, które szczegółowo omówiliśmy w artykule o kwalifikacji podmiotu w uKSC i rejestracji w S46.

Czego oczekuje audytor weryfikujący ciągłość działania w ramach uKSC i NIS2?

Nowelizacja ustawy o KSC oraz unijna dyrektywa NIS2 (w szczególności art. 21 ust. 2 lit. c) stawiają sprawę jasno – każdy podmiot kluczowy i ważny ma prawny obowiązek zapewnić ciągłość działania (Business Continuity), bezpieczne zarządzanie kopiami zapasowymi oraz plany przywracania normalnego trybu pracy po awarii (Disaster Recovery).

Co to oznacza podczas rzeczywistej kontroli lub audytu bezpieczeństwa prowadzonego przez dużego kontrahenta B2B?

Audytor nie zadowoli się już ogólnym zdaniem w segregatorze mówiącym o tym, że „organizacja wykonuje regularne kopie zapasowe”. Zamiast tego poprosi o wykazanie czterech konkretnych faktów operacyjnych:

1. Jak zabezpieczono kopie przed skasowaniem przy włamaniu – czy system posiada blokadę uniemożliwiającą usunięcie backupu nawet osobie dysponującej hasłem głównego administratora?
2. Gdzie fizycznie znajdują się dane – czy kopie są przesyłane do odrębnej lokalizacji geograficznej i czy istnieje warstwa odizolowana od bieżącego dostępu z sieci (tzw. kopia Offline)?
3. Kto pilnuje, czy kopie faktycznie się robią – czy firma ma stały monitoring zadań backupowych, który natychmiast wykryje błąd zapisu lub brak wolnego miejsca na dyskach?
4. Ile realnie trwa podniesienie systemu z kopii – kiedy ostatnio przeprowadzono praktyczny test odtworzeniowy i jakim wynikiem czasowym się zakończył?

Wniosek dla zarządu i dyrektorów IT – w świetle uKSC posiadanie kopii zapasowej, którą napastnik może skasować w pięć minut po włamaniu albo której nikt nigdy nie próbował odtworzyć, jest traktowane na równi z brakiem zabezpieczeń. Ustawa rozlicza firmę ze skuteczności powrotu do działania, a nie z samego faktu posiadania dysków z archiwami.

Aby ułatwić ocenę obecnego stanu bezpieczeństwa w Twojej organizacji, zestawiliśmy trzy najpopularniejsze podejścia do kopii zapasowych wraz z ich zachowaniem podczas kryzysu oraz oceną w świetle wymogów uKSC.

Architektura 3‑poziomowa, niezmienność zapisu WORM i kontrola dostępu – jak chronić kopie przed skasowaniem

Skoro pojedyncza kopia trzymana w firmowej serwerowni nie daje ochrony przed pożarem budynku ani przed atakiem ransomware, jak zaprojektować system, który przetrwa oba te scenariusze jednocześnie?

Kluczem jest odejście od myślenia o backupie jako o „jednym miejscu na dysku” na rzecz wielopoziomowej izolacji danych oraz twardej blokady przed ich usunięciem.

Trzy poziomy lokalizacji kopii zapasowych (On‑site, Remote, Offline)

W profesjonalnej architekturze ciągłości działania – takiej, jaką wdrażamy w ramach usługi Centuria Backup – ochrona danych opiera się na trzech uzupełniających się poziomach lokalizacji. Każdy z nich odpowiada na zupełnie inne ryzyko biznesowe i techniczne:

1. Poziom On‑site (kopia lokalna) – pierwsza kopia zapasowa jest zapisywana na odseparowanej infrastrukturze w tej samej lokalizacji (tym samym centrum danych), w której pracuje główny serwer klienta. Jej największą zaletą jest szybkość. Gdy pracownik przypadkowo usunie ważny katalog albo aktualizacja oprogramowania wprowadzi błąd w konfiguracji, administratorzy mogą przywrócić dane niemal natychmiast, bez konieczności przesyłania terabajtów informacji z odległego ośrodka.
2. Poziom Remote (kopia w innej lokalizacji geograficznej) – oprócz kopii lokalnej system automatycznie przesyła zaszyfrowaną kopię zapasową do drugiego, fizycznie oddalonego centrum danych. Jeżeli w głównym obiekcie dojdzie do poważnej awarii zasilania, uszkodzenia sprzętu lub pożaru, firma nie traci dorobku i może odtworzyć całe środowisko w zapasowej lokalizacji.
3. Poziom Offline (kopia całkowicie odcięta od sieci) – najwyższy stopień zabezpieczenia, łączący kopię lokalną oraz zdalną z dodatkową kopią Offline (np. zapisywaną na fizycznych nośnikach taśmowych w odrębnej lokalizacji geograficznej). Ponieważ nośnik offline po zakończeniu zapisu nie jest widoczny w bieżącej sieci komputerowej, żaden zdalny haker ani program szyfrujący nie ma fizycznej możliwości, aby się do niego dostać.

Takie stopniowanie pozwala precyzyjnie dopasować poziom ochrony do wartości danych. Mniej istotne systemy pomocnicze mogą korzystać z wariantu podstawowego, podczas gdy główne bazy transakcyjne, systemy finansowe czy dokumentacja produkcyjna są chronione na wszystkich trzech poziomach jednocześnie.

Blokada przed usunięciem (WORM i funkcja „Protected”) oraz separacja środowisk

Sama obecność kopii w drugim mieście nie wystarczy jednak, jeśli włamywacz po zdobyciu hasła administratora będzie mógł wysłać przez sieć polecenie skasowania wszystkich archiwów. Aby temu zapobiec, nowoczesny system kopii zapasowych wykorzystuje dwa mechanizmy obronne – separację infrastruktury oraz niezmienność zapisu.

Separacja oznacza, że system backupowy stanowi całkowicie odrębne środowisko, odgrodzone sieciowo od serwerów produkcyjnych. Nawet jeśli serwer sklepu internetowego lub systemu ERP zostanie przejęty przez przestępców, z jego poziomu nie da się zarządzać magazynem kopii zapasowych ani wydawać mu poleceń usunięcia danych.

Drugim filarem jest technologia WORM (Write Once, Read Many), co w prostym tłumaczeniu oznacza zasadę „zapisz raz, odczytuj wielokrotnie”.

Jak działa to w praktyce? W momencie, gdy kopia zapasowa zostaje poprawnie zapisana w repozytorium, system nakłada na nią elektroniczną blokadę czasową na ustalony okres przechowywania (np. 14 lub 30 dni). Dopóki ten zegar nie dobiegnie końca, plików kopii nie da się nadpisać, zaszyfrować ani skasować – nawet gdyby próbowała to zrobić osoba posiadająca najwyższe uprawnienia administracyjne w firmie.

Równolegle w rozwiązaniach Centurii stosujemy funkcję „Protected” dla wskazanych przez klienta kopii zapasowych. W każdym systemie backupowym działa automatyczna rotacja – gdy mija ustalony czas przechowywania, najstarsze kopie są usuwane, aby zrobić miejsce na nowe. Oznaczenie strategicznej kopii (np. z zamknięcia roku obrachunkowego, końca kwartału albo sprzed wielkiej przebudowy systemu) flagą Protected wyłącza ją z automatycznego czyszczenia i gwarantuje, że ten konkretny punkt w czasie pozostanie bezpiecznie zachowany tak długo, jak potrzebuje tego biznes.

Dlaczego system musi alarmować, gdy do kopii zapasowej próbuje zalogować się człowiek?

Projektując zabezpieczenia pod wymogi uKSC i NIS2, warto zwrócić uwagę na jeszcze jeden szczegół operacyjny, o którym zapomina większość tradycyjnych działów IT.

W prawidłowo wdrożonym systemie cały proces tworzenia, przesyłania i weryfikacji kopii zapasowych odbywa się w stu procentach automatycznie. Codziennie o wyznaczonych godzinach (np. o 00.00, 04.00, 08.00 czy 12.00) zadania wykonują dedykowane skrypty i procesy systemowe – żaden pracownik nie musi ręcznie logować się do magazynu kopii, aby przekopiować pliki.

Co zatem oznacza sytuacja, w której do repozytorium kopii zapasowych nagle loguje się człowiek?

Jeżeli firma nie prowadzi w tej właśnie chwili zaplanowanego odtwarzania danych po awarii ani umówionego testu, ręczne wejście człowieka do zasobów backupowych jest jednym z najsilniejszych sygnałów ostrzegawczych o trwającym włamaniu lub próbie sabotażu wewnętrznego.

Detekcja dostępu człowieka w standardzie Centurii – nasz system monitoringu kopii zapasowych śledzi nie tylko poprawność wykonania zadań czy wolne miejsce na dyskach, ale również każdy przypadek uzyskania dostępu do kopii zapasowej przez człowieka (czyli połączenie inne niż ze strony automatycznych skryptów tworzących backup). Takie zdarzenie natychmiast wywołuje alarm o wysokim priorytecie w naszym całodobowym monitoringu serwerów 24/7/365, pozwalając dyżurnemu zespołowi zablokować podejrzaną sesję, zanim ktokolwiek spróbuje pobrać lub uszkodzić archiwa.

Parametry RPO i RTO przełożone na język biznesu – ile danych i ile godzin przestoju możesz stracić?

Kiedy podczas rozmowy o ciągłości działania i wymogach uKSC pada pytanie o kopie zapasowe, zarządy oraz działy IT często mówią dwoma różnymi językami. Administratorzy skupiają się na pojemności dysków w terabajtach i harmonogramach zadań, natomiast prezes chce wiedzieć jedno – jak szybko po awarii firma znów zacznie sprzedawać i czy stracimy dzisiejsze zamówienia klientów?

Aby połączyć te dwie perspektywy i precyzyjnie zaplanować ochronę pod kontrolę nadzorczą, używa się dwóch podstawowych parametrów – RPO oraz RTO.

Jak rozumieć wskaźniki RPO i RTO bez technicznego żargonu?

Oba skróty opisują granicę wytrzymałości Twojego biznesu na skutki awarii, ale każdy z nich patrzy w inną stronę osi czasu – jeden w przeszłość, a drugi w przyszłość od momentu usterki:

• RPO (Recovery Point Objective) – maksymalna dopuszczalna utrata danych mierzona w czasie. Ten wskaźnik odpowiada na pytanie, z ilu ostatnich godzin lub minut firma może stracić dane, jeśli serwer padnie w tej sekundzie. Przykładowo RPO równe 4 godziny oznacza, że kopie wykonują się w czterogodzinnych odstępach (np. o 00.00, 04.00, 08.00, 12.00, 16.00 i 20.00), więc w najgorszym scenariuszu stracisz zmiany wprowadzone do systemu w ciągu ostatnich czterech godzin.
• RTO (Recovery Time Objective) – maksymalny czas przestoju systemu. Ten parametr określa, ile dokładnie czasu potrzebuje zespół techniczny od momentu podjęcia decyzji o przywróceniu kopii zapasowej do chwili, gdy odzyskano dane, przywrócono pełną sprawność systemu i klienci mogą znów normalnie korzystać z usługi.

W praktyce dobrze zaprojektowana polityka ciągłości działania nigdy nie narzuca jednego, sztywnego wskaźnika dla całej firmy na ślepo.

W ramach jednego środowiska ustala się różne wartości RPO i RTO w zależności od krytyczności poszczególnych usług. Główna baza danych sklepu internetowego lub systemu finansowego może być zabezpieczana co kilka godzin (albo w sposób ciągły), podczas gdy pomocniczy serwer wirtualny, na którym dane zmieniają się rzadko, wystarczy archiwizować raz w tygodniu w niedzielę.

Jak nowoczesne metody skracają straty z godzin do minut i sekund (bez zatrzymywania biznesu)?

Tradycyjne podejście do kopii zapasowych zmuszało firmy do trudnego kompromisu. Wykonywanie pełnej kopii dużej bazy danych w środku dnia potrafiło mocno obciążyć lub wręcz zablokować serwer, paraliżując działanie sklepu internetowego w godzinach szczytu. Z tego powodu firmy robiły backup tylko raz na dobę – w środku nocy – godząc się z tym, że awaria o godzinie 16.00 oznacza utratę całodniowego utargu i pracy kilkudziesięciu ludzi.

Współczesne rozwiązania z rodziny Centuria Backup całkowicie eliminują ten problem dzięki trzem mechanizmom:

1. Kopie zapasowe Online (bez przestojów produkcyjnych) – zrzuty baz danych oraz kopie maszyn wykonują się w trakcie normalnego, rzeczywistego działania systemu. Klienci składają zamówienia na stronie, a proces archiwizacji pracuje w tle, nie wpływając na dostępność ani szybkość ładowania usługi.
2. Odtwarzanie bazy do wybranego punktu w czasie (PITR – Point‑In‑Time Recovery) – w systemach bazodanowych opartych na oprogramowaniu PostgreSQL, gdzie utrata transakcji z ostatnich minut oznacza bezpośrednią stratę finansową, oprócz standardowych kopii przechowujemy na bieżąco dzienniki transakcji. Dzięki temu RPO spada do poziomu pojedynczych sekund. Jeżeli o godzinie 14.35 podczas aktualizacji aplikacji dojdzie do błędu ludzkiego lub skasowania tabeli, nie trzeba przywracać całego systemu z poprzedniej nocy ani zatrzymywać firmy na długie godziny – bazę danych można „cofnąć w czasie” dokładnie do stanu z godziny 14.34.59, na sekundę przed awarią.
3. Natychmiastowy start maszyny z kopii (Live‑Restore) oraz deduplikacja – przy ochronie serwerów wirtualnych przesyłamy wyłącznie zmienione bloki danych (kopie przyrostowe) i eliminujemy powtarzające się informacje (deduplikacja). Największy przełom widać jednak w chwili kryzysu. Zamiast czekać wiele godzin, aż terabajty danych przekopiują się na nowy serwer, funkcja Live‑Restore pozwala uruchomić maszynę wirtualną w czasie rzeczywistym bezpośrednio z kopii zapasowej, skracając czas przestoju (RTO) do absolutnego minimum.

Dobór modelu kopii zapasowej do potrzeb środowiska

Ponieważ każda warstwa firmowej infrastruktury stawia inne wyzwania – od pojedynczych baz danych, przez środowiska wirtualne, aż po setki rozproszonych serwerów w chmurze publicznej – w Centurii podzieliliśmy architekturę backupu na pięć wyspecjalizowanych modułów. Poniższe zestawienie pokazuje, który wariant odpowiada na konkretne problemy biznesowe i wymogi ciągłości działania.

„Mamy kopie, ale nie wiemy, czy działają” – stały monitoring zadań i testy odtworzeniowe pod uKSC

Samo skonfigurowanie harmonogramu kopii zapasowych to dopiero połowa drogi. Jednym z najgroźniejszych złudzeń w zarządzaniu IT jest przekonanie, że skoro system backupowy został uruchomiony rok temu i nie wysyła komunikatów o błędach na skrzynkę prezesa, to dane firmy są bezpieczne.

W rzeczywistości środowisko informatyczne żyje i zmienia się każdego dnia. Przybywa nowych towarów w sklepie, rosną bazy danych, zmieniają się hasła dostępowe i wygasają certyfikaty.

Dlaczego sam harmonogram nie wystarczy i po co monitoruje się każdą kopię?

Podczas audytów infrastruktury regularnie spotykamy sytuację, w której firma jest przekonana, że posiada codzienne kopie zapasowe, po czym okazuje się, że ostatni poprawny zapis wykonał się kilka miesięcy wcześniej. Dlaczego tak się dzieje? Powodem bywa prozaiczny brak wolnego miejsca na dysku, zmiana uprawnień po aktualizacji systemu albo błąd skryptu, który zamiast pełnej bazy danych zaczął codziennie zapisywać pusty plik o rozmiarze zero megabajtów.

Aby wyeliminować ryzyko takiej niespodzianki w dniu awarii, system kopii zapasowych w Centurii podlega stałemu, aktywnemu monitoringowi.

Nasz nadzór obejmuje wszystkie punkty, w których proces archiwizacji może zawieść:

• Status wykonania i kompletność każdego zadania – sprawdzamy nie tylko to, czy zadanie wystartowało o wyznaczonej godzinie, ale czy zakończyło się pełnym sukcesem i czy rozmiar zapisanej kopii nie odbiega podejrzanie od normy.
• Kontrola czasu trwania i dostępności repozytorium – system natychmiast wykrywa sytuacje, w których tworzenie kopii trwa zbyt długo (co mogłoby świadczyć o problemach z wydajnością sieci lub dysków) albo gdy magazyn danych staje się niedostępny.
• Nadzór nad wolną przestrzenią dyskową – monitorujemy tempo przyrostu danych z wyprzedzeniem, aby wyczerpujące się miejsce nigdy nie zatrzymało nocnego zapisu.
• Jedno centralne źródło prawdy (Single Source of Truth) – nawet jeśli firma korzystała wcześniej z wielu rozproszonych skryptów tworzących kopie różnych baz danych, porządkujemy je i spinamy w centralnej platformie raportowania bez konieczności burzenia dotychczasowych rozwiązań.

Gdy monitoring wychwyci jakikolwiek błąd – na przykład niewykonanie się kopii bazy danych o godzinie 04.00 rano – informacja nie trafia do próżni. Zespół realizujący usługę od razu podejmuje interwencję w ramach ustalonego czasu reakcji SLA i naprawia przyczynę problemu, zanim ktokolwiek w firmie będzie potrzebował sięgnąć po ten backup.

Testy odtworzeniowe (Recovery Drills) – jedyny sposób, by poznać prawdziwy czas powrotu do pracy (RTO)

Nawet najlepiej monitorowana kopia zapasowa wymaga ostatecznego sprawdzianu, jakim jest praktyczny test odtworzeniowy.

Dopóki zespół techniczny nie przeprowadzi w kontrolowanych warunkach próby przywrócenia systemu z kopii zapasowej, wpisany do firmowych procedur czas RTO pozostaje wyłącznie życzeniem na papierze. Dopiero podczas realnego odtwarzania wychodzą na jaw wąskie gardła – na przykład to, jak długo trwa indeksowanie dużej bazy danych po starcie serwera albo czy zewnętrzne integracje z systemami płatności i kurierami uruchamiają się prawidłowo w zapasowej lokalizacji.

Dlaczego warto kontraktować regularne testy odtworzeniowe? W Centurii planujemy i przeprowadzamy cykliczne próby przywrócenia środowiska (np. raz na kwartał) w ściśle ustalonych terminach. Nasi inżynierowie odtwarzają system z kopii zapasowej w bezpiecznych, kontrolowanych warunkach, a wyznaczone osoby po stronie klienta weryfikują, czy aplikacja i dane biznesowe działają bez zarzutu.

Taki sprawdzian daje organizacji dwie wymierne korzyści:

1. Twardą wiedzę biznesową dla zarządu – dokładnie wiesz, jakie rzeczywiste RTO jesteśmy w stanie zapewnić Twojej firmie i ile godzin potrwa powrót do pełnej sprawności w razie prawdziwej katastrofy.
2. Gotowy dowód na wypadek kontroli uKSC i NIS2 – udokumentowany przebieg testu odtworzeniowego to najsilniejszy argument dla audytora potwierdzający, że projektowanie i weryfikacja planu Disaster Recovery w Twojej spółce działa w praktyce, a nie tylko w segregatorze.

Jak w 14 dni uporządkować ochronę danych i precyzyjnie dobrać przestrzeń na kopie?

Wielu dyrektorów IT oraz członków zarządu odkłada decyzję o wdrożeniu profesjonalnego, wielopoziomowego backupu z jednego powodu – obawiają się, że już na starcie będą musieli oszacować w ciemno docelową pojemność dysków i płacić za terabajty nieużywanej przestrzeni zamówionej „na wszelki wypadek”.

Dzieje się tak dlatego, że rzeczywista ilość miejsca potrzebna na kopie zapasowe zawsze przekracza sam rozmiar danych na serwerze produkcyjnym. Wynika to z prostej zasady bezpieczeństwa – system rotacji nigdy nie usuwa starszych kopii, dopóki nowe archiwum nie zostanie w całości i bezbłędnie zapisane w repozytorium.

Aby zdjąć z klienta ryzyko nietrafionych szacunków i przepłacania za przestrzeń, wdrożenie w Centurii oparliśmy na przejrzystym modelu pomiarowym:

• Krok 1 – Ustalenie parametrów biznesowych i harmonogramu. Wspólnie określamy, które serwery i bazy danych obejmujemy ochroną, jakie czasy RPO i RTO są akceptowalne dla biznesu, jak daleko w przeszłość chcemy się cofać (np. 14 dni kopii codziennych z godziny 00.00 oraz zachowanie 8 kopii tygodniowych i 12 miesięcznych) oraz które kopie wymagają izolacji geograficznej (Remote) lub odcięcia od sieci (Offline).
• Krok 2 – Bezpieczna rezerwacja i 14‑dniowy okres pomiarowy. Na start uruchamiamy usługę z bezpiecznym zapasem miejsca (zazwyczaj na poziomie 150–250% wolumenu danych źródłowych, w zależności od wybranej polityki przechowywania). Następnie przez pierwsze 14 dni dokładnie monitorujemy proces tworzenia kopii i rzeczywisty przyrost danych, aby po dwóch tygodniach dopasować docelowy wolumen i rozliczać się wyłącznie za przestrzeń, której Twoje środowisko faktycznie potrzebuje.
• Krok 3 – Pełna weryfikacja powdrożeniowa. Usługę uznajemy za uruchomioną dopiero wtedy, gdy wykonamy co najmniej jedną w pełni poprawną kopię zapasową, sprawdzimy zgodność retencji i harmonogramów z dokumentacją, uruchomimy stały monitoring zadań ze ścieżką obsługi błędów oraz – jeśli zostało to ujęte w zakresie – przeprowadzimy test odtworzenia.

Nie czekaj, aż awaria macierzy dyskowej, błąd podczas aktualizacji albo atak ransomware sprawdzi wytrzymałość obecnych skryptów na żywym organizmie Twojej firmy. Sprawdź, jak wyglądają plany Disaster Recovery Plan i audyt infrastruktury pod NIS2 realizowane przez zespół Centurii – porozmawiajmy o tym, co i na jakich warunkach Twoje środowisko będzie w stanie odtworzyć, gdy wydarzy się sytuacja krytyczna.