Backup, który leży na tej samej macierzy co produkcja, nie jest backupem. Pokazujemy, jak z Proxmox Backup Server złożyć pełną strategię 3-2-1: z deduplikacją, retencją GFS, weryfikacją, szyfrowaniem i ochroną przed ransomware.
Reguła 3-2-1 mówi: trzymajcie 3 kopie danych (produkcja plus dwa backupy), na 2 różnych nośnikach lub systemach, z czego 1 kopia poza lokalizacją. To nie jest dogmat wymyślony przez sprzedawców storage'u. Każdy element odpowiada na konkretny scenariusz awarii.
rm -rf z niewłaściwego okna zabiera wszystko naraz.Ransomware zasługuje na osobne zdanie. Nowoczesne ataki zaczynają od znalezienia i zniszczenia backupów, a dopiero potem szyfrują produkcję. Strategia 3-2-1 działa przeciw ransomware tylko wtedy, gdy przynajmniej jedna kopia jest poza zasięgiem poświadczeń, które atakujący może przejąć. Do tego wrócimy niżej.
W środowisku Proxmox VE naturalny układ wygląda tak:
Sync joby w PBS są zaprojektowane pod łącza, które nie zawsze są idealne. Przesyłają tylko brakujące bloki (przyrostowo, z wykorzystaniem tej samej deduplikacji co lokalnie), są wznawialne po zerwaniu połączenia i spokojnie mogą iść po VPN, na przykład tunelem WireGuard między lokalizacjami. Po pierwszej pełnej synchronizacji dzienny ruch to zwykle ułamek rozmiaru środowiska, bo idą tylko zmienione bloki.
Jak taki serwer zwymiarować i skonfigurować od strony sprzętu i datastore opisujemy na stronie usługi wdrożenia Proxmox Backup Server. Jeśli dopiero projektujecie klaster, zajrzyjcie też do artykułu Ceph czy ZFS, bo wybór storage produkcyjnego wpływa na strategię backupu.
PBS ma wbudowany mechanizm prune w modelu GFS (grandfather-father-son): zachowaj N ostatnich kopii dziennych, N tygodniowych, N miesięcznych, N rocznych, resztę usuń. Prune oznacza snapshoty do skasowania, a garbage collection zwalnia bloki, do których nic już nie wskazuje.
Dla typowej firmy sensowny punkt startowy to: 7 kopii dziennych, 4 tygodniowe, 6 miesięcznych. Taki układ pokrywa większość realnych scenariuszy: "coś zepsuliśmy wczoraj", "faktura z zeszłego tygodnia zniknęła", "potrzebujemy stanu bazy sprzed kwartału". Dzięki deduplikacji różnica w zajętości między 7 a 14 kopiami dziennymi jest niewielka, więc nie ma sensu oszczędzać na krótkiej historii.
Retencję dostosowujcie do wymogów prawnych i branżowych: dane księgowe, dokumentacja medyczna czy wymogi projektów publicznych potrafią narzucać przechowywanie liczone w latach. Wtedy dochodzą kopie roczne, a czasem osobny datastore z inną polityką. Ważne, żeby polityka retencji była decyzją biznesową spisaną na papierze, a nie przypadkowym ustawieniem z dnia instalacji.
Backup, którego nikt nie sprawdza, degraduje się po cichu. Bit rot na dyskach, uszkodzone sektory, błędy RAM: to wszystko może uszkodzić bloki backupu tak, że zauważycie dopiero przy restore, czyli w najgorszym możliwym momencie. Dlatego w PBS konfigurujemy verify joby: cykliczne zadania, które czytają snapshoty i porównują sumy kontrolne bloków z indeksami. Cicha korupcja wychodzi na jaw w raporcie, nie podczas awarii.
Drugi element to szyfrowanie client-side. Klient backupu (Proxmox VE) szyfruje dane przed wysłaniem, więc PBS przechowuje je już zaszyfrowane i nigdy nie widzi ich otwartym tekstem. To ważne szczególnie dla kopii zdalnej: możecie ją trzymać u partnera albo w wynajętej kolokacji bez obaw, że ktoś po drugiej stronie przeczyta wasze dane.
Klucz szyfrowania to pojedynczy punkt awarii. Bez klucza restore nie istnieje: nie ma procedury odzyskania, nie ma supportu, który pomoże. Trzymajcie klucz poza infrastrukturą, którą backup chroni, i zróbcie jego kopię: wydruk w sejfie plus egzemplarz w firmowym menedżerze haseł to rozsądne minimum.
Atakujący, który przejmie konto administratora Proxmox VE, nie może mieć z tego samego miejsca możliwości skasowania backupów. W praktyce oznacza to kilka zasad:
Te mechanizmy są częścią szerszego tematu utwardzania środowiska, który rozwijamy w checkliście bezpieczeństwa Proxmox.
Nie doradzamy niczego, czego sami nie używamy. Hosting IQHost działa na klastrach Proxmox z 8 węzłami, a backupy odbierają dwa serwery Proxmox Backup Server w dwóch lokalizacjach, łącznie ponad 100 TB. Kopia offsite z zasady 3-2-1 nie jest u nas teorią, tylko drugą serwerownią. Dzięki deduplikacji realna historia backupów jest dużo dłuższa, niż wynikałoby z surowej pojemności: kolejne kopie tej samej maszyny to głównie referencje do bloków, które już leżą w datastore.
Ten setup regularnie testujemy pełnym przywróceniem maszyn, nie tylko weryfikacją sum kontrolnych. Jak taki test wygląda w praktyce i co z niego wynikło, opisaliśmy w case study testu przywracania z PBS. Samą architekturę klastra znajdziecie w case study klastra IQHost.
Dwie pułapki, które widzimy najczęściej. Pierwsza: trzy kopie na jednej macierzy to w praktyce jedna kopia, bo giną razem przy jednej awarii kontrolera lub jednym błędzie. Druga: backup, którego nigdy nie przywrócono testowo, to hipoteza, nie zabezpieczenie. Dopóki nie zrobicie pełnego restore i nie zmierzycie, ile trwał, nie wiecie, czy macie backup.
O tym, jak zaplanować i przeprowadzać testy odtwarzania, piszemy osobno w artykule o testach restore i disaster recovery.
Nie. Replikacja chroni przed awarią sprzętu, ale powiela też błędy: skasowany plik, zaszyfrowana baza czy uszkodzony system zostaną zreplikowane w ciągu sekund lub minut. Backup daje historię wersji, do której można wrócić. Replikacja i backup rozwiązują różne problemy i w poważnym środowisku potrzebujecie obu.
Mniej, niż wynikałoby z prostego mnożenia rozmiaru VM przez liczbę kopii. PBS deduplikuje dane na poziomie bloków, więc kolejne backupy tej samej maszyny zajmują tylko tyle, ile zmienionych bloków. W praktyce datastore mieści wielokrotnie dłuższą historię, niż sugeruje surowa pojemność. Dokładne zapotrzebowanie zależy od tempa zmian danych, dlatego wymiarujemy je na podstawie realnego środowiska.
Tracicie dostęp do wszystkich zaszyfrowanych kopii. PBS przechowuje dane już zaszyfrowane po stronie klienta i nie zna klucza, więc bez niego restore nie istnieje. Klucz trzeba trzymać poza infrastrukturą, którą backup chroni, i mieć jego kopię, na przykład wydruk w sejfie oraz egzemplarz w menedżerze haseł firmy.
Sprawdzimy, czy wasza strategia backupu naprawdę spełnia 3-2-1, czy tylko tak wygląda w prezentacji. Bez zobowiązań, konkretna rozmowa techniczna z inżynierem, który sam utrzymuje PBS na produkcji.
Umów rozmowę o backupie