Backup i odtwarzanie: co wymagać przed podpisaniem umowy

  • QData

TL;DR

  • „Mamy backupy” to nie klauzula umowna — wymagajcie RPO/RTO per tier, daty ostatniego testu restore i nazwanej osoby odpowiedzialnej.
  • Testy odtwarzania muszą dać podpisany raport dla audytorów, ubezpieczyciela i zarządu — nie ustne „działało”.
  • Pytajcie o ransomware: niezmienność kopii, odseparowanie credentiali, odtworzenie bez płacenia okupu jako pierwszej opcji.
  • Jeśli dostawca nie wyjaśni czasu odtworzenia ERP czy plików prostym językiem — traktujcie backup jako nieudowodniony.

Dyrektor finansowy pytał nas ostatnio, czemu „w pełni zarządzany” hosting nie mógł pokazać raportu z odtwarzania młodszego niż czternaście miesięcy. Backupy szły nocą, dashboardy były zielone. Na tabletopie ransomware nikt nie wiedział, czy kopia off-site jest dostępna bez skompromitowanego konta admina. Umowa mówiła o „standardzie branżowym” — czyli checkboxie w ofercie.

Backup to miejsce, gdzie umowy IT wyglądają najtaniej, a kosztują najdrożej po awarii. Ten poradnik jest dla właścicieli, CFO i kierowników IT, którzy oceniają oferty bez zostawania inżynierami backupu — ale chcą dowodów, nie nadziei.

Co powinno znaczyć „backup w zakresie”

Co jest backupowane: sam OS, dane aplikacji, bazy ze spójnymi snapshotami, tenant SaaS, całe VM. Gdzie leżą kopie: ten sam DC, u partnera, object storage w innym regionie, taśma offline. Kto może je skasować — wspólny admin z produkcją to częsty błąd.

Dobry dokument zakresu wymienia systemy po nazwie lub tierze, podaje retencję i szyfrowanie, oraz czy dostajecie pliki restore bezpośrednio czy tylko przez dostawcę.

RPO i RTO — na piśmie, przy systemach biznesowych

RPO — ile danych możecie stracić. RTO — jak długo może trwać odtworzenie, zanim biznes przestanie czekać.

Wymagajcie tabeli w umowie lub opisie usługi: tier-1 (ERP, poczta, front) RPO/RTO, tier-2 (narzędzia wewnętrzne), tier-3 (archiwum, dev). Jedna liczba „dla wszystkiego” oznacza brak przemyślenia. Brak liczb na piśmie — zakładajcie najgorszy scenariusz.

Testy restore — jedyny dowód

Backupy bez odtwarzania to inwentarz, nie ubezpieczenie. Kiedy ostatni udany test u klienta podobnej skali? Kto był świadkiem? Ile trwało pełne odtworzenie vs RTO? Jest podpisany raport lub export ticketu?

Kwartalny restore co najmniej jednego systemu tier-1 to rozsądne minimum dla firm średniej wielkości. Roczne „odtworzyliśmy losowy plik” nie wystarczy, gdy ERP musi wrócić w całości.

Pytania pod ransomware

  • Czy repozytoria backupów są niezmienne (immutability/WORM) przez określony czas?
  • Czy jest kopia air-gap lub offline według harmonogramu, który możecie audytować?
  • Czy credentiale backupu różnią się od admina domeny i właściciela tenantu chmury?
  • Jaka jest ścieżka restore, gdy AD lub Entra ID jest skompromitowane?

Czerwone flagi

„Nielimitowana retencja” bez modelu kosztu storage. Restore wyceniany godzinowo bez limitu. Backupy tylko na tym samym SAN co produkcja. Brak snapshotów spójnych dla SQL/PostgreSQL. „Backup w chmurze” = drugi folder u tego samego vendora.

Checklist na jedną stronę

  • Lista systemów/tierów z retencją i szyfrowaniem.
  • Tabela RPO/RTO dołączona do SLA.
  • Ostatni raport testu restore (< 90 dni dla tier-1 lub uzasadnienie luki).
  • Sekcja ransomware: immutability, osobne credentiale, notatka o AD.
  • Nazwany owner backupu po stronie dostawcy + eskalacja.
  • Klauzula wyjścia: jak otrzymujecie dane backupu przy odejściu.

Jak zrobić drill restore w jedno popołudnie

