Backupy firmowe według 3-2-1: co testujesz, czego nie testują nawet duzi

Pierwsza noc na dyżurze, którą zapamiętasz na zawsze, to ta, kiedy klient dzwoni o 23:47 z pytaniem "macie backup z wtorku?". Masz. Pliki .sql leżą w S3, ostatni zrzut z 03:00. Tylko nikt nigdy nie próbował z nich wstać. Po godzinie wiesz, że plik rozjechał się z replikacją w sobotę i baza, którą próbujesz odtworzyć, nigdy nie zaistniała w takiej formie w produkcji.

Backup, którego nie testujesz, nie istnieje. To zdanie nudzi już chyba wszystkich w branży, ale 8 na 10 firm, które wpadają do nas z prośbą o audyt infrastruktury, ma ten sam problem: backup wykonuje się co noc, restore nigdy się nie wykonał.

Ten tekst nie jest o tym, że "warto mieć backup". Jest o tym, co konkretnie zrobić, żeby w noc, kiedy zadzwoni telefon, mieć z czego wstać.

Reguła 3-2-1, plus jeden warunek z 2026

Klasyk z lat 80., wciąż aktualny:

• 3 kopie danych (oryginał + 2 backupy)
• 2 różne nośniki (np. dysk produkcyjny + obiekt w chmurze)
• 1 kopia poza lokalizacją (off-site)

W 2026 dorzucamy literę zero: 0 kopii podatnych na modyfikację po wykonaniu. Niemutowalność (immutable backup, Object Lock w S3, WORM w GCS) to dziś nie luksus, tylko obrona przed ransomware. Atakujący, który dostał się do twojego konta AWS, najpierw zniszczy backupy, zanim zaszyfruje produkcję. Jeśli wszystkie twoje kopie zapasowe leżą w tym samym koncie z pełnymi prawami operacyjnymi, atakujący dostaje backup równo z produkcją.

W praktyce dla małej firmy oznacza to:

• backup w buckecie S3 z włączonym Object Lock w trybie Compliance, retencja minimum 30 dni
• osobne AWS Account na backupy z replikacją cross-account
• klucze IAM, które tylko zapisują (write-only), nie czytają i nie kasują
• raz na kwartał test "całkowita utrata konta głównego, ile odzyskamy z osobnego account"

RTO i RPO: dwie cyfry, których nie znasz, a powinieneś

Większość ludzi mówi "robimy backup co noc", jakby to była odpowiedź. To nie jest odpowiedź. To są dwa pytania.

RPO (Recovery Point Objective) to ile danych jesteś w stanie stracić. Backup nocny to RPO = 24h, więc jeśli dysk padnie o 18:00, tracisz 15 godzin pracy klientów. Dla sklepu internetowego w środku Black Friday to mogą być setki tysięcy złotych w transakcjach, których nie odzyskasz, plus chargebacki, plus klienci, którzy nigdy nie wrócą.

RTO (Recovery Time Objective) to jak długo możesz być wyłączony. Backup w S3 Glacier jest tani (kilka groszy za GB), ale jego restore trwa 6–12h. Jeśli twój RTO to 1h, Glacier ci nie pomoże, nawet jeśli go masz.

Zanim wybierzesz technologię, ustal te dwie liczby per system:

| System | RPO | RTO | Co to oznacza | |---|---|---|---| | Strona firmowa | 24h | 4h | Nocny backup na S3 Standard wystarczy | | Sklep e-commerce | 5 min | 30 min | Replikacja synchroniczna + warm standby | | Baza klientów (CRM) | 1h | 2h | Continuous backup + szybki restore | | Pliki marketingowe | 24h | 24h | Daily backup do S3 Glacier OK |

Bez tych liczb wybierasz w ciemno i prawie zawsze przepłacasz albo niedopłacasz.

Co konkretnie testować i jak często

Backup nie istnieje, dopóki ktoś nie odtworzył z niego działającego systemu w środowisku, które nie jest produkcją. Cztery poziomy testów, każdy z inną częstotliwością:

Co tydzień: file-level restore. Wybierasz losowy plik sprzed 7 dni, próbujesz go odzyskać. Trwa to 5 minut, ale wyłapuje 80% problemów: zepsute uprawnienia, błędna kompresja, brakujące metadane.

Co miesiąc: full database restore. Bierzesz pełny zrzut bazy z backupu, ładujesz do osobnego środowiska, włączasz aplikację, klikasz przez krytyczne ścieżki. Wyłapuje problemy z wersjami silnika bazy, brakującymi rozszerzeniami, niezsynchronizowanymi schemami.

Co kwartał: tabletop exercise. Zespół siada przy stole, ktoś rzuca scenariusz ("kradzież dysku z biura, jak odzyskujemy?"), wszyscy mówią głośno, co by zrobili. Bez klikania w nic. Wyłapuje luki w runbookach, w dokumentacji, w wiedzy zespołu: ktoś jest na urlopie, ktoś nie zna procedury, hasło do vaulta zna tylko jedna osoba.

