Proxmox Backup Server na VPS jako zdalny magazyn kopii

Co w praktyce daje Proxmox Backup Server na VPS

Proxmox Backup Server (PBS) na VPS stanowi zdalny cel kopii zapasowych, który obsługuje ten sam protokół, co klaster Proxmox VE (virtual environment). Dzięki temu każda kopia zapasowa po pierwszej jest przyrostowa, deduplikowana między gośćmi, szyfrowana przed opuszczeniem lokalizacji i weryfikowalna po zakończeniu procesu. Należy wynająć VPS z wolumenem blokowym, zainstalować PBS na Debian 13, utworzyć jeden datastore na tym wolumenie i dodać go w Proxmox VE jako pamięć masową typu pbs. Instalacja zajmuje dziesięć minut. Wszystko, co następuje później – przestrzenie nazw (namespaces), garbage collection, przechowywanie kluczy oraz faktycznie wykonane przywracanie danych – decyduje o tym, czy kopia zapasowa będzie użyteczna za rok.

Powodem, dla którego warto używać PBS zamiast kopiowania plików vzdump na wynajęty dysk, jest magazyn fragmentów (chunk store). Klient dzieli każdy dysk gościa na fragmenty o rozmiarze około 4 MiB, oblicza ich skróty i przesyła tylko te fragmenty, których datastore jeszcze nie posiada. W przypadku działającej maszyny wirtualnej QEMU śledzi zmienione bloki w mapie bitowej (dirty bitmap) po wykonaniu pierwszej kopii zapasowej, więc kolejne uruchomienie odczytuje z dysku lokalnego tylko te bloki. Gość o rozmiarze 200 GB, w którym zmienia się 3 GB danych dziennie, przesyła około 3 GB dziennie. To właśnie sprawia, że domowe łącze i wynajęty wolumen współpracują ze sobą, i dlatego VPS jako zdalny cel kopii zapasowych przewyższa zapasowy dysk u znajomego. Jeśli nadal rozważasz, gdzie powinien znajdować się sam hypervisor, Proxmox w domu kontra wynajęty VPS omawia to zagadnienie osobno.

Dobierz rozmiar wolumenu przed wynajęciem

Dobór rozmiaru to operacja arytmetyczna wykonywana na własnych danych. Należy przyjąć przestrzeń faktycznie zajmowaną przez każdego gościa, a nie rozmiar jego wirtualnego dysku, a następnie dodać dzienną zmianę pomnożoną przez liczbę dni przechowywania. Kompresja i deduplikacja poprawiają ten wynik, dlatego należy traktować go jako górną granicę, a nie cel.

[
  {
    "label": "web VM",
    "used_gb": 40,
    "daily_change_gb": 0.8,
    "store_gb": 64
  },
  {
    "label": "mail VM",
    "used_gb": 120,
    "daily_change_gb": 3.0,
    "store_gb": 210
  },
  {
    "label": "file server container",
    "used_gb": 300,
    "daily_change_gb": 1.5,
    "store_gb": 345
  }
]

Wiersze te stanowią przykład obliczeniowy, a nie pomiar. Odczytaj zajęte miejsce za pomocą df -h wewnątrz każdego gościa, a dzienną zmianę odczytaj z rozmiaru drugiego i trzeciego backupu w dzienniku zadań PBS, gdy tylko się pojawią.

Gość pocztowy w przykładzie zajmuje 120 GB i zmienia się o około 3.0 GB dziennie, więc trzydzieści dziennych migawek wymaga około 210 GB: jedna pełna kopia plus trzydzieści dni zmian. Zsumuj ostatnią kolumnę dla wszystkich 3 gości, co daje łącznie około 619 GB. Dodaj jedną piątą tej wartości na indeksy, metadane oraz przestrzeń potrzebną dla procesu garbage collection, co wskazuje na wolumen o rozmiarze 1 TB.

Reszta planu jest niewielka. PBS działa poprawnie z 2 GB pamięci RAM, a 4 GB zapewnia komfort pracy, ponieważ kosztowne operacje odbywają się po stronie klastra: węzeł Proxmox VE odczytuje dyski gości oraz wykonuje dzielenie na fragmenty (chunking) i haszowanie. Zadaniem VPS jest zapisywanie fragmentów oraz wykonywanie dwóch obciążających zadań: garbage collection i weryfikacji. Wynajmij datastore jako osobny wolumen blokowy, zamiast jednego dużego dysku głównego, ponieważ wolumen można później powiększyć bez konieczności przebudowy serwera.

