Backup odporny na ransomware:
Proxmox Backup Server

Dlaczego lokalny snapshot to za mało

Snapshoty na tym samym storage co maszyna giną razem z klastrem. Ransomware, który wejdzie na hypervisor albo na udział NFS, szyfruje dyski i kopie w jednym ruchu. Proxmox Backup Server stoi obok: osobny host, osobny datastore, osobne konto API. Podręcznik PBS nazywa to wprost ochroną przed ransomware: drobnoziarnista kontrola dostępu, weryfikacja integralności i kopia poza ośrodkiem przez remote sync albo taśmę.

Co PBS daje z pudełka

PBS to rozwiązanie klient–serwer (AGPLv3) zoptymalizowane pod Proxmox VE. Klient wbudowany w PVE zrzuca maszyny i kontenery; proxmox-backup-client obsługuje też hosty fizyczne. Stos jest w Rust. Namespace pozwala rozdzielić klastry i środowiska na jednym datastore bez mieszania ACL. Oficjalne cechy:

Subskrypcja PBS (Basic / Standard / Premium) otwiera repozytorium Enterprise i portal klienta. Sam serwer działa bez subskrypcji; to ten sam model co Proxmox VE.

Model 3-2-1 na PBS

Podręcznik PBS cytuje regułę 3-2-1: trzy kopie, dwa nośniki, jedna poza ośrodkiem. Na stosie Proxmox wygląda to tak:

• Kopia 1 — produkcja: dyski VM na ZFS, LVM-thin, NFS albo Ceph. To nie jest backup.
• Kopia 2 — PBS lokalny: datastore na osobnym serwerze (albo w drugiej szafie). Prune i garbage collection tylko na PBS, nie z tokena klastra.
• Kopia 3 — drugi ośrodek albo taśma: sync job na zdalny PBS albo job taśmowy. Sync można ustawić tak, by nie usuwał snapshotów, które zniknęły na źródle — atakujący ze źródła nie czyści celu.

Jeśli źródło padnie ransomware’em, sync zwykle kończy się błędem i leci powiadomienie. Taśma (w tym WORM) jest drugim nośnikiem i da się ją wynieść do sejfu albo poza budynek.

Uprawnienia: backup bez kasowania

Rola Datastore.Backup pozwala tworzyć kopie, ale nie kasować ani zmieniać istniejących. Dobre praktyki z podręcznika:

• Osobny token API na każdy host albo klaster PVE.
• Jedno uprawnienie, wąska ścieżka ACL — np. /datastore/tank/pve-abc-cluster (namespace).
• Prune wyłącznie zadaniami na PBS, nie z klienta.
• Nie dawać tokenowi synca prawa usuwania — ten sam wzorzec co przy backupie.

Wykrywanie i test odtworzenia

Jeśli ransomware zaszyfruje datastore PBS, sumy SHA-256 nie zgadzają się z zapisem — odtworzenie się wywali. Zadania weryfikacji regularnie to sprawdzają i zaczną padać. Podręcznik ostrzega: wystarczająco sprytny ransomware może ten mechanizm obejść, więc weryfikacja to warstwa dodatkowa, nie wystarczająca.

Skuteczniejszy test: odtwarzać na nowego gościa, nie nadpisując produkcji. Przy wielu VM — automatyzować; jeśli nie, losowe próbki raz na tydzień albo miesiąc. Długa retencja jest potrzebna, bo część ransomware leży uśpiona dni albo tygodnie, zanim zacznie szyfrować. Weryfikacja datastore i restore na izolowanego gościa to dwa różne testy: pierwszy łapie uszkodzony chunk, drugi łapie, że kopia wstaje i aplikacja odpowiada.

Co wdrażamy w firmie

To landing usługi, nie sam poradnik. W pakiecie:

• Projekt: PBS lokalny + drugi ośrodek (sync) albo taśma, namespace per klaster, 2FA na realmie PBS.
• Tokeny tylko do zapisu, prune i GC na serwerze, zadania weryfikacji, powiadomienia (SMTP / webhook).
• Harmonogram kopii z PVE, szyfrowanie po stronie klienta, procedury odtworzenia VM i CT.
• Test odtworzenia na próbce i runbook na incydent ransomware.

Porównanie z Veeam jest w osobnym artykule Veeam vs PBS. Dobór datastore pod kopie — w doborze storage.

Klucze szyfrowania i odzyskiwanie

AES-256-GCM po stronie klienta oznacza, że serwer PBS trzyma ciphertext. Podręcznik przewiduje klucz szyfrowania kopii i osobny master key do odzyskania kluczy — bez master key utrata hasła klienta jest utratą danych, nie „przypomnieniem hasła na portalu”. Klucze trzymamy poza klastrem produkcyjnym i poza samym PBS (sejf, osobny secret store), w dwóch kopiach.

Szyfrowanie nie zastępuje ACL. Skompromitowany token z Datastore.Backup nadal może dopisywać nowe snapshoty. Nie może przepisać starych bloków — ale może zalać datastore śmieciem, jeśli nie ma kwot i alertów na zapełnienie.

Runbook incydentu ransomware

• Oderwać produkcję od PBS: wyłączyć joby backupu z klastra, zostawić sync bez usuwania znikniętych snapshotów.
• Nie logować się na PBS tokenem, który był na skonpromitowanym klastrze. Konsola z osobnego jump hosta, konto tylko do odczytu / restore.
• Weryfikacja datastore (SHA-256) na próbce grup, potem restore na nowego gościa w izolowanej sieci — nie na oryginalne VMID.
• Nie odtwarzać „w miejscu” na zaszyfrowaną produkcję i nie odpalać prune/GC „żeby zrobić miejsce” w trakcie incydentu.

To jest treść usługi, nie checkbox w GUI. Testujemy runbook na próbce zanim ktoś zaszyfruje klaster — inaczej pierwszy raz ćwiczycie go pod presją. Porównanie z Veeam: Veeam vs PBS.

Prune, GC i retencja

Podręcznik PBS rozdziela prune od garbage collection. Prune usuwa metadane snapshotu wg polityki (keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly). Chunki zostają, dopóki GC ich nie zabierze — i to dopiero po okresie karencji, żeby przypadkowy prune nie zjadł danych, które inny snapshot jeszcze trzyma.

Politykę prune ustawiamy zadaniami na PBS, nie z tokena klastra. Sync na drugi ośrodek może nie usuwać snapshotów, które zniknęły na źródle: atakujący z produkcją nie czyści celu. Taśma (w tym WORM) jest drugim nośnikiem; bibliotekę i pule mediów opisuje ten sam podręcznik, nie osobny produkt.