Backup i Disaster Recovery dla firm

Jak zaplanować backup, RPO/RTO, retencję, kopie 3-2-1, test odtworzenia, monitoring i plan Disaster Recovery dla usług biznesowych.

Praktyczny poradnik DataHouse.pl

Backup i Disaster Recovery dla firm

Backup nie jest tylko kopią plików. W firmie trzeba opisać RPO, RTO, retencję, odpowiedzialność za odtworzenie, testy przywracania, monitoring oraz plan Disaster Recovery dla usług takich jak WWW, poczta, bazy danych, VPN i systemy klientów.

RPO i RTO

RPO określa, ile danych firma może utracić, a RTO ile czasu może trwać odtworzenie usługi. Bez tych dwóch wartości backup jest przypadkową kopią, a nie częścią planu ciągłości działania.

Model kopii 3-2-1

Praktyczny model zakłada kilka kopii danych, różne nośniki lub warstwy storage oraz przynajmniej jedną kopię poza głównym środowiskiem. Dla usług krytycznych warto rozdzielić backup lokalny, zdalny i archiwalny.

Test odtworzenia

Kopia, której nikt nie odtworzył, jest tylko założeniem. Test przywracania powinien obejmować pliki, bazę danych, konfigurację usługi, certyfikaty, DNS, konta techniczne i dokumentację uruchomienia.

Disaster Recovery

Plan DR opisuje, co robimy po awarii: kto podejmuje decyzję, gdzie odtwarzamy usługę, jak przełączamy DNS lub routing, jak komunikujemy stan i kiedy wracamy do normalnej pracy.

Modele backupu i odtwarzania

Backup plików

Dokumenty, załączniki, konfiguracje

Dobry punkt startowy, ale bez backupu baz danych i konfiguracji usług nie wystarczy do pełnego odtworzenia systemu.

Backup baz danych

ERP, CRM, sklepy, poczta

Wymaga spójnych snapshotów, kontroli transakcji, testu importu i jasnego RPO dla danych biznesowych.

Backup maszyn / VPS

Serwery aplikacyjne i środowiska testowe

Ułatwia odtworzenie całego systemu, ale nadal trzeba osobno sprawdzić DNS, certyfikaty, klucze i integracje.

Kopia poza głównym środowiskiem

Awaria sprzętu, błąd operatora, ransomware

Zmniejsza ryzyko utraty danych, gdy problem dotyczy podstawowej platformy albo konta administracyjnego.

Disaster Recovery

Usługi krytyczne i wysokie SLA

Plan obejmuje miejsce odtworzenia, kolejność usług, komunikację, przełączenie ruchu i powrót do pracy normalnej.

Cele odtworzeniowe

Macierz doboru RPO/RTO

Poniższe przedziały są przykładami projektowymi, a nie publiczną gwarancją usługi. Dokładne cele zależą od spójności obciążenia, wolumenu danych, zależności, zasobów odtworzeniowych i testów oraz są potwierdzane w indywidualnej ofercie i umowie.

Archiwa i raportowanie

Przykłady: Dokumenty, eksporty, raporty historyczne

RPO: Godziny do jednej doby

RTO: Godziny do następnego dnia roboczego

Typowy projekt: Planowa kopia off-site z retencją i udokumentowanym odtworzeniem plików

Standardowe systemy biznesowe

Przykłady: Pliki, collaboration, aplikacje wewnętrzne

RPO: Przykładowy cel: 1-4 godziny

RTO: Przykładowy cel: 4-8 godzin

Typowy projekt: Częsty backup, oddzielne repozytorium, kopia off-site i cykliczny test odtworzenia

Systemy transakcyjne

Przykłady: ERP, CRM, e-commerce, bazy danych i poczta

RPO: Przykładowy cel: 15-60 minut

RTO: Przykładowy cel: 1-4 godziny

Typowy projekt: Kopie spójne aplikacyjnie, oddzielne poświadczenia oraz przetestowana kolejność startu baz i aplikacji

Usługi krytyczne

Przykłady: Systemy, których awaria natychmiast zatrzymuje kluczowe operacje

RPO: Minuty lub near-zero po walidacji wymagań

RTO: Minuty do jednej godziny po walidacji wymagań

Typowy projekt: Replikacja lub bardzo częste kopie, zasoby w drugim ośrodku, automatyczny monitoring, runbook i regularne ćwiczenia

Pięć warstw ochrony i domen awarii

1. Produkcja

Podstawowe systemy i dane. Ta warstwa nie jest backupem i wyznacza pierwszą domenę awarii.

2. Szybkie odtworzenie lokalne

Snapshoty lub bliska kopia skracają typowe odtworzenia, lecz mogą dzielić z produkcją ryzyko zasilania, storage albo administracji.

3. Oddzielne repozytorium

Dedykowana pojemność z własną retencją, monitoringiem i kontrolowanym dostępem do odtwarzania.

4. Warstwa off-site i immutable

Kopia oddzielona lokalizacją i poświadczeniami, opcjonalnie immutable lub offline, chroni przed awarią ośrodka i destrukcyjnym przejęciem kont.

5. Środowisko odtworzeniowe

Zimne, ciepłe lub aktywne zasoby w drugiej domenie awarii dobiera się do zwalidowanego RTO i mapy zależności.

Runbook Disaster Recovery: od incydentu do powrotu

1. Wykryj i ogłoś

Potwierdź wpływ, właściciela incydentu, kanał komunikacji i decyzję o uruchomieniu odtwarzania.