Co rok: chaos exercise. Real disaster drill. Wyłącza się produkcyjny serwer (powiadomieni szefostwa, ale nie zespół operacyjny), mierzy czas do pełnego restore. Niepopularne. Bardzo skuteczne.

Większość firm robi tylko poziom pierwszy. Najczęściej automatycznie i bez zaglądania, czy się udało.

5 błędów, które widzimy najczęściej u nowych klientów

1. "Backup mamy w S3" bez wskazania, od kiedy nie był testowany. Częsta odpowiedź: nigdy.

2. Wszystko w jednym koncie chmurowym. Atakujący dostaje IAM root, kasuje produkcję, kasuje backupy, kasuje logi. Trzy minuty pracy, twoja firma znika. Backup musi być w osobnym koncie z osobnym billingiem i osobnymi kluczami.

3. Brak alarmu na "backup nie wykonał się". Skrypt cron, który padł 3 miesiące temu i nikt nie zauważył. Discord, Slack albo Sentry notyfikacja na każdy failed job to standard, nie ekstra.

4. Hasła do backupów w tym samym vaulcie co produkcja. Master password do 1Password leży obok hasła do bazy, do której masz backup. Atakujący, który dostał vault, dostaje wszystko, włącznie z możliwością wyzerowania niemutowalności jutro rano.

5. "Snapshot RDS to backup". Snapshot to backup tylko jeśli jest skopiowany do innego konta i innego regionu, z niemutowalnością. AWS-owy snapshot w tym samym koncie to nie backup, to wygodny rollback.

Pułapki per silnik bazy

Postgres. pg_dump to logical backup: wolny przy dużych bazach, ale przenośny między wersjami. pg_basebackup to physical backup: szybszy restore, ale ten sam major version. Continuous backup (WAL archiving, np. przez pgBackRest lub wal-g) jest must-have dla RPO poniżej 1h. Test restore na osobnym hoście, nie na replice.

MySQL/MariaDB. mysqldump dla małych baz, xtrabackup (Percona, free) dla większych. Pamiętaj o --single-transaction dla InnoDB, żeby nie blokować produkcji. Binary log do PITR (point-in-time recovery).

MongoDB. mongodump jest oczywisty, ale dla większych deploymentów mongo-tools zwolnią cluster. Ops Manager / Cloud Manager robią backup snapshotami volume. Dla replica setów: backup z secondary node, nigdy z primary.

SQLite. Tak, też trzeba. .backup zamiast kopiowania pliku, bo write w trakcie kopiowania równa się uszkodzony backup. W kontenerze: litestream replikuje do S3 w czasie rzeczywistym, znacznie lepiej niż cron z .backup.

Checklist: 10 punktów do sprawdzenia w twojej firmie

1. Wiesz, jakie są RPO i RTO dla każdego krytycznego systemu, zapisane gdzieś, nie tylko w głowie.
2. Backup jest w osobnym koncie chmurowym lub fizycznie poza lokalizacją produkcyjną.
3. Backup jest niemutowalny (Object Lock, WORM, immutable snapshot).
4. Co najmniej jeden test restore się wykonał w ciągu ostatnich 30 dni.
5. Failed backup wysyła alert do Slack, Discord albo e-mail, nie tylko do logu na dysku.
6. Backup jest szyfrowany at-rest z osobnymi kluczami od kluczy produkcyjnych.
7. Hasła i klucze do backupów są poza vaultem produkcyjnym.
8. Runbook restore istnieje i był aktualizowany w tym roku.
9. Dwie osoby w firmie wiedzą, jak odzyskać dane (nie jeden DevOps).
10. Backup zawiera nie tylko bazę: pliki użytkowników, konfigi, secrets, certyfikaty.

Jeśli zaznaczyłeś mniej niż 6, masz problem, którego jeszcze nie widzisz.

Co robimy u klientów

W ramach managed hostingu i cloud setup zwykle ustawiamy:

• backupy bazy danych z continuous archiving (RPO poniżej 5 min)
• cross-account replication do osobnego AWS Account z innym ownerem
• Object Lock z 30–90 dniową retencją niemutowalną
• automated monthly restore tests (skrypt restoruje do staging, weryfikuje, raportuje)
• runbook na disaster recovery, aktualizowany przy każdej większej zmianie infrastruktury
• 24/7 monitoring backup jobs z alarmami w Slack lub Discord

Jeśli twoja firma robi backup, ale nie jest pewna, czy faktycznie działa, napisz do nas. Robimy darmowy audyt backupów: 1h spotkanie plus raport co do tygodnia, gdzie jest ryzyko i co można poprawić bez wymiany infrastruktury.