Ciągłość · Backup / DR

Backup i disaster recovery: RPO, RTO i testy odtworzenia

Backup bez zdefiniowanego RPO/RTO i bez testów restore to tylko koszt dysku. Disaster recovery bez procedury i okna komunikacji to plan na papierze. W modelu zarządzanym obie warstwy muszą być częścią SLA — nie dodatkiem „jak starczy czasu”.

RPO i RTO — w prostych słowach

• RPO (Recovery Point Objective) — ile danych możecie stracić (np. 15 minut, 4 godziny),
• RTO (Recovery Time Objective) — jak szybko środowisko ma wrócić do pracy.

Im niższe wartości, tym droższa architektura: częstsze snapshoty, replikacja, warm/hot standby, osobna lokalizacja. Nie każda aplikacja potrzebuje RPO bliskiego zera.

Typowe błędy w praktyce

• backup na tej samej macierzy / w tym samym AZ co produkcja,
• brak testu odtworzenia (albo test „raz na dwa lata”),
• niejasne, kto zatwierdza restore i kto komunikuje klientów,
• retencja zbyt krótka względem wymagań księgowych lub branżowych.

Co obejmuje zarządzane DR w BaseCloud

W pakietach Professional i Enterprise backup oraz procedury odtworzenia są elementem eksploatacji: harmonogramy, monitoring jobów, retencja i udział w testach DR. Zakres RPO/RTO doprecyzowujemy po audycie — nie obiecujemy „zero downtime” bez architektury, która to realnie umożliwia.

Checklist przed podpisaniem SLA

• lista systemów krytycznych i ich właścicieli biznesowych,
• cele RPO/RTO per system (nie jeden numer na całą firmę),
• częstotliwość i forma testów restore,
• ścieżka eskalacji i raport po incydencie.

Zobacz pakiety · DORA i ciągłość działania · Więcej artykułów