Nie trzeba katastrofy, żeby wiedzieć czy backup działa. Wybierzcie kopię poza produkcją jednego systemu tier-1 — bazę ERP, udział plików albo VM, której finanse tego dnia nie potrzebują. Zarezerwujcie cztery godziny. Role: ktoś od dostawcy (albo właściciel backupu), ktoś od aplikacji, ktoś z IT, kto postawi wyrzutnię restore. Drill ma cztery zegary:

  1. Odnalezienie — czas od „start” do „mamy właściwy punkt i logujemy się do repozytorium bez konta admina produkcji”. Powyżej 20 minut: hasła albo dokumentacja już są ustalenie.
  2. Odtworzenie na izolowany cel — nie nadpisujcie produkcji. Zapiszcie GB i minuty.
  3. Dym na aplikacji — czy użytkownik się zaloguje, otworzy znany dokument albo zaksięguje testowy dokument? „VM odpowiada na ping” to nie zaliczenie.
  4. Podpis raportu — data, osiągnięte RPO (luka między ostatnią dobrą kopią a „teraz”), RTO, braki, właściciel każdej poprawki. Schowajcie tam, gdzie dział prawny i ubezpieczyciel znajdą bez admina backupu.

Widzieliśmy „zielone dashboardy backupu”, które padały na kroku 1, bo niemodyfikowalne repozytorium używało tego samego domain admina, którego ransomware i tak zabierze. Drill ma to znaleźć przed tabletopem, nie w trakcie.

Liczby, które naprawdę widzimy w umowach

To nie normy — to przedziały, które przeżywają rozmowę z zarządem w firmach 50–200 osób w Polsce i Niemczech. Dopasujcie do ryzyka i zapiszcie.

  • Poczta / M365 — RPO 1–4 h, jeśli płacicie za backup Exchange/SharePoint/OneDrive u trzeciej strony; kosze natywne to nie strategia na ransomware. RTO: godziny, nie dni, dla skrzynki; odtworzenie całego tenanta to inny sport.
  • ERP (Comarch, Enova, SAP B1, własne) — RPO często 4–24 h (log shipping). RTO 8–24 h na spójną bazę plus serwer aplikacji jest uczciwe; „dwie godziny” bez przetestowanego runbooka to teatr.
  • Pliki / CAD / dokumentacja produkcji — nocny RPO jest częsty i często za luźny, jeśli piątkowe rysunki są poniedziałkową wysyłką. Zapytajcie operacje, nie IT, ile godzin pracy stać ich na narysowanie od nowa.
  • Retencja — 14–30 dziennych, 8–12 tygodniowych, 12 miesięcznych to punkt startowy. „Bez limitu” bez ceny storage to przyszła faktura.

Jeśli dostawca podaje jedno RPO/RTO na wszystko, nie siedział przy waszym zamknięciu miesiąca ani oknie wysyłek.

3-2-1-1-0 bez plakatu

Trzy kopie, dwa nośniki, jedna poza siedzibą, jedna niemodyfikowalna albo offline, zero błędów na ostatnim teście restore. W praktyce firmy średniej wielkości: dysk produkcji + repozytorium na innej macierzy albo object storage + kopia, której skompromitowany admin nie skasuje (okno immutability 7–30 dni jest typowe) + raport restore młodszy niż 90 dni dla tier-1. Taśma nie jest obowiązkowa. Drugie konto u dostawcy, do którego produkcyjny AD nie sięga — często tak.

Dla techników: spójne snapshoty SQL/PostgreSQL (VSS albo dump, nie tylko crash-consistent), osobne konto usługi backupu, MFA na konsoli, ścieżka awaryjna gdy Entra ID albo AD leży. Jeśli jedyna droga restore wymaga tego samego IdP, które właśnie złamano phishingiem, nie macie planu na ransomware — macie nadzieję.

Czego pytają ubezpieczyciele i audytorzy w 2026

Kwestionariusze cyber nie kończą się na „czy macie backup”. Pytają o immutability, datę ostatniego restore, czy do kopii da się dojść kontami produkcji i kto podpisuje raport. Przeglądy NIS2 pytają o to samo, a potem — gdzie leży raport. Włóżcie kopię do tej samej teczki dowodowej co runbook incydentu — co musi być w runbooku NIS2. Jeśli nie odpowiecie na te cztery pytania na jednym spotkaniu, nie podpisujcie nowej klauzuli „zarządzany backup”, dopóki nie potraficie.

Co dalej

Wyciągnijcie umowę i podkreślcie każde zdanie o „backupie” bez liczb. Poproście o restore drill na jednym systemie niekrytycznym przed odnowieniem — albo przed migracją tier-1. W praktyce Bezpieczna infrastruktura chmury publicznej projektujemy backup i restore z runbookami pod testy — tak, jak pytają audytorzy i regulatorzy, nie tylko dashboard.

Chcesz porozmawiać o projekcie?

Napisz do nas

Więcej na ten temat

Jak wybrać zarządzaną chmurę, gdy macie 50–200 osób
RFP na chmurę: jak porównać trzech dostawców bez porównywania prezentacji

Zapisz się do newslettera

Otrzymuj nowości, aktualizacje i oferty specjalne bezpośrednio na skrzynkę.
Nie, dziękuję