Backup 3-2-1 w praktyce. Dlaczego większość firm robi go źle?

Co naprawdę oznacza reguła 3-2-1

Trzy kopie danych. Dwa różne typy nośników. Jedna kopia poza lokalizacją główną. To definicja, którą można znaleźć wszędzie — i którą większość firm interpretuje błędnie. "Mam trzy kopie" nie znaczy nic, jeśli wszystkie trzy leżą na tym samym serwerze lub w tej samej szafie. Awaria zasilania, pożar, zalanie — i tracisz wszystko naraz.

Dwa różne nośniki to nie "dwie partycje na tym samym dysku". To np. lokalne NAS z dyskami i zewnętrzny serwer backup w innej lokalizacji. Albo tape i replikacja sieciowa. Chodzi o to, żeby jedna klasa usterki (awaria konkretnego modelu dysku, ransomware, uszkodzenie kontrolera) nie zniszczyła obu kopii jednocześnie.

Kopia offsite to kopia, która fizycznie nie leży w tym samym budynku. Nie w serwerowni na tym samym piętrze. Nie w pomieszczeniu obok. Inna lokalizacja — inna sieć zasilająca, inny adres, inny operator. Dla większości firm nie trzeba budować drugiej serwerowni — wystarczy dostawca backup-as-a-service lub kolokacja z przestrzenią na PBS.

Najczęstsze błędy, które widzieliśmy

Backup na tym samym serwerze co dane. Wolumen /backup zamontowany lokalnie, rsync do katalogu /backup/daily. Przy awarii dysku lub zaszyfrowania przez ransomware — kopia znika razem z oryginałem. To nie jest backup, to migawka na tym samym nośniku.

Backup, który przestał się odpalać trzy miesiące temu. Skrypt crona, który wywalał się po cichu z błędem permissions denied. Zadanie w Veeam, które nie miało wolnego miejsca docelowego. Nikt nie sprawdzał logów, bo "backup działa". Odkrycie tego w momencie potrzeby przywrócenia danych jest jednym z najbardziej stresujących doświadczeń, jakie spotkał administrator systemu.

Brak testu odtworzenia. To chyba najgroźniejszy błąd, bo daje fałszywe poczucie bezpieczeństwa. Plik kopii istnieje, rozmiar się zgadza — ale nikt nie sprawdził, czy da się z niego odtworzyć działający system. Uszkodzone archiwa tar, niekompletne snapshooty, brakujące zależności — to rzeczy, które wychodzą tylko przy próbie przywrócenia.

Ransomware zmienił zasady

Klasyczne podejście do backupu zakładało ochronę przed awarią sprzętu i błędem ludzkim. Ransomware dodał trzeci scenariusz: aktywny atak, który celowo niszczy lub szyfruje dane — włącznie z kopiami zapasowymi dostępnymi z zainfekowanego systemu. Jeśli serwer backupu jest zamontowany przez sieć (SMB, NFS, S3 bez odpowiedniej ochrony), ransomware zaszyfruje go razem z resztą.

Odpowiedź na to zagrożenie to immutable storage — kopie, których nie można nadpisać ani usunąć przez określony czas, nawet przez konto z uprawnieniami administracyjnymi. Proxmox Backup Server oferuje tryb Garbage Collection z ochroną retencji. Systemy obiektowe takie jak MinIO lub S3 mają Object Lock. Tape z wysuniętą kasetą to najprostszy air-gap.

Air-gap — fizyczna lub logiczna separacja kopii od sieci produkcyjnej — jest najtwardszym zabezpieczeniem. Kopia, do której ransomware nie ma połączenia sieciowego, nie może być zaszyfrowana przez sieć. W praktyce: backup na taśmie, pendrive transportowany fizycznie, lub serwer backupu bez stałego dostępu z sieci produkcyjnej (dostęp tylko inicjowany przez serwer backup, nie przez klienty).

Proxmox Backup Server jako centrum backupu

PBS to narzędzie open-source od twórców Proxmox VE, zaprojektowane specjalnie do backupu maszyn wirtualnych i kontenerów. Jego główna zaleta to deduplikacja po stronie klienta przed transferem — backup maszyny, która zmieniła 2% danych, przesyła tylko te 2%. Przy codziennych backupach dużych VM to różnica między backupem zajmującym godzinę a dziesięć minut.

Szyfrowanie client-side oznacza, że dane są szyfrowane przed opuszczeniem hypervisora. Serwer PBS nie ma dostępu do niezaszyfrowanych danych — co jest kluczowe przy lokalizacji backupu offsite. Klucz szyfrowania pozostaje u Ciebie. Zgubienie klucza oznacza trwałą utratę backupów — przechowuj go osobno od serwera PBS.

PBS obsługuje zbieranie backupów z wielu węzłów Proxmox VE jednocześnie. Jeden serwer PBS może być centrum backupu dla całego klastra. Polityki retencji konfiguruje się per-datastore: ile kopii dziennych, tygodniowych, miesięcznych przechować. Po upływie retencji PBS nie usuwa bloków danych automatycznie — robi to podczas garbage collection, co chroni przed przypadkowym usunięciem.

