Planowanie backupu i recovery: chroń swoje pliki

Plan backupu i recovery odpowiada na dwa liczbowe pytania: RPO (ile danych możesz sobie pozwolić stracić, mierzone w czasie) i RTO (jak długo możesz sobie pozwolić na przestój). Zdefiniuj je dla każdego workloadu, potem inżynieruj wstecz. Baza danych z RPO 5 minut potrzebuje ciągłego przesyłania WAL; tygodniowy raport marketingowy z RPO 24 godziny potrzebuje jednego nocnego zadania. Połącz z zasadą 3-2-1 — trzy kopie, na dwóch typach nośników, z jedną poza siedzibą — i testuj odtworzenia kwartalnie. Większość historii „mamy backupy" kończy się źle, bo nikt nigdy nie przećwiczył odtwarzania.

RPO i RTO: liczby startowe

RPO (Recovery Point Objective) = maksymalna akceptowalna utrata danych w czasie. RTO (Recovery Time Objective) = maksymalny akceptowalny przestój.

Przykłady według workloadu:

Produkcyjna baza danych dla sklepu e-commerce: RPO 5 min, RTO 1 godz.
Uploady plików skierowane do klientów: RPO 15 min, RTO 2 godz.
Wewnętrzny serwer plików: RPO 24 godz., RTO 8 godz.
Archiwum e-mail: RPO 24 godz., RTO 48 godz.
Analityka marketingowa: RPO 24 godz., RTO 72 godz.

Ściślejsze RPO/RTO kosztuje więcej. RPO 5 minut oznacza ciągłą replikację (droga infrastruktura); RPO 24 godziny oznacza jedno nocne zadanie (tanie). Nie przekombinowuj — nie każdy workload potrzebuje gorącego standby.

Zasada 3-2-1 nadal działa

Trzy kopie danych, na dwóch różnych typach storage, z jedną poza siedzibą. Zasada 3-2-1 poprzedza chmurę i nadal obowiązuje:

Primary: storage produkcyjny (S3, EBS, dysk PostgreSQL)
Secondary: kopia zapasowa na innym nośniku lub w innym regionie (inny bucket S3 z replikacją, Glacier)
Tertiary: poza siedzibą, najlepiej inny dostawca lub air-gapped (Backblaze B2, taśma on-prem, fizyczne dyski w sejfie)

Aspekt różnorodności dostawców ma znaczenie. Skompromitowane konto root AWS może usunąć wszystkie Twoje backupy AWS. Kopia wtórna w Backblaze, Wasabi lub on-prem przeżywa ten scenariusz. Dla firm poniżej 200 mln PLN przychodów, kopia u drugiego dostawcy kosztuje może 200–800 PLN miesięcznie i ubezpiecza przed katastrofalnymi problemami całego tenantu.

Pełny, przyrostowy i syntetyczny pełny backup

Trzy strategie backupu:

Pełny: kopiuj wszystko za każdym razem. Prosty, odtwarzanie szybkie (jeden plik), storage ciężki.
Przyrostowy: kopiuj tylko to, co zmieniło się od ostatniego backupu. Oszczędny na storage, odtwarzanie wymaga pełnego + wszystkich przyrostowych.
Syntetyczny pełny: serwerowe scalenie pełnego + przyrostowych w nowy wirtualny pełny. Szybkie odtwarzanie z dowolnego punktu.

Nowoczesne narzędzia backupowe (Veeam, Rubrik, restic z prune, BorgBackup) używają przyrostowego-na-zawsze z syntetycznymi pełnymi pod spodem. Wzorzec: nocny przyrostowy, tygodniowy syntetyczny pełny, zachowaj 30 dziennych + 12 miesięcznych + 7 rocznych kopii (rotacja dziadek-ojciec-syn).

Dla serwera plików 2 TB z 5% dzienną stopą zmian, przyrostowy-na-zawsze przechowuje około 3–5 TB łącznie przez rok retencji — versus 700+ TB gdybyś robił pełny nocny.

Szyfrowanie zanim opuści

Backupy nie powinny podróżować ani leżeć niezaszyfrowane. Szyfrowanie po stronie klienta z AES-256-GCM (domyślne w restic, Borg, Duplicacy, Veeam i innych) zapewnia, że host backupu nigdy nie widzi jawnego tekstu.

Zarządzanie kluczami ma większe znaczenie niż wybór algorytmu. Backup zaszyfrowany kluczem przechowywanym na tym samym koncie AWS co backup to teatr — atakujący z dostępem IAM dostaje oba. Przechowuj klucze w:

AWS KMS z kluczem oddzielnego konta (dekryptowanie cross-account)
HashiCorp Vault w środowisku out-of-band
Sprzętowym module bezpieczeństwa (YubiKey, HSM) dla klucza root
Wydrukowanej i zapieczętowanej papierowej kopii dla naprawdę krytycznych kluczy

Rotuj regularnie (rocznie), loguj każde użycie i testuj odtwarzanie z rotowanym kluczem zanim rotacja wejdzie w życie na produkcji.

Niezmienność: odpowiedź na ransomware

Ataki ransomware w 2025 roku powszechnie celują najpierw w backupy — szyfrują dane produkcyjne, potem usuwają lub szyfrują backupy, żeby uniemożliwić odtworzenie. Niezmienne backupy pokonują to.

