Odzyskiwanie awaryjne (Disaster Recovery) i kopie zapasowe

1. Przegląd koncepcji i problem systemowy

W inżynierii infrastruktury awarie dysków SSD, katastrofy w centrach danych dostawców, ataki ransomware oraz błędy ludzkie (DROP DATABASE production, przypadkowe rm -rf) nie są kwestią „czy”, lecz „kiedy”.

Większość zespołów żyje w iluzji bezpieczeństwa: dodają wpis do crontaba tworzący zrzut raz na dobę i uważają zadanie za wykonane. Gdy dochodzi do rzeczywistej katastrofy, okazuje się, że:

• Ostatnia kopia zapasowa zawiodła trzy miesiące temu z powodu przepełnienia dysku.
• Zrzut zawiera uszkodzone dane binarne.
• Przywrócenie bazy o wielkości 100 GB zajmuje 36 godzin, paraliżując działalność biznesową (nieakceptowalny RTO).
• Napastnik, po włamaniu na serwer, usunął kopie zapasowe wraz z działającą bazą, ponieważ klucz API S3 posiadał pełne uprawnienia do usuwania obiektów (s3:DeleteObject).

Disaster Recovery (odporność na awarie) to kompleksowa strategia ciągłości działania biznesu. Obejmuje ona nie tylko przechowywanie plików, ale także matematycznie wyliczone cele RTO/RPO, niezmiennicze magazyny danych (Immutable Storage) oraz zautomatyzowane, regularne ćwiczenia polegające na odbudowie infrastruktury od zera.

2. Taksonomia architektoniczna i model mentalny

Macierz architektury Disaster Recovery opiera się na kompromisie między szybkością a częstotliwością utrwalania stanu:

┌─────────────────────────────────────────────────────────────┐
│                 TAKSONOMIA ODZYSKIWANIA PO AWARII           │
├─────────────────────────────────────────────────────────────┤
│ 1. Odzyskiwanie do punktu w czasie (PITR) ➔ RPO ~ sekundy   │
│    • Strumieniowanie dzienników WAL (Write-Ahead Log)       │
│      w czasie rzeczywistym                                  │
│    • Narzędzia: Litestream (dla SQLite), pgBackRest (PG)    │
├─────────────────────────────────────────────────────────────┤
│ 2. Migawki z deduplikacją i szyfrowaniem ➔ RPO ~ godziny     │
│    • Atomowe migawki danych przez Restic, BorgBackup, Kopia │
│    • Szyfrowanie po stronie klienta AES-256 / ChaCha20      │
├─────────────────────────────────────────────────────────────┤
│ 3. Warstwa trwałego magazynu offsite (Antyransomware)        │
│    • Blokada obiektów S3 (WORM - Write Once, Read Many)     │
│    • Geograficznie izolowane magazyny (Cloudflare R2, AWS S3)│
├─────────────────────────────────────────────────────────────┤
│ 4. Zimny standby i automatyczne ćwiczenia odzyskiwania       │
│    (walidacja RTO)                                           │
└─────────────────────────────────────────────────────────────┘

1. Odtwarzanie do dowolnego punktu w czasie (Point-In-Time Recovery - PITR):
   • Zamiast jednego ciężkiego zrzutu raz na dobę, baza danych w sposób ciągły strumieniuje swój dziennik zmian binarnych (WAL) do chmury. Pozwala to „cofnąć” stan bazy do sekundy poprzedzającej awarię lub błędne zapytanie dewelopera (RPO < 10 sekund).
2. Deduplikowane zrzuty przyrostowe (Content-Addressed Snapshots):
   • Narzędzia takie jak Restic dzielą pliki na bloki kryptograficzne. Jeśli w bazie o wielkości 50 GB zmieniło się jedynie 1%, przesyłane są tylko nowe bloki, co oszczędza do 95% miejsca na dysku oraz przepustowości sieci.
3. Niezmienniczy magazyn danych (Immutable WORM Storage):
   • Polityka bezpieczeństwa S3 Object Lock, zgodnie z którą nikt (nawet administrator z dostępem root) nie może usunąć ani nadpisać utworzonego archiwum przez określony czas (np. 30 dni).
4. Ćwiczenia odtworzeniowe (Recovery Drills):
   • Regularny, automatyczny proces w CI, który pobiera ostatni archiwum, uruchamia je w izolowanym kontenerze, wykonuje testowe zapytania SQL i potwierdza integralność danych.

