Backup i odtwarzanie: co wymagać przed podpisaniem umowy

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.

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?

Kontakt

Więcej na ten temat