RPO i RTO — zdefiniuj zanim pojawi się potrzeba

RPO (Recovery Point Objective) to maksymalna akceptowalna utrata danych wyrażona w czasie — ile godzin lub minut pracy możesz stracić bez poważnych konsekwencji. Jeśli backup działa raz na dobę, Twoje RPO w najgorszym scenariuszu to 24 godziny. Dla bazy danych transakcyjnej to może być katastrofa. Dla archiwum plików — akceptowalny kompromis.

RTO (Recovery Time Objective) to czas, w jakim musisz przywrócić systemy do pracy. Nie czas, w jakim chciałbyś to zrobić — czas, po przekroczeniu którego straty biznesowe stają się nieakceptowalne. RTO dwóch godzin dla systemu ERP wymaga innych narzędzi niż RTO dwóch dni dla serwera deweloperskiego.

Te dwa parametry powinny być zdefiniowane pisemnie, zatwierdzone przez kogoś od biznesu i przeglądane co roku. Bez nich niemożliwe jest racjonalne planowanie backupu — bo nie wiesz, do jakiego celu strzelasz. Zbyt agresywne RPO/RTO kosztują dużo więcej w infrastrukturze backupu. Zbyt luźne — wychodzą na jaw przy pierwszej poważnej awarii.

Harmonogram i retencja — dlaczego 7 dni to za mało

Standardowy harmonogram produkcyjny: backup codzienny przez 14-30 dni, tygodniowy przez 3 miesiące, miesięczny przez rok. Uzasadnienie: ransomware lub błąd danych może nie zostać wykryty przez kilka dni. Backup z wczoraj może być już zainfekowany. Backup sprzed 10 dni — prawdopodobnie czysty.

Retencja 7 dni jest powszechna dlatego, że jest tania i prosta — nie dlatego, że jest właściwa. Przy codziennym przyroście 50 GB i efektywnej deduplikacji PBS, retencja 30 dni dziennych backupów może zajmować mniej niż 200 GB efektywnego miejsca. Koszty przechowania tych dodatkowych kopii są nieporównywalnie mniejsze niż koszty utraty danych sprzed 3 tygodni.

Backup miesięczny i roczny ma osobne uzasadnienie: compliance, audyt, możliwość cofnięcia się do stanu danych sprzed modyfikacji, która okazała się błędna dopiero po miesiącach. To jest inne narzędzie niż disaster recovery — bardziej archiwizacja, która przypadkowo jest też backupem.

Test odtworzenia — jedyna prawdziwa miara wartości backupu

Test odtworzenia powinien być zaplanowaną, powtarzalną procedurą — nie jednorazowym eksperymentem. Minimum: raz na kwartał przywróć losowo wybraną maszynę lub zestaw danych z kopii starszej niż 2 tygodnie do środowiska testowego i zweryfikuj integralność danych oraz działanie usług.

Co sprawdzić podczas testu: czy maszyna startuje po przywróceniu, czy dane aplikacyjne są spójne (np. baza danych przechodzi FSCK lub odpowiada na zapytania), czy certyfikaty i klucze są obecne, czy konfiguracja sieci jest poprawna. Przetestuj też czas trwania odtworzenia — to jest Twoje realne RTO, nie teoretyczne.

Automatyczne weryfikacje PBS (sprawdzanie sum kontrolnych bloków) i status "verified" w interfejsie to dobry sygnał, ale nie zastąpią pełnego testu funkcjonalnego. Backup może być integralny (nieprzerwany, sumy się zgadzają) i jednocześnie bezużyteczny — np. gdy archiwizuje uszkodzone pliki bazy danych lub niekompletną migawkę.

Jak wygląda backup offsite u nas

Oferujemy dedykowaną przestrzeń na Proxmox Backup Server w naszym datacenter jako miejsce docelowe dla backupu offsite. Twój PBS lub Proxmox VE łączy się przez szyfrowany tunel z naszym PBS i przesyła kopie z deduplikacją i szyfrowaniem client-side. Dostęp do Twoich danych mamy tylko w zakresie fizycznego przechowania — klucz szyfrowania pozostaje u Ciebie.

Konfiguracja jest prosta: dodajesz nasze PBS jako dodatkowy storage w Proxmox VE, konfigurujesz harmonogram backupu na ten storage i retencję. Reszta działa automatycznie. Monitorujemy dostępność i zajętość przestrzeni, ale nie przeglądamy zawartości kopii.

Jeśli masz inne środowisko niż Proxmox — porozmawiajmy. Możemy udostępnić przestrzeń S3-compatible, SFTP lub zaszyfrowany wolumen sieciowy, który możesz podpiąć do Veeam, Nakivo, Restic lub dowolnego innego narzędzia backupu wspierającego te protokoły.