Instalacja Proxmox Backup Server na Debian 13

Według stanu na sierpień 2026 r. aktualne połączenie to Proxmox Backup Server 4 oraz Debian 13 o nazwie kodowej trixie. Starsze poradniki łączą PBS 2 z Debian 11, a nazwa kodowa jest częścią definicji repozytorium, więc skopiowanie starej nazwy pakietu spowoduje błąd apt o braku pliku release. Należy rozpocząć od czystego obrazu Debian 13. Wszystkie poniższe polecenia należy wykonać jako root lub z użyciem sudo zgodnie z zapisem.

sudo apt update && sudo apt install -y wget
sudo wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

Suma kontrolna musi wynosić 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45. Jeśli jest inna, należy przerwać proces. Błędny klucz oznacza próbę instalacji pakietów podpisanych przez niezweryfikowane źródło.

Należy utworzyć plik /etc/apt/sources.list.d/pbs.sources z repozytorium no-subscription, które jest właściwe dla serwera bez wykupionego wsparcia technicznego:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update
sudo apt install -y proxmox-backup-server

Interfejs webowy odpowiada na porcie HTTPS 8007. Należy zalogować się jako root@pam przy użyciu systemowego hasła root, ponieważ PBS uwierzytelnia tego użytkownika za pomocą PAM (pluggable authentication modules), czyli tych samych kont, których używa system operacyjny. Certyfikat jest podpisany samodzielnie, o czym poinformuje przeglądarka. Odcisk palca (fingerprint) tego certyfikatu jest wartością, którą później przypisuje się w Proxmox VE, więc ostrzeżenie jest oczekiwanym zachowaniem, a nie błędem wymagającym naprawy.

Port 8007 to formularz logowania dostępny w publicznym Internecie, dlatego nie należy pozostawiać go otwartego dla wszystkich. Jeden plik nftables pozwala na jego zabezpieczenie. Zapisanie /etc/nftables.conf czyści bieżący zestaw reguł, więc należy pominąć ten krok, jeśli firewall na tej maszynie jest zarządzany przez inne narzędzie.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    ip saddr 203.0.113.7 tcp dport 8007 accept
  }
}

Należy zastosować reguły za pomocą sudo systemctl enable --now nftables i utrzymywać otwartą drugą sesję SSH podczas wprowadzania zmian: policy drop oraz jeden błąd w regule SSH spowoduje utratę dostępu do serwera. Należy zastąpić 203.0.113.7 adresem, z którego łączy się klaster. Jeśli adres jest dynamiczny, należy rozszerzyć regułę o zakres dostawcy lub zakończyć połączenie w tunelu. Należy pamiętać, że większość paneli VPS posiada dodatkowy firewall sieciowy przed maszyną, który również musi zezwalać na ruch na tym porcie.

Umieszczenie magazynu danych na oddzielnym wolumenie

Magazyn danych nie może znajdować się w głównym systemie plików. Gdy magazyn zapełni współdzielony główny system plików, kopia zapasowa kończy się niepowodzeniem, podobnie jak wszystkie inne usługi na serwerze, w tym logowanie niezbędne do ustalenia przyczyny awarii. Należy podłączyć wolumen blokowy, sformatować go, zamontować, a dopiero potem utworzyć magazyn danych w punkcie montowania.

lsblk
sudo mkfs.ext4 -L pbsstore /dev/vdb
sudo mkdir -p /mnt/datastore/store1

Nazwę urządzenia należy pobrać z lsblk. W większości obrazów KVM jest to /dev/vdb, a w innych /dev/sdb, dlatego nigdy nie należy zakładać nazwy z góry. Należy dodać punkt montowania do /etc/fstab za pomocą etykiety, aby zmiana nazwy urządzenia po restarcie nie spowodowała wskazania magazynu danych na niewłaściwy dysk:

LABEL=pbsstore  /mnt/datastore/store1  ext4  defaults,relatime  0  2

sudo systemctl daemon-reload
sudo mount -a
findmnt -no SOURCE,TARGET,OPTIONS /mnt/datastore/store1