Implementacje:

S3 Object Lock (Compliance Mode): nawet root nie może usunąć przez okres retencji
Azure Blob immutable storage: podobne, egzekwowane na poziomie kontenera
Veeam Hardened Linux Repository: tylko-dołączanie, SSH-only, brak API delete
Fizyczna taśma w sejfie: ostateczny air gap

Dla danych krytycznych dla biznesu, co najmniej jedna kopia backupu powinna być niezmmienna przez okres retencji. Przyrostowy koszt to zazwyczaj zero — i tak zamierzałeś ją zachować. Wartość gdy ransomware uderza jest totalna.

Testowanie: opcjonalnej części nie ma

Backup, którego nigdy nie przywróciłeś, nie jest backupem — to nadzieja. Harmonogram testowania według priorytetu:

Tier 1 (krytyczny dla misji): pełne ćwiczenie przywracania kwartalnie, losowe przywracanie pliku miesięcznie
Tier 2 (ważny biznesowo): pełne ćwiczenie przywracania co pół roku, losowe przywracanie pliku kwartalnie
Tier 3 (standardowy): pełne ćwiczenie przywracania rocznie, losowe przywracanie pliku kwartalnie

Zapisuj w teście:

Ile zajęło przywracanie (porównaj do RTO)
Czy dane pasują do stanu produkcyjnego (sumy kontrolne względem znane punktu)
Czy uprawnienia lub konfiguracje nie przywróciły się
Co się posypało i jak było naprawione

Firmy pomijające testowanie dowiadują się o uszkodzonych backupach podczas prawdziwych incydentów — to najdroższy moment na jakąkolwiek naukę.

Backupy baz danych potrzebują własnego planu

Pliki i bazy danych backupuje się inaczej. Katalog .pgdata skopiowany w trakcie transakcji jest uszkodzony. Używaj natywnych narzędzi:

PostgreSQL: pg_basebackup + archiwizacja WAL dla PITR, pg_dump dla logicznego
MySQL: Percona XtraBackup dla fizycznego hot backup, mysqldump dla logicznego
MongoDB: mongodump, zestawy replik z opóźnionymi wtórnymi
Microsoft SQL Server: natywny backup z BACKUP DATABASE, log shipping dla PITR

Dla bazy PostgreSQL 500 GB z RPO 5 minut, nocne backupy bazowe + ciągła archiwizacja WAL do S3 daje odtwarzanie punkt-w-czasie do dowolnej sekundy z ostatnich 30 dni. Czas odtwarzania: pobierz backup bazowy (30 min), odtwórz WAL do czasu docelowego (5–30 min). Ścisłe RTO oznacza ciepłą replikę gotową do promocji.

Spójne aplikacyjnie snapshoty

Snapshoty systemu plików (ZFS, Btrfs, AWS EBS, dyski zarządzane Azure, persistent disk GCP) zamrażają punkt w czasie na poziomie bloku. Dla baz danych łącz z wyciszeniem aplikacji:

pg_start_backup('etykieta') (PostgreSQL) lub FLUSH TABLES WITH READ LOCK (MySQL)
Zrób snapshot
pg_stop_backup() lub odblokuj

Snapshot jest spójny aplikacyjnie — nadaje się do odtworzenia bez crash recovery. AWS Backup, Azure Backup i Google Cloud Backup automatyzują ten wzorzec dla typowych baz danych.

Dystrybucja archiwów backupowych do stron trzecich

Gdy backupy muszą trafić do zewnętrznych stron — audytorów, regulatorów, powierniczych następców — sam transfer wymaga ostrożności. FTP jest archaiczny; załączniki e-mail trafiają na limity rozmiarów; przekazywanie dysków USB jest powolne.

Szyfrowany end-to-end transfer plików obsługuje doraźną dystrybucję backupów czysto. HexaTransfer przenosi pliki do 10 GB z szyfrowaniem po stronie klienta AES-256-GCM i jednorazowym linkiem. Idealne do wysyłania snapshotu bazy danych do audytora bez dawania mu dostępu do Twoich bucketów S3. Ważne zwłaszcza przy transferach danych objętych RODO, gdzie odpowiednia ochrona w tranzycie jest wymagana przez prawo i kontrolowana przez UODO.

Dokumentacja jest częścią backupu

Najlepszy backup na świecie jest bezużyteczny, jeśli osoba umiejąca go przywrócić jest na urlopie i nikt inny nie wie jak. Dokumentuj:

Co jest backupowane, a co nie (jawne wykluczenia)
Harmonogram i retencja per workload
Zarządzanie kluczami i dostęp
Runbooki odtwarzania z poleceniami krok po kroku
Lista kontaktów (wsparcie dostawcy, dyżurny)
Wyniki testów i daty

Wydrukuj kopię. Przechowuj kopię w fizycznym sejfie z kluczami awaryjnymi. Jeśli Twój runbook backupu żyje tylko na stronie Confluence serwowanej z tej samej infrastruktury, która właśnie padła — masz problem. Papier nadal działa gdy nic innego nie działa.

Zdefiniuj RPO/RTO, wdróż 3-2-1 z niezmiennością, szyfruj po stronie klienta, testuj kwartalnie, dokumentuj obsesyjnie. Sukces backupu to 10% technologia i 90% dyscyplina.

Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.