Backupy bez złudzeń — zasada 3-2-1 w praktyce strony, sklepu i serwera

Jest takie stare powiedzenie, że ludzie dzielą się na dwa typy: tych, którzy robią kopie zapasowe, i tych, którzy dopiero zaczną je robić. Zwykle zaczynają nazajutrz po awarii dysku, ataku ransomware albo nieszczęśliwym „DROP TABLE” o godzinie 16:59 w piątek. W tym artykule wychodzimy poza to powiedzenie: pokazujemy, jak wygląda sensowna strategia kopii zapasowych dla strony firmowej, sklepu internetowego i serwera — od klasycznej zasady 3-2-1 po rzeczy, o których prawie wszyscy zapominają.

Zasada 3-2-1 (i jej nowsze rozszerzenia)

Fundament każdej strategii backupu mieści się w trzech cyfrach:

• 3 — trzymaj co najmniej trzy egzemplarze danych (produkcja + dwie kopie),
• 2 — na dwóch różnych nośnikach lub systemach (np. dysk serwera i storage obiektowy),
• 1 — w tym co najmniej jedną kopię poza główną lokalizacją (inne centrum danych, inna chmura).

Współczesna praktyka dokłada do tego rozszerzenie 3-2-1-1-0: dodatkowa jedynka to kopia offline albo niezmienialna (immutable) — taka, której nie skasuje ani ransomware, ani napastnik z przejętym hasłem — a zero oznacza „zero błędów przy testowym odtworzeniu”. O tym zerze za chwilę, bo to najczęściej ignorowany element całej układanki.

Co właściwie trzeba backupować przy stronie WWW?

„Robię kopię plików” to za mało. Kompletna kopia strony to co najmniej cztery warstwy:

• baza danych — w WordPressie i sklepach to tu żyje wszystko, co najcenniejsze: treści, zamówienia, klienci,
• pliki aplikacji — motyw, wtyczki, a przede wszystkim katalog uploads z mediami, których nie da się odtworzyć z repozytorium,
• konfiguracja — vhosty nginx/Apache, PHP, crontab, certyfikaty, zmienne środowiskowe; bez nich odtwarzanie serwera to archeologia,
• rzeczy „obok” serwera — strefa DNS, konfiguracja CDN/WAF, klucze API. Eksport strefy DNS zajmuje minutę, a przy przejmowaniu projektu po awarii bywa na wagę złota.

Jeśli kod trzymacie w repozytorium git (tak jak my), pliki motywu odtworzycie z repo — ale baza i uploads muszą mieć własny backup zawsze.

Strona firmowa: rozsądne minimum

Dla wizytówki czy bloga na WordPressie wystarcza prosty rytm: baza codziennie, pliki co tydzień plus dodatkowa kopia przed każdą aktualizacją wtyczek i rdzenia. Do tego dwa praktyczne wymogi: kopie muszą wychodzić poza serwer (o tym niżej) i muszą powstawać automatycznie — backup „robiony ręcznie w wolnej chwili” statystycznie nie istnieje. Backup od hostingodawcy traktujcie jako miły dodatek, nie strategię: bywa na tej samej maszynie, bywa niedostępny akurat wtedy, gdy padł cały serwer, a jego retencja rzadko przekracza kilka dni.

Sklep internetowy: tu liczy się każda godzina

W sklepie baza danych to dosłownie pieniądze — utrata dnia zamówień oznacza realne straty i chaos w magazynie. Dlatego przy e-commerce warto poznać dwa skróty, którymi posługują się admini:

• RPO (Recovery Point Objective) — ile danych możesz stracić: przy sklepie sensowne RPO to minuty lub pojedyncze godziny, nie doba,
• RTO (Recovery Time Objective) — jak szybko musisz wstać: co z tego, że masz kopię, skoro odtwarzanie zajmie trzy dni?

W praktyce oznacza to: zrzut bazy co godzinę (albo ciągła archiwizacja binlogów MySQL), pliki raz dziennie, a przy większej skali replika bazy do drugiej lokalizacji. Uwaga na klasyczną pułapkę: replikacja to nie backup — replika posłusznie powtórzy również omyłkowe skasowanie danych. I jeszcze RODO: kopie zawierają dane osobowe klientów, więc obowiązują dla nich te same zasady co dla produkcji — szyfrowanie, kontrola dostępu i retencja.

Serwer: automat, który robi się sam