2. Odizoluj przyczynę

Ogranicz przejęte konta, ransomware, awarię storage lub sieci, zanim podłączysz chronione kopie.

3. Odtwórz infrastrukturę

Przygotuj compute, storage, sieć, firewall, tożsamość, DNS i zależności certyfikatów.

4. Odtwórz dane i aplikacje

Odtwarzaj według kolejności zależności i zapisz punkt czasowy odzyskanego zestawu danych.

5. Przełącz i zweryfikuj

Przełącz ruch dopiero po testach technicznych i odbiorze biznesowym krytycznych transakcji.

6. Komunikuj i monitoruj

Śledź stan usług, kolejki, integracje, wydajność i zgłoszenia użytkowników przez cały proces.

7. Wróć i popraw plan

Zatwierdź powrót na platformę podstawową, zachowaj dowody i popraw runbook na podstawie wniosków.

Macierz odpowiedzialności

Priorytety biznesowe i akceptowalna strata

Właściciel: Właściciel biznesowy klienta

Wymagany rezultat: Zatwierdzone klasy usług, RPO/RTO i kolejność odtwarzania

Spójność aplikacji i zależności

Właściciel: Właściciel aplikacji klienta z DataHouse

Wymagany rezultat: Metoda backupu, quiescing, poświadczenia i kolejność startu aplikacji

Repozytorium, retencja i monitoring

Właściciel: DataHouse w uzgodnionym zakresie usługi

Wymagany rezultat: Pojemność, zadania kopii, alerty, separacja dostępu i polityka retencji

Wykonanie odtworzenia

Właściciel: Imienne zespoły techniczne w runbooku

Wymagany rezultat: Kroki odtworzenia, kontakty eskalacyjne, dostęp i dziennik dowodów

Odbiór i failback

Właściciel: Właściciel biznesowy klienta z DataHouse

Wymagany rezultat: Wynik odbioru, otwarte błędy, decyzja o ruchu i plan powrotu

Dowody z testu odtworzeniowego

  • data testu, testowane obciążenie i osoby odpowiedzialne;
  • wybrany punkt odtworzenia i rzeczywisty punkt czasowy odzyskanych danych;
  • czas rozpoczęcia i zakończenia odtworzenia infrastruktury, danych i aplikacji;
  • testy techniczne baz, plików, poczty, DNS, certyfikatów, integracji i dostępu użytkowników;
  • odbiór biznesowy, odchylenia od celu i otwarte ryzyka;
  • działania korygujące, właściciel i termin przed kolejnym ćwiczeniem.
Zaplanuj Backup i DR z DataHouse

Prześlij listę obciążeń, wolumen danych, oczekiwaną retencję, zależności i priorytety biznesowe. Przygotujemy architekturę, zakres testów i podział odpowiedzialności do indywidualnej oferty.

Poproś o plan Backup i DR

Właściciel techniczny: zespół DataHouse / eTop. Weryfikacja: 28 lipca 2026. Przykładowe przedziały RPO/RTO mają charakter edukacyjny; dokładna pojemność, retencja, cele odtworzeniowe, testy, odpowiedzialności, ceny i SLA są potwierdzane w ofercie i umowie.

Checklista planu Backup/DR

  1. Spisać usługi krytyczne: WWW, pocztę, bazy danych, pliki, DNS, VPN, integracje, konta techniczne i certyfikaty.
  2. Ustalić RPO, RTO, retencję, szyfrowanie, lokalizację kopii i odpowiedzialność za test odtworzenia.
  3. Oddzielić backup szybki od archiwalnego oraz kopię poza głównym środowiskiem administracyjnym.
  4. Przetestować odtworzenie na osobnym środowisku i sprawdzić aplikacje, DNS, SSL, pocztę oraz dostęp użytkowników.
  5. Opisać plan Disaster Recovery: kolejność usług, komunikację, przełączenie ruchu, monitoring i powrót po awarii.

Najczęstsze pytania

Czym backup różni się od Disaster Recovery?

Backup to kopia danych, a Disaster Recovery to plan odtworzenia usługi po awarii: gdzie uruchomić system, jak przełączyć ruch, kto podejmuje decyzje i jak sprawdzić, że usługa działa.

Co oznaczają RPO i RTO?

RPO określa maksymalną akceptowalną utratę danych, a RTO maksymalny czas odtworzenia usługi. Te wartości decydują o częstotliwości kopii i architekturze odtwarzania.

Jak często testować odtwarzanie backupu?

Dla usług krytycznych test odtworzenia trzeba wykonywać cyklicznie oraz po większych zmianach aplikacji, bazy danych, systemu, DNS lub procedur administracyjnych.

Czy backup powinien być poza głównym środowiskiem?

Tak. Jedna kopia powinna być oddzielona od podstawowej platformy i kont administracyjnych, żeby awaria, błąd lub ransomware nie zniszczyły wszystkich kopii.

Czy DataHouse.pl może pomóc w planie Backup/DR?

Tak. Plan można połączyć z backup i storage, Cloud Pro, VPS, serwerami dedykowanymi, kolokacją, administracją, monitoringiem i testami narzędziowymi.

Czy jedno RPO i RTO pasuje do wszystkich systemów?

Zwykle nie. Bazy danych, ERP, poczta, pliki i archiwa mają różną tolerancję utraty danych, zależności oraz kolejność odtwarzania, dlatego trzeba klasyfikować je osobno.