3. Pipeline techniczny i mechanika wewnętrzna

Cykl życia niezawodnego backupowania z deduplikacją i szyfrowaniem:

1. Spójne zamrożenie stanu (Snapshot Lock): Baza danych przechodzi w tryb przygotowania do kopiowania lub tworzony jest zrzut transakcyjny poprzez mechanizmy COW (Copy-on-Write) systemu plików ZFS/Btrfs.
2. Szyfrowanie po stronie klienta: Przed wysłaniem danych do sieci są one szyfrowane silnym algorytmem (AES-256-GCM) przy użyciu frazy hasła znanej wyłącznie inżynierowi. Dostawca hostingowy S3 otrzymuje wyłącznie zaszyfrowany szum binarny.
3. Równoległe przesyłanie do izolowanego magazynu chmurowego: Bloki są przesyłane przez HTTPS do niezależnego regionu geograficznego (np. serwer w Niemczech robi backup do magazynu Cloudflare R2 w Szwecji).
4. Zastosowanie polityki rotacji (GFS Retention Policy): Algorytm zachowuje: ostatnie 24 kopie godzinowe, 7 dziennych, 4 tygodniowe oraz 12 miesięcznych (Grandfather-Father-Son), automatycznie usuwając stare, pośrednie zrzuty.
5. Automatyczna weryfikacja integralności (Automated Integrity Check): Osobne zadanie w tle raz w tygodniu wykonuje komendę restic check --read-data-subset=5%, wykrywając potencjalną degradację bitów (Bit Rot) w magazynie.

4. Praktyczne scenariusze inżynierskie w środowisku produkcyjnym

01. Ciągła replikacja SQLite przy użyciu Litestream

Dla aplikacji opartych na SQLite/Turso:

• Litestream działa jako proces systemowy w tle, przechwytując zmiany w pliku WAL.
• Co 10 sekund nowe ramki są szyfrowane i przesyłane do bucketu Cloudflare R2.
• W przypadku całkowitej utraty serwera nowa maszyna jest podnoszona jedną komendą litestream restore -o /var/data/app.db, przywracając stan systemu praktycznie bez utraty danych (RPO < 10 s, RTO < 60 s).

02. Ochrona przed napastnikami dzięki S3 Object Lock

Zapobieganie destrukcji infrastruktury przez hakerów:

• Nawet jeśli napastnik uzyska pełny dostęp root do serwera i znajdzie konfigurację z kluczami AWS_ACCESS_KEY_ID, próba wykonania aws s3 rm --recursive zostanie zablokowana przez politykę AWS Compliance Lock na poziomie centrum danych Amazon.
• Firma ma gwarantowany dostęp do niezmiennych kopii zapasowych.

03. Plan odtworzenia zimnego standby przez Terraform (IaC Standby)

Awaria poziomu OVH (pożar w centrum przetwarzania danych w Strasburgu):

• Główny serwer staje się fizycznie niedostępny.
• Inżynier uruchamia pipeline CI: Terraform w ciągu 3 minut wynajmuje nową instancję w Hetzner, Ansible nakłada podstawową konfigurację, skrypt pobiera ostatni backup Restic, a rekordy DNS Cloudflare przełączają się na nowy IP w ciągu 60 sekund.

5. Pułapki, typowe błędy i bezpieczeństwo

• Przechowywanie hasła deszyfrującego obok backupu: Jeśli hasło do repozytorium Restic jest zapisane w jawnym pliku /root/.backup_pass, kompromitacja serwera jednocześnie otwiera napastnikom dostęp do odczytu całej bazy klientów w kopiach zapasowych.
• Kopiowanie plików aktywnych baz bez blokady (Dirty Reads): Proste skopiowanie katalogu danych PostgreSQL (cp -r /var/lib/postgresql) podczas aktywnych zapytań tworzy niespójny stan binarny (Torn Pages), którego nie da się uruchomić po przywróceniu.
• Brak pamięci do dekompresji zrzutu: Jeśli na nowym serwerze zainstalowano dysk mniejszy niż rozpakowana baza danych, procedura przywracania zakończy się błędem w połowie procesu z powodu braku miejsca na dysku (No space left on device).
• Ignorowanie plików konfiguracyjnych i zmiennych środowiskowych: Backup tylko bazy danych, bez zachowania konfiguracji Nginx, certyfikatów SSL oraz plików .env, wydłuża RTO z 15 minut do kilku dni ręcznego przypominania sobie ustawień.