findmnt powinno wyświetlić urządzenie, ścieżkę oraz opcje, w tym rw,relatime. W tej jednej linii ukryte są dwa potencjalne błędy. Jeśli punkt montowania nie istnieje, a magazyn danych zostanie utworzony mimo to, PBS zapisze dane w głównym systemie plików pod punktem montowania. Kolejne poprawne zamontowanie wolumenu ukryje te dane bez ich usuwania: magazyn danych będzie wyglądał na pusty, a główny system plików pozostanie zapełniony. Jeśli opcje zawierają noatime, PBS odmówi pracy, ponieważ wykonuje kontrolę czasu dostępu podczas tworzenia magazynu danych oraz przy każdym procesie usuwania nieużywanych danych (garbage collection).

sudo proxmox-backup-manager datastore create store1 /mnt/datastore/store1
sudo proxmox-backup-manager datastore list

Powoduje to utworzenie katalogu .chunks zawierającego 65536 podkatalogów, nazwanych od 0000 do ffff. Magazyn danych składa się z setek tysięcy małych plików, a nie z kilku dużych. Wynikają z tego dwie kwestie. Kopiowanie magazynu danych za pomocą standardowych narzędzi operujących na plikach jest zbyt wolne, aby było użyteczne. Ponadto migawka wolumenu wykonana przez dostawcę w trakcie trwania kopii zapasowych nie stanowi spójnej kopii danych, co jest powodem, dla którego migawki nie zastępują kopii zapasowych w żadnym innym przypadku.

Przestrzenie nazw zapobiegają konfliktom między hostami

Magazyn danych jest domyślnie płaski. Kopie zapasowe nazywają się vm/100, ct/101 oraz host/<name>. Dwa klastry, z których każdy posiada gościa o identyfikatorze 100, zapisują dane do tej samej grupy, ich migawki przeplatają się, a reguła retencji napisana dla jednego z nich uwzględnia migawki drugiego. Przestrzenie nazw nadają każdemu źródłu własne drzewo wewnątrz jednego magazynu danych.

Utwórz je na hoście PBS. Argument --repository ma postać [[auth-id@]server[:port]:]datastore, więc lokalna przestrzeń nazw przyjmuje postać root@pam@localhost:store1, a polecenie wymaga podania hasła użytkownika root.

sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-home
sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-office
sudo proxmox-backup-client namespace list --repository 'root@pam@localhost:store1'

Deduplikacja pozostaje niezależna od tego podziału. Fragmenty danych (chunks) są współdzielone w całym magazynie danych, więc dziesięciu gości z systemem Debian rozmieszczonych w trzech przestrzeniach nazw nadal przechowuje tylko jedną kopię systemu bazowego. Jest to argument przemawiający za jednym magazynem danych z przestrzeniami nazw zamiast jednego magazynu danych na hosta: oddzielne magazyny danych oznaczają oddzielne pule fragmentów, a oddzielne pule fragmentów oznaczają wielokrotne płacenie za tę samą instalację systemu Debian.

Przypisz każdemu źródłu własne konto, ograniczone do jego własnej przestrzeni nazw. Token API (interfejsu programowania aplikacji) to poświadczenie przypisane do użytkownika, które posiada własne uprawnienia, co jest pożądane w przypadku maszyny, która może zostać skradziona.

sudo proxmox-backup-manager user create backup@pbs --email you@example.com
sudo proxmox-backup-manager user generate-token backup@pbs pve-home
sudo proxmox-backup-manager acl update /datastore/store1/pve-home DatastoreBackup --auth-id 'backup@pbs!pve-home'

Polecenie generowania tokena wyświetla sekret tylko raz:

Result: {
  "tokenid": "backup@pbs!pve-home",
  "value": "d63e505a-e3ec-449a-9bc7-1da610d4ccde"
}

Skopiuj go teraz, ponieważ PBS nie przechowuje jego kopii, której mógłby użyć ponownie. Przyjrzyj się dwukrotnie poleceniu kontroli dostępu. Wskazuje ono token, backup@pbs!pve-home, a nie użytkownika, ponieważ uprawnienia tokena są obliczane wyłącznie na podstawie wpisów wskazujących bezpośrednio na ten token. Wpis dotyczący samego backup@pbs pozostawia token bez żadnego dostępu, a pierwsza kopia zapasowa kończy się niepowodzeniem z powodu braku uprawnień, a nie z przyczyn widocznych w sieci. Ścieżka ma równie duże znaczenie: token ograniczony do /datastore/store1/pve-home nie może odczytać ani usunąć niczego w przestrzeni nazw office, dzięki czemu jeden przejęty klaster nie może zniszczyć historii innego oddziału.