Na poziomie serwera VPS warto łączyć dwa światy: snapshoty całej maszyny u dostawcy (szybkie odtworzenie po totalnej awarii) oraz kopie aplikacyjne (baza + pliki), które pozwalają wyciągnąć pojedynczą rzecz bez przywracania wszystkiego. Szkielet skryptu, który obsługuje drugą część i wysyła kopię poza serwer — do omawianego przez nas niedawno Cloudflare R2:

#!/bin/bash
set -euo pipefail
STAMP=$(date +%Y-%m-%d_%H-%M)
BACKUP_DIR=/var/backups/site

mysqldump --single-transaction --quick shop_db | gzip > "$BACKUP_DIR/db_$STAMP.sql.gz"
tar -czf "$BACKUP_DIR/files_$STAMP.tar.gz" -C /var/www/site wp-content/uploads

rclone copy "$BACKUP_DIR" r2:backups/site --include "*_$STAMP*"

# lokalnie trzymamy tylko 7 dni
find "$BACKUP_DIR" -type f -mtime +7 -delete

Wpis w cronie, powiadomienie o błędzie i gotowe. Kopie wrażliwe warto przed wysyłką zaszyfrować (age lub gpg) — wtedy nawet wyciek z bucketa nie jest katastrofą. Pamiętajcie tylko, żeby klucz deszyfrujący nie leżał wyłącznie… na backupowanym serwerze.

Gdzie trzymać kopie?

Najkrótsza odpowiedź: nie tam, gdzie produkcja. Kopia na tym samym dysku ginie razem z dyskiem, kopia na tym samym koncie hostingowym ginie razem z przejętym kontem. Dobre kierunki to storage obiektowy (R2, S3, Backblaze B2) w innej lokalizacji, z dwoma dodatkami:

• retencja wielopoziomowa — np. schemat: 7 kopii dziennych, 4 tygodniowe, 12 miesięcznych; chroni przed scenariuszem „błąd wykryty po trzech tygodniach, a wszystkie kopie już nadpisane”,
• niezmienialność (object lock / wersjonowanie) — kopia, której przez zadany czas nie może usunąć nikt, nawet administrator; to najlepsza polisa na ransomware i na przejęte klucze API. Osobne konto/poświadczenia tylko do backupów to standard, nie paranoja.

Backup, którego nie przetestowałeś, nie istnieje

Wracamy do zera z formuły 3-2-1-1-0. Kopie potrafią być puste, urwane w połowie, zaszyfrowane kluczem, którego nikt nie ma, albo robione z wyłączonej bazy. Jedyny sposób, żeby się o tym nie przekonać w dniu awarii, to regularne próbne odtworzenie: raz na kwartał postawcie stronę z kopii na środowisku testowym i kliknijcie po niej 10 minut. Do tego monitoring samego procesu — sprawdzać trzeba nie tylko „czy backup się udał”, ale przede wszystkim czy w ogóle się wykonał: zadanie, które cicho przestało startować dwa miesiące temu, to klasyka gatunku. Świetnie nadają się do tego healthchecki (np. ping po udanym skrypcie) albo opisywany przez nas niedawno Zabbix z triggerem „brak świeżego pliku kopii od 26 godzin”.

Siedem grzechów głównych

• kopia na tym samym serwerze co produkcja,
• backup plików bez bazy danych (albo odwrotnie),
• replikacja lub RAID traktowane jako backup,
• brak kopii przed aktualizacjami i wdrożeniami,
• szyfrowane archiwum, do którego hasło zna jedna osoba (albo nikt),
• retencja „ostatnie 3 dni”, podczas gdy błędy wychodzą po tygodniach,
• zero testów odtwarzania — czyli wiara zamiast wiedzy.

Podsumowanie

Dobry backup jest nudny: robi się sam, leży w kilku miejscach, w tym jednym nietykalnym, a raz na jakiś czas ktoś sprawdza, że da się z niego wstać. Cała ta „nuda” kosztuje ułamek tego, co jedna poważna awaria bez kopii. W ramach stałej opieki technicznej konfigurujemy naszym klientom dokładnie taki układ — z automatyką, kopiami poza serwerem i monitoringiem, który upomni się o brakujący backup, zanim ktokolwiek go potrzebuje. Nie jesteś pewien, czy Twoje kopie naprawdę działają? Sprawdźmy to razem — najlepiej zanim będą potrzebne.