Backup i Disaster Recovery —
plan dla firmy z ITSM

Ransomware w firmie to scenario testowany przez cyberbezpieczeństwo najczęściej bez powodzenia. Atakujący szyfruje wszystkie dane — głównie system plików, bazy danych, email. Firma musi wybrać: zapłacić ransom (500k–2M PLN), przywrócić z backup'u (RTO 4–24h, RPO 1–4h strata danych), albo zamknąć operacje (strata 100k+ PLN dziennie). Większość polskich firm bierze trzecią opcję bo nie ma DR planu. W tym artykule pokazuję **dlaczego to się dzieje**, **jak budować DR plan**, **RTO i RPO** i **jak testować co 3 miesiące** aby wciąż działało.

Dlaczego DR — statystyki i ryzyka bez planu

Statystyka 1: W 2025 roku, 60% polskich firm miało incydent poważny (outage > 4 godzin). Z nich 70% miało DR plan, 30% nie miało.

Statystyka 2: Średni koszt outage'u: 100k PLN na godzinę (dla firmy 500+ osób). Outage 24h = 2.4M PLN strat (plus reputation damage).

Statystyka 3: Ransomware attack cost: 200k PLN (attacker payment) + 300k PLN (forensics + recovery) + 500k PLN (lost business) = 1M PLN minimum. Duża firma 2M PLN+.

Ryzyka bez DR:

• Hardware failure — serwer dies, baza danych offline, nie wiadomo kiedy wróci
• Ransomware — все encrypted, trzeba płacić ransom lub czekać na recovery
• Data center outage — całe biuro bez dostępu do systemów
• Błędy operacyjne — ktoś skasował produkujący folder, bez snapshot'a nie ma powrotu
• Regulatory non-compliance — NIS2, ISO 27001 wymagają tested DR plan, brak = kara

RTO vs RPO — co to oznacza i ile czasu masz?

RTO (Recovery Time Objective): Maksymalny czas, w którym system musi być przywrócony do działania od momentu incydentu. Przykład: RTO 4h = system musi być online w ciągu 4 godzin.

RPO (Recovery Point Objective): Maksymalna ilość danych, którą możesz stracić (time-based). Przykład: RPO 1h = backup co 1 godzinę = maksymalna strata to dane z ostatniej godziny.

Praktyczne przykłady:

• Financial system (bank, finanse): RTO 2h, RPO 15 minut (backup co 15 min, transakcje mogą czekać max 2h)
• Email (MS Exchange): RTO 6h, RPO 2h (backup co 2h, pracownicy czekają na email max 6h)
• File Server (dokumenty, projekty): RTO 8h, RPO 4h (backup daily o północy, refresh co 4h jeśli uznajesz za necessary)
• Web application (public-facing): RTO 1h, RPO 30 min (geo-redundancy, backup co 30 min)

Reguła 3-2-1 — backup strategy dla każdej firmy

3 kopie: Original (production data) + 2 backup copies. To ochronia przed erasure (pracownik skasuje) i corruption.

2 media: Nie trzymaj wszystkich backup'ów na tym samym typie storage (np. sam disk). Mix: disk + cloud, lub disk + tape. To ochronia przed media failure (disk się psuje).

1 offline: Jedna kopia musi być offline (disconnected from network), żeby ransomware attacker nie mógł jej szyfrować. LTO tape w sejfie to standard.

Praktyczna implementacja:

• Kopia 1 (Original): Production server (na SSD dla performance)
• Kopia 2 (Local Backup): Backup appliance na datacenter (disk, encrypted, accessible dla recovery w <4h)
• Kopia 3 (Cloud Sync): AWS S3 / Azure Blob Storage (geographic redundancy, accessible w <2h jeśli datacenter burns down)
• Kopia 4 (Offline Archive): LTO tape (quarterly), przechowywane offsite — dla compliance (5-year audit trail)

Częstotliwość backup'u — daily/weekly/monthly vs RPO

Full Backup schedule:

• Critical systems (SQL databases, ERP): Full backup daily o północy (RPO 1 day) + Transaction log backup co 1–4 godziny (RPO 4h). Retention: 30 dni (monthly = permanent archive)
• Regular systems (file servers, workstations): Full backup weekly (RPO 7 dni), incremental daily (RPO 1 day). Retention: 3 miesiące
• VMs (virtual machines): Snapshot daily o północy (RPO 1 day), image backup weekly. Retention: 2 tygodnie (snapshots = space-consuming)
• Audit logs (compliance): Immutable archive (WORM — Write Once, Read Many), retention 7 lat. No delete, no modification.

Tabela RTO dla różnych poziomów krytyczności systemów

Testowanie DR — quarterly drill i verify data integrity

Reguła: Test DR co 3 miesiące albo nie testuj vůbec. Statystyka: 30% backup'ów jest corrupt albo unrestoreable — odkrywasz to, dopiero kiedy testujesz.

Quarterly DR test procedure:

• Faza 1: Select backup (losowy wybiór)

  Losuj backup z 1–3 miesiące wstecz. Nie testuj najnowszego — testujesz „jak stary backup jeszcze działa".

• Faza 2: Restore na test system

  Zarezerwuj dedykowany test server (VM snapshot, isolated network) i zarestoruj backup. Zmierz czas (docelowo: RTO ≤ 4h).

• Faza 3: Verify data integrity

  Checklist: baza danych starts, aplikacja się łączy, dane są kompletne (count rows vs production), no corruption. Run DBCC CheckDB (SQL) albo equivalent.

• Faza 4: Document + Notify

  Wyniki testu: success/fail, czas restore, issues found, remediation plan. Email do kierownictwa i CISO — proof że DR works.

Failover procedure i runbook dla helpdesku

Runbook — zdokumentowana procedura crisis krok po kroku. Bez runbook'a, panika = błędy.

Struktura runbook'a:

1. Incident declaration: Kto deklaruje outage? IT Manager? CIO? Co to znaczy „outage" — system offline 10 minut? 1 godzina? (Define RTO threshold)
2. Escalation: Wiadomość do Disaster Recovery Lead, Manager, CEO
3. Assessment (30 minut): Diagnozuj problem — czy to hardware failure? Software bug? Ransomware? Data center down?
4. Decision (30 minut): Czy czekać na fix czy trigger DR? Jeśli RTO < 4h i assessment pokazuje „nie wrócimy szybko" → trigger DR
5. Restore (RTO – 1h): Backup team restoruje na test system, verifikuje data integrity
6. Failover (30–60 minut): Reroute traffic od production do restored system, update DNS, notify users
7. Stabilization (2h): Monitor logs, aplikacje, performance, user reports
8. Post-incident review (następny dzień): What went wrong? Jak improve DR plan?

Najczęstsze pytania (FAQ)