Dodawanie VPS jako pamięci masowej kopii zapasowych w Proxmox VE

Najpierw odczytaj odcisk palca certyfikatu na hoście PBS.

sudo proxmox-backup-manager cert info | grep Fingerprint

Następnie, na dowolnym węźle klastra:

sudo pvesm add pbs pbs-offsite --server pbs.example.com --datastore store1
sudo pvesm set pbs-offsite --username 'backup@pbs!pve-home' --password
sudo pvesm set pbs-offsite --fingerprint 'FINGERPRINT_FROM_CERT_INFO'
sudo pvesm set pbs-offsite --namespace pve-home
sudo pvesm set pbs-offsite --prune-backups keep-all=1

Wklej wartość cert info wyświetloną w miejsce symbolu zastępczego w trzeciej linii. Przekazanie --password bez wartości sprawia, że pvesm wyświetli monit o jej podanie, dzięki czemu sekret tokena nie pozostanie w historii powłoki. Jest on przechowywany w /etc/pve/priv/storage/pbs-offsite.pw, a sama definicja pamięci masowej trafia do /etc/pve/storage.cfg, co jest replikowane do każdego węzła w klastrze, więc konfigurację wykonuje się tylko raz dla całego klastra.

--prune-backups keep-all=1 instruuje Proxmox VE, aby niczego nie usuwał. Retencja zależy od strony PBS i została omówiona poniżej z powodu, który warto jasno wyartykułować: token nie potrzebuje wówczas uprawnień do usuwania, więc klaster zaszyfrowany przez ransomware nie może sięgnąć do zewnętrznej historii kopii, która ma go uratować.

sudo pvesm status --storage pbs-offsite
sudo vzdump 100 --storage pbs-offsite --mode snapshot

pvesm status wyświetla active w kolumnie statusu, wraz z całkowitym i zajętym miejscem w magazynie danych. inactive oznacza, że węzeł nie mógł nawiązać sesji TLS (transport layer security) do portu 8007, co wskazuje na problem z firewallem lub odciskiem palca, a nie z danymi uwierzytelniającymi.

Pierwsza kopia zapasowa przesyła wszystkie dane, więc wykonaj obliczenia przed jej uruchomieniem. 200 GB to 1600 gigabitów, a łącze wysyłające 100 Mbit przesyła 0,1 gigabita na sekundę, więc czas minimalny to około cztery i pół godziny, a w rzeczywistości będzie dłuższy. Uruchom proces, gdy nie potrzebujesz pełnej przepustowości łącza. Każde kolejne uruchomienie przesyła tylko nowe fragmenty danych.

Szyfrowanie po stronie klienta i lokalizacja klucza

VPS to komputer, którego nie jesteś właścicielem. Szyfruj dane po stronie klienta, aby magazyn danych przechowywał fragmenty, których dostawca nie może odczytać.

sudo pvesm set pbs-offsite --encryption-key autogen

Operacja ta zapisuje nowy klucz w /etc/pve/priv/storage/pbs-offsite.enc, dostępny wyłącznie dla użytkownika root i replikowany wraz z resztą /etc/pve. Od następnej kopii zapasowej klient szyfruje każdy fragment przed wysłaniem. Serwer nadal może wyświetlić listę migawek i ich rozmiary, ale nie jest w stanie odczytać ich zawartości.

Teraz część, która sprawia, że jest to kopia zapasowa, a nie zagrożenie. Wygenerowany klucz nie posiada hasła i istnieje tylko w klastrze, który chroni. Jeśli klaster zostanie skradziony lub zaszyfrowany przez osoby trzecie, VPS przechowuje dane, których nikt nie może otworzyć. Skopiuj klucz poza klaster w dniu jego utworzenia.

sudo cp /etc/pve/priv/storage/pbs-offsite.enc /root/pbs-offsite.enc
sudo proxmox-backup-client key paperkey /root/pbs-offsite.enc

key paperkey wyświetla klucz w formie dokumentu przeznaczonego do wydrukowania na papierze i przechowywania w innym miejscu. Traktuj sam plik jako poufny, ponieważ każdy, kto go posiada, może odszyfrować każdą wykonaną za jego pomocą kopię zapasową. W przypadku większych wdrożeń, PBS obsługuje również klucz główny, czyli parę kluczy RSA (Rivest Shamir Adleman) utworzoną za pomocą proxmox-backup-client key create-master-key, gdzie każda kopia zapasowa przechowuje własny klucz szyfrujący zaszyfrowany kluczem publicznym, podczas gdy klucz prywatny pozostaje offline w celu odzyskiwania danych.

Warto poznać jedną konsekwencję tego projektu przed rozpoczęciem pracy, a nie po fakcie. W przypadku zaszyfrowanych kopii zapasowych skrót fragmentu jest obliczany na podstawie zawartości tekstu jawnego połączonego z kluczem szyfrującym, więc dwa identyczne fragmenty zaszyfrowane różnymi kluczami generują różne skróty i nigdy nie podlegają deduplikacji względem siebie. Zmiana klucza oznacza, że kolejna kopia zapasowa przesyła wszystko ponownie, a stare fragmenty pozostają w pamięci do momentu usunięcia migawek i przeprowadzenia czyszczenia (garbage collection). Decyzję o szyfrowaniu podejmij przed pierwszym przesłaniem danych.

Usuwanie oznaczeń i odzyskiwanie miejsca przez garbage collection

To jest sekcja, która bywa pomijana, a to ona odpowiada za zapełnianie wolumenu. Pruning (przycinanie) migawki usuwa jej metadane: manifest, indeksy, dziennik oraz notatki. Nie usuwa jednak żadnych fragmentów danych (chunks). Fragmenty są współdzielone między migawkami, więc żaden proces nie może stwierdzić, że fragment jest nieużywany, dopóki nie zostaną odczytane wszystkie pozostałe indeksy. Zadaniem, które to wykonuje, jest garbage collection. Magazyn danych (datastore) z harmonogramem prune, ale bez harmonogramu garbage collection, będzie stale zwiększał swoje rozmiary.

Należy skonfigurować oba zadania. Najpierw retencję, jedno zadanie na przestrzeń nazw (namespace):

sudo proxmox-backup-manager prune-job create home-daily --store store1 --ns pve-home --schedule '02:30' --keep-daily 14 --keep-weekly 8 --keep-monthly 6
sudo proxmox-backup-manager prune-job list

Następnie harmonogram zbierania danych w magazynie, kilka godzin po zadaniu prune i poza oknem czasowym kopii zapasowych:

sudo proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'
sudo proxmox-backup-manager datastore show store1

Warto raz samodzielnie zweryfikować ten podział na hoście PBS:

df -h /mnt/datastore/store1
sudo proxmox-backup-manager garbage-collection start store1
df -h /mnt/datastore/store1

Uruchom zadanie prune, a następnie df – wartość użytego miejsca nie ulegnie zmianie. Uruchom garbage collection, a następnie ponownie df – wtedy wartość się zmieni.

Garbage collection działa w dwóch fazach. Faza pierwsza przeszukuje każdy indeks w magazynie danych i aktualizuje czas dostępu każdego fragmentu, do którego odwołują się te indeksy. Faza druga usuwa fragmenty, których czas dostępu jest starszy niż wyznaczony limit. Limit ten wynosi 24 godziny i 5 minut przed rozpoczęciem uruchomienia lub moment rozpoczęcia najstarszej kopii zapasowej, która jest w trakcie zapisu – zależnie od tego, co nastąpiło wcześniej. Ten margines istnieje, ponieważ systemy Linux domyślnie montują systemy plików z flagą relatime, co powoduje aktualizację czasu dostępu mniej więcej raz na dobę, a nie przy każdym odczycie. Dlatego fragment zapisany godzinę temu nie zostanie usunięty, nawet jeśli nic się do niego nie odwołuje, a miejsce zwolnione przez prune pojawi się dopiero po pierwszym uruchomieniu garbage collection, które nastąpi ponad dobę po ostatnim użyciu fragmentu. Magazyn danych, który wygląda, jakby nie odzyskał miejsca, często znajduje się po prostu wewnątrz tego okna czasowego.

Na małym VPS jest to najbardziej obciążające zadanie, ponieważ wykonuje operację stat na każdym pliku fragmentu na wolumenie. Dziennik zadania kończy się podsumowaniem tego, co zostało usunięte, a co nadal oczekuje na usunięcie ze względu na okres karencji. Jeśli wiele elementów oczekuje, uruchom zadanie ponownie następnego dnia. PBS udostępnia gc-atime-safety-check oraz gc-atime-cutoff jako opcje dostrajania magazynu danych i obie powinny pozostać w ustawieniach domyślnych. Istnieją one z myślą o pamięciach masowych, które nie potrafią rejestrować czasu dostępu, a wyłączenie zabezpieczeń na systemie plików zamontowanym z noatime prowadzi do utraty fragmentów, do których nadal odwołują się istniejące migawki.

Weryfikacja potwierdza czytelność fragmentów danych

Kopia zapasowa, która została poprawnie przesłana, po roku może stać się nieczytelna. Weryfikacja polega na ponownym odczycie fragmentów danych (chunks) i porównaniu ich z sumami kontrolnymi zapisanymi w indeksie. Dzięki temu uszkodzenia wykrywane są zgodnie z harmonogramem, a nie dopiero w momencie przywracania danych.

sudo proxmox-backup-manager verify store1 --read-threads 1 --verify-threads 4

Na małych serwerach VPS należy utrzymywać niską liczbę wątków. Weryfikacja jest ograniczona wydajnością dysku oraz procesora i w przeciwnym razie będzie konkurować o zasoby z innymi zadaniami wykonywanymi przez serwer. Harmonogram zadań należy skonfigurować w interfejsie WWW, w zakładce Verify Jobs danego magazynu danych (datastore). Cotygodniowe zadanie, które pomija już zweryfikowane migawki i sprawdza ponownie dane starsze niż 30 dni, pozwala na pokrycie całego magazynu bez powielania pracy.

Migawka, która nie przejdzie weryfikacji, jest oznaczana w widoku magazynu danych jako nieudana. Nie należy ignorować takiego stanu. Fragmenty danych są współdzielone, więc pojedynczy uszkodzony fragment z obrazu bazowego zazwyczaj powoduje błąd weryfikacji każdej migawki, która się do niego odwołuje. Naprawa polega na usunięciu nieudanych migawek i wykonaniu nowej kopii zapasowej, co spowoduje ponowne przesłanie brakujących fragmentów. Jeśli błędy pojawiają się regularnie, należy podejrzewać nośnik danych pod magazynem i skonfigurować monitorowanie stanu dysku na VPS, aby system ostrzegł o awarii przed zadaniem weryfikacyjnym.

Przetestuj przywracanie, a następnie przetestuj je poza klastrem

Kopia zapasowa jest użyteczna dopiero po zweryfikowaniu procesu jej przywracania. Należy wykonać dwa testy, z których każdy sprawdza inne aspekty.

Cały gość, wewnątrz klastra:

sudo pvesm list pbs-offsite
sudo qmrestore 'pbs-offsite:backup/vm/100/2026-08-14T22:00:00Z' 999 --storage local-lvm

Pierwsza kolumna pvesm list to identyfikator wolumenu, którego częścią jest znacznik czasu, dlatego należy skopiować własną wartość zamiast przepisywać przykład. Przywróć dane do nieużywanego identyfikatora gościa i na inny magazyn, a następnie uruchom go z odłączonym interfejsem sieciowym. Nigdy nie przywracaj danych na działającego gościa w celu sprawdzenia kopii, ponieważ niepowodzenie procesu w połowie spowoduje utratę również działającej kopii.

Drugi test jest pomijany przez większość administratorów. Załóż, że budynek z klastrem przestał istnieć i wykonaj przywracanie z maszyny, która nigdy nie była jego częścią. Na dowolnym systemie Debian 13 dodaj repozytorium typu client-only jako /etc/apt/sources.list.d/pbs-client.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pbs-client
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-client
export PBS_REPOSITORY='backup@pbs!pve-home@pbs.example.com:store1'
export PBS_PASSWORD='<the token secret>'
export PBS_FINGERPRINT='<the value cert info printed>'
proxmox-backup-client snapshot list --ns pve-home
proxmox-backup-client snapshot files vm/100/2026-08-14T22:00:00Z --ns pve-home
proxmox-backup-client restore vm/100/2026-08-14T22:00:00Z 'ARCHIVE_NAME_FROM_THAT_LIST' ./restore-test --keyfile ./pbs-offsite.enc --ns pve-home

Wypełnij trzy ujęte w cudzysłów symbole zastępcze własnymi wartościami, a nazwę archiwum w ostatniej linii pobierz z danych wyświetlonych przez snapshot files. Potwierdza to fakt, którego pierwszy test nie jest w stanie sprawdzić: że posiadany plik klucza deszyfruje rzeczywiste dane oraz że możliwe jest obsłużenie klienta z maszyny, która nigdy nie posiadała konfiguracji klastra. Zapisz cztery wymagane wartości: ciąg repozytorium, sekret tokena, odcisk palca (fingerprint) oraz plik klucza, a następnie przechowuj je razem w miejscu wskazanym przez plan awaryjny.

Wpływ deduplikacji na koszty przechowywania danych

Deduplikacja jest realna i działa w obrębie całego magazynu danych (datastore). Dziesięć systemów gości Debian współdzieli jedną kopię systemu podstawowego, więc przechowywanie drugiego identycznego systemu gościa prawie nic nie kosztuje. Oszczędza to również przepustowość wysyłania, ponieważ klient przesyła sumę kontrolną zamiast danych dla każdego bloku, który serwer już posiada.

Warto jasno określić, czego deduplikacja nie robi.

• Nie zmniejsza danych, które ulegają zmianom. Baza danych, która każdej nocy nadpisuje duże fragmenty swoich plików, generuje nowe bloki, a retencja je zwielokrotnia.
• Nie działa w poprzek granic kluczy szyfrujących, co opisano powyżej.
• Nie działa w poprzek granic magazynu danych, co stanowi główny argument za stosowaniem przestrzeni nazw (namespaces).
• Nie zapobiega zapełnieniu wolumenu. Gdy magazyn danych jest pełny, kopie zapasowe kończą się niepowodzeniem, a jedynym rozwiązaniem jest zwiększenie wolumenu lub skrócenie okresu retencji.

Nie należy nakładać kolejnej warstwy deduplikacji poniżej. Bloki docierają już zdeduplikowane i skompresowane przez klienta, więc deduplikacja ZFS pod magazynem danych zużywa pamięć RAM na poszukiwanie dopasowań, które zostały usunięte przed zapisem. Właściwym wyborem dla wolumenu jest tutaj standardowy system plików ext4 lub xfs.

Interfejs webowy raportuje współczynnik deduplikacji dla magazynu danych. Liczba ta opisuje posiadane systemy gości i jest jedyną wartością, na której warto opierać planowanie, ponieważ publikowane wskaźniki opisują dane innych użytkowników. Jeśli wymagane są również kopie zapasowe na poziomie plików dla maszyn, które nie są gośćmi Proxmox, należy uruchomić je równolegle na tym samym VPS: PBS jest celem zorientowanym na hypervisor dla całych maszyn wirtualnych, podczas gdy restic i BorgBackup wskazują na katalogi, a kopie zapasowe restic na VPS sprawdzają się w przypadku laptopów i samodzielnych serwerów, do których obsługi PBS nie został zaprojektowany.

Tryby awarii i ich objawy

Magazyn danych jest oznaczony jako nieaktywny. pvesm status --storage pbs-offsite wyświetla inactive, gdy węzeł nie może nawiązać sesji TLS z portem 8007. Należy sprawdzić zaporę sieciową na VPS, następnie zewnętrzną zaporę sieciową dostawcy, a na końcu odcisk palca certyfikatu. Odcisk palca, który nie pasuje do certyfikatu, powoduje takie same objawy jak zablokowany port; zmienia się on przy każdej wymianie certyfikatu.

Pierwsza kopia zapasowa kończy się błędem uprawnień. Wpis kontroli dostępu musi wskazywać token, a nie użytkownika, oraz obejmować przestrzeń nazw, na którą wskazuje magazyn danych. Należy to zweryfikować w zakładce uprawnień magazynu danych w interfejsie WWW przed podjęciem dalszej diagnostyki.

Odsiewanie danych (garbage collection) nie uruchamia się. Kontrola czasu dostępu zakończyła się niepowodzeniem, co prawie zawsze oznacza, że system plików magazynu danych jest zamontowany z opcją noatime. Należy uruchomić findmnt -no OPTIONS /mnt/datastore/store1 w celu weryfikacji, poprawić opcję w /etc/fstab i ponownie zamontować zasób. Nie należy wyłączać tej kontroli w celu obejścia problemu.

Magazyn danych stale zwiększa zajętość. Zadania czyszczenia (prune) są wykonywane, ale miejsce nie jest odzyskiwane. Przyczyną jest brak harmonogramu dla garbage collection lub fakt, że każde zadanie uruchamia się wewnątrz 24-godzinnego okna karencji, ponieważ startuje bezpośrednio po kopiach zapasowych. Harmonogram należy sprawdzić za pomocą proxmox-backup-manager datastore show store1.

Kopia zapasowa, która wcześniej była szybka, trwa teraz godziny. Maszyna wirtualna, która została zatrzymana, zmigrowana lub przywrócona, traci swoją mapę zmian (dirty bitmap), więc kolejne zadanie odczytuje cały dysk po stronie klastra, mimo że przesyła niewiele danych. Dziennik zadań wykazuje długi czas trwania przy niewielkiej ilości przesłanych danych, a kolejne uruchomienie będzie już szybkie. Jeśli każde zadanie na VPS działa wolno, przyczyna zazwyczaj leży poza magazynem danych, a pierwszym parametrem do sprawdzenia jest czas kradzieży procesora (CPU steal time) od sąsiadującego użytkownika.

FAQ

Dlaczego rozmiar datastore w Proxmox Backup Server rośnie mimo uruchomienia zadania prune?

Ponieważ operacja prune usuwa jedynie metadane migawki: manifest, indeksy, dziennik oraz notatki. Fragmenty danych (chunks) pozostają na dysku do momentu, aż garbage collection usunie te, do których nie odwołuje się żaden indeks. Należy skonfigurować harmonogram dla datastore za pomocą proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' i zweryfikować działanie, uruchamiając df -h w ścieżce datastore przed i po proxmox-backup-manager garbage-collection start store1. Należy uwzględnić co najmniej jednodniowe opóźnienie, ponieważ druga faza usuwa tylko te fragmenty, których czas dostępu jest starszy niż 24 godziny i 5 minut.

Ile miejsca na dysku potrzebuje VPS z Proxmox Backup Server?

Należy zsumować faktyczne zajęcie miejsca przez każdego gościa, a następnie dodać dzienną zmianę danych pomnożoną przez liczbę dni przechowywania kopii. Wynik ten stanowi górną granicę, ponieważ kompresja i deduplikacja działają na korzyść użytkownika. Warto dodać około 20% zapasu na indeksy i przestrzeń roboczą, a następnie zaokrąglić wynik do dostępnego rozmiaru wolumenu. Po dwóch tygodniach należy ponownie sprawdzić faktyczne zużycie w widoku datastore, ponieważ szacunki wykonane przed pierwszym backupem zawsze obarczone są błędem.

Gdzie przechowywać klucz szyfrujący backup?

W dowolnym miejscu poza klastrem, który jest chroniony. Proxmox VE przechowuje go w /etc/pve/priv/storage/<storage>.enc, co jest replikowane do każdego węzła, więc w przypadku utraty klastra klucz również przepadnie. Należy skopiować go pierwszego dnia, wydrukować za pomocą proxmox-backup-client key paperkey i przechowywać kopię w innym budynku. Należy również pamiętać, że klucz jest częścią skrótu fragmentu (chunk digest), więc jego późniejsza wymiana spowoduje konieczność ponownego przesłania wszystkich danych podczas kolejnego backupu.

Czy potrzebuję jednego datastore na hosta Proxmox, czy przestrzeni nazw (namespaces)?

Zaleca się jeden datastore i jedną przestrzeń nazw na hosta źródłowego lub klaster. Deduplikacja działa w obrębie jednego datastore, a nie między nimi, więc podział według hostów powoduje wielokrotne przechowywanie tych samych obrazów bazowych. Przestrzenie nazw pozwalają odseparować grupy backupów, dzięki czemu dwa hosty posiadające gościa o tym samym ID 100 nie powodują kolizji, a ścieżka kontroli dostępu w formacie /datastore/store1/pve-home ogranicza token API każdego hosta do jego własnej przestrzeni nazw.

Czy mały VPS poradzi sobie jako serwer backupu Proxmox?

Zazwyczaj tak, w przypadku środowisk domowych, ponieważ procesy dzielenia na fragmenty (chunking) i haszowania odbywają się na węźle Proxmox VE, a nie na serwerze backupu. VPS zajmuje się zapisem fragmentów oraz dwoma obciążającymi zadaniami: garbage collection i weryfikacją. Należy przydzielić 4 GB pamięci RAM i ograniczyć liczbę wątków weryfikacji. Oba zadania należy zaplanować poza oknem backupu, a jeśli mimo to trwają znacznie dłużej, niż wynikałoby to z wydajności dysku, przed zakupem większego planu należy sprawdzić parametr steal time.