Proxmox Backup Server: czym jest, czym nie jest i jak odzyskać VM

Stan dokumentacji: 5 października 2026 r. Nazwy hostów, datastore, VMID, adresy i pojemności w przykładach są zanonimizowane. Polecenia oznaczone jako wykonywane na PBS uruchamiamy jako root na serwerze PBS, a pozostałe jako root na hoście Proxmox VE (PVE).

Czym jest Proxmox Backup Server, a czym nie jest

Proxmox Backup Server (PBS) jest serwerem kopii zapasowych. Przyjmuje backupy od klientów, przechowuje je w datastore, udostępnia je do odtworzenia oraz wykonuje zadania retencji, weryfikacji i synchronizacji do drugiego PBS. PVE ma z PBS natywną integrację: po dodaniu datastore PBS jako storage typu pbs backup VM i kontenera uruchamiamy tym samym mechanizmem vzdump, którego używa PVE dla innych storage backupowych.

Datastore jest nazwaną lokalizacją, w której PBS trzyma kopie. W typowej instalacji jest to katalog na zwykłym systemie plików, na przykład ext4, XFS lub ZFS; PBS obsługuje również backend S3 z lokalnym cache, ale ten artykuł opisuje standardowy wariant lokalnego filesystemu. Datastore nie jest dyskiem uruchomionej VM. PBS zapisuje w nim metadane snapshotów i chunki, czyli fragmenty danych rozpoznawane po sumie SHA-256. Gdy kolejny backup zawiera fragment już obecny w datastore, PBS nie zapisuje drugiej identycznej kopii. To deduplikacja.

Co robi PBS	Czego PBS nie robi
Przechowuje wersje backupów VM, kontenerów i danych hostów.	Nie uruchamia VM i nie jest hypervisorem. Od tego jest PVE albo inny host KVM.
Zmniejsza transfer i zajętość przez deduplikację oraz kompresję.	Nie jest storage typu ZFS, Ceph RBD lub NFS dla pracujących dysków VM. W PVE backend `pbs` obsługuje backupy, nie obrazy dysków.
Weryfikuje zapisane dane i może synchronizować snapshoty do drugiego PBS.	Nie daje automatycznego failoveru ani replikacji działającej VM w czasie rzeczywistym.
Pomaga ograniczyć skutki błędu w gościu, przypadkowego usunięcia danych lub awarii dysku źródłowego.	Nie czyni jednej kopii backupu odpornej na pożar, utratę całego hosta ani administratora z prawem skasowania źródła i PBS.

Sam napis TASK OK po backupie potwierdza wykonanie zadania, ale nie udowadnia jeszcze, że system i aplikacja po odtworzeniu wystartują. Verify sprawdza dane względem zapisanych sum kontrolnych. Test restore sprawdza inną rzecz: czy wybór snapshotu, storage docelowy, konfiguracja VM, klucze szyfrowania i procedura operacyjna pozwalają przywrócić usługę.

TLS szyfruje połączenie między PVE a PBS, ale nie oznacza automatycznie szyfrowania backupu na dysku. Szyfrowanie kopii w PBS jest opcjonalne i odbywa się po stronie klienta. Gdy jest włączone, do odczytu potrzebny jest niezależnie przechowywany klucz odzyskiwania lub prywatny klucz główny; bez niego nawet administrator PBS nie odzyska danych. Bez tego szyfrowania administrator PBS z prawem odczytu datastore może czytać zawartość backupu.

Jeżeli backupujemy zwykły host Linux, a nie VM lub kontener PVE, używamy na nim proxmox-backup-client do archiwów plikowych. PBS nie tworzy sam kopii całego hosta tylko dlatego, że agent lub panel jest dostępny w sieci.

Jak backup VM trafia do PBS w realnym małym środowisku

Rozważmy zanonimizowany, typowy układ: pve-lab-01 uruchamia VM crm-01 o VMID 901. Osobna VM pbs-01.example.test udostępnia datastore pve-lab-backup przez HTTPS na porcie 8007. Po dodaniu go do PVE storage nazywa się pbs-lab.

crm-01 (VM 901)
        │ zapis na dysku VM
        ▼
pve-lab-01 ── backup przez TLS ──► pbs-01.example.test:8007
                                        │
                                        ▼
                              datastore pve-lab-backup
                              snapshot + indeksy + chunki

Podczas backupu w trybie snapshot PVE odczytuje konfigurację i dyski VM, a następnie przesyła dane do PBS. PBS przypisuje kopię do grupy backupów VM, na przykład vm/901. W tej grupie kolejne snapshoty mają własny czas i metadane, lecz mogą współdzielić te same chunki z wcześniejszymi kopiami.

Tryb snapshot ogranicza przestój, lecz sam nie gwarantuje spójności aplikacji ani bazy danych. QEMU Guest Agent z działającym fsfreeze/thaw może uporządkować stan filesystemu, ale nie kończy transakcji bazy za aplikację. Dla krytycznej bazy ustalamy jej własny mechanizm backupu albo procedurę wyciszenia przed kopią. Przywracamy wtedy snapshot, o którym wiemy, że był wykonany po tej procedurze.

W praktyce ma to znaczenie po błędzie aplikacji. Załóżmy, że błędna migracja bazy danych w crm-01 usuwa ważne rekordy. Nie zatrzymujemy od razu działającej VM ani nie nadpisujemy jej ostatnim backupem. Najpierw odtwarzamy wybrany snapshot jako nową VM, na przykład 1901, w odizolowanej sieci. Dopiero gdy potwierdzimy wersję danych i sposób powrotu, planujemy zmianę produkcyjnej VM.

Czy PBS jako VM na tym samym fizycznym hoście jest backupem?

Takie PBS ma wartość laboratoryjną i operacyjną, ale trzeba uczciwie nazwać jego granicę. Jeśli VM PBS i chronione VM działają na tym samym PVE, a datastore PBS leży na tej samej lokalnej puli dyskowej, backup może pomóc po błędzie ograniczonym do gościa: usunięciu pliku, nieudanej aktualizacji, błędnej konfiguracji albo przypadkowym skasowaniu danych wewnątrz jednej VM.

W tym wariancie utrata hosta, jego puli dyskowej, zasilania, kradzież urządzenia albo zdarzenie usuwające jednocześnie VM źródłową i VM PBS może usunąć także jedyną kopię. To wspólna domena awarii, a nie wada PBS. Sam fakt, że PBS jest VM na tym samym PVE, nie przesądza jednak o utracie danych: jeżeli jego datastore i kopie kluczy leżą na niezależnym storage, dane mogą przetrwać awarię PVE. Nadal trzeba wtedy odtworzyć PBS lub zapewnić dostęp do datastore z innej maszyny.

Najprostszą dodatkową domenę awarii daje osobny fizyczny serwer lub drugi PBS w innej lokalizacji, do którego synchronizujemy kopie.

W laboratorium mamy VM PBS na hoście fizycznym. Ten fakt sam w sobie nie oznacza, że laboratorium ma gotowy backup. Działająca usługa i panel HTTPS są dopiero początkiem. Żeby mówić o sprawdzonej ochronie, muszą istnieć:

zamontowany datastore z wystarczającą pojemnością,
oddzielna tożsamość lub token o minimalnych uprawnieniach do backupu,
storage PBS aktywny w PVE,
co najmniej jeden zakończony backup testowej VM,
zaplanowane prune, garbage collection (GC) i verify,
udokumentowany, wykonany test odtworzenia.

Jeżeli jeden z tych warunków nie jest spełniony, nie nazywamy układu gotowym backupem produkcyjnym.

Jak sprawdzić PBS bez zmiany konfiguracji

Zaczynamy od odczytu aktualnego stanu. Poniższe polecenia wykonujemy jako root na PBS. Nie tworzą datastore, nie uruchamiają GC i nie modyfikują backupów.

systemctl is-active proxmox-backup-proxy
proxmox-backup-manager datastore list
proxmox-backup-manager task list --all --limit 20
proxmox-backup-manager prune-job list
proxmox-backup-manager verify-job list
proxmox-backup-manager garbage-collection list

Usługa proxmox-backup-proxy powinna mieć stan active. Lista datastore pokazuje, czy PBS ma w ogóle miejsce na kopie. Pusta lista oznacza, że panel może działać poprawnie, ale nie ma jeszcze gdzie zapisywać backupów. Pozostałe trzy polecenia pokazują, czy retencja, weryfikacja i GC są skonfigurowane oraz co wydarzyło się w ostatnich zadaniach.

Gdy znamy ścieżkę datastore, sprawdzamy również warstwę pod spodem. W tym przykładzie /srv/pbs-data trzeba zastąpić rzeczywistą ścieżką z proxmox-backup-manager datastore show.

STORE_PATH=/srv/pbs-data
proxmox-backup-manager datastore show pve-lab-backup
findmnt -T "$STORE_PATH"
df -hT "$STORE_PATH"
df -ih "$STORE_PATH"

findmnt odpowiada, z jakiego filesystemu korzysta katalog. df -hT pokazuje wolne bloki, a df -ih wolne inode. To rozróżnienie jest ważne: komunikat ENOSPC nie zawsze oznacza brak gigabajtów w datastore; czasem kończą się inode albo pełny jest inny filesystem, na przykład partycja z logami zadań.

Jak dodać PBS do PVE i wykonać pierwszy backup testowej VM

Ten przykład zakłada, że datastore pve-lab-backup istnieje już na świadomie przygotowanym i zamontowanym filesystemie. Dalej korzystamy z głównej przestrzeni tego datastore, bez namespace. Na PBS tworzymy osobnego użytkownika technicznego i jego API token wyłącznie dla PVE. Token nie jest zamiennikiem użytkownika: ma własne ACL, a jego skuteczne prawa są przecięciem praw tokena i użytkownika. Rola DatastoreBackup pozwala tworzyć backupy oraz odtwarzać backupy należące do tej tożsamości, ale nie daje bez potrzeby prawa kasowania istniejących kopii.

Poniższy blok wykonujemy tylko raz jako root na PBS. Zmienia on konfigurację użytkowników i ACL. Przed uruchomieniem otwieramy bezpieczne miejsce na sekret: generowanie tokena wyświetli go tylko raz. Nie wklejamy go do historii powłoki, playbooku ani dokumentacji.

PBS_STORE='pve-lab-backup'
PBS_USER='pve-lab@pbs'
PBS_TOKEN_NAME='pve-lab-01'
PBS_TOKEN="${PBS_USER}!${PBS_TOKEN_NAME}"

proxmox-backup-manager user create "$PBS_USER" \
  --comment 'PVE lab backup client'
proxmox-backup-manager acl update \
  "/datastore/$PBS_STORE" DatastoreBackup --auth-id "$PBS_USER"
proxmox-backup-manager user generate-token "$PBS_USER" "$PBS_TOKEN_NAME" \
  --comment 'PVE lab backup client'
proxmox-backup-manager acl update \
  "/datastore/$PBS_STORE" DatastoreBackup --auth-id "$PBS_TOKEN"
proxmox-backup-manager user permissions "$PBS_TOKEN" \
  --path "/datastore/$PBS_STORE"

Ostatnie polecenie powinno pokazać co najmniej Datastore.Backup. Jeżeli użytkownik lub token już istnieje, nie powtarzamy bloku w ciemno: najpierw porównujemy istniejące ACL z planem. Sekret tokena wprowadzimy za chwilę tylko do interaktywnego monitu PVE.

Jeżeli PBS używa własnego certyfikatu, na PBS odczytujemy jego fingerprint. To polecenie jest tylko odczytem.

proxmox-backup-manager cert info | grep -i 'Fingerprint'

Na PVE dodajemy definicję storage wraz z tożsamością tokena i fingerprintem. Wartości w przykładzie są celowo przykładowe: nazwa serwera musi rozwiązywać się z PVE, a token musi istnieć po stronie PBS. Po opcji --password PVE zapyta interaktywnie o sekret tokena wyświetlony w poprzednim kroku.

pvesm add pbs pbs-lab \
  --server pbs-01.example.test \
  --datastore pve-lab-backup \
  --username 'pve-lab@pbs!pve-lab-01' \
  --fingerprint '12:34:56:78:90:ab:cd:ef:12:34:56:78:90:ab:cd:ef:12:34:56:78:90:ab:cd:ef:12:34:56:78:90:ab:cd:ef' \
  --nodes pve-lab-01 \
  --password

pvesm status --storage pbs-lab

PVE zapisze sekret tokena w pliku dostępnym tylko dla root, pod /etc/pve/priv/storage/pbs-lab.pw. Nie wpisujemy go za opcją wprost i nie wklejamy do dokumentacji. W ostatnim poleceniu oczekujemy statusu active oraz informacji o pojemności PBS. Błąd certyfikatu oznacza, że trzeba porównać fingerprint i nazwę hosta, a nie wyłączać weryfikację TLS.

Opcję --nodes pve-lab-01 zastępujemy nazwą własnego węzła, gdy PBS jest osiągalny tylko stamtąd. W klastrze PVE definicja storage jest wspólna; jeżeli backupy i restore mają działać z wielu węzłów, każdy z nich musi mieć poprawną trasę, DNS i dostęp TLS do PBS. Przy zmianie sekretu tokena używamy później pvesm set pbs-lab --password, zamiast wpisywać go do pliku ręcznie.

Pierwszy zapis uruchamiamy wyłącznie dla nieprodukcyjnej VM, w godzinie, gdy jej dodatkowe I/O nie przeszkadza. Poniższy przykład tworzy nowy backup VMID 901; nie jest poleceniem do uruchomienia dla całego klastra.

vzdump 901 --storage pbs-lab --mode snapshot
pvesm list pbs-lab --vmid 901

Pierwsze polecenie zapisuje backup i może chwilowo obciążyć storage VM oraz PBS. Drugi wiersz nie zmienia danych; powinien pokazać identyfikator w rodzaju pbs-lab:backup/vm/901/2026-10-05T01:15:00Z. Ten dokładny identyfikator będzie potrzebny do testu odtworzenia.

Dlaczego prune, garbage collection i verify są trzema różnymi zadaniami

W PBS nie usuwamy starych kopii przez ręczne kasowanie plików z katalogu datastore. Snapshoty współdzielą chunki, więc usunięcie jednego katalogu .chunks albo przypadkowych plików może uszkodzić wiele backupów. Retencję planujemy jako zadanie PBS lub PVE, a dla jednej grupy backupów wskazujemy jedno źródło prawdy o retencji.

Mechanizm	Co robi	Czego nie należy po nim zakładać
Prune	Wybiera snapshoty do zachowania według reguł, na przykład dziennych, tygodniowych i miesięcznych, a pozostałe usuwa z katalogu backupów.	Nie musi natychmiast oddać miejsca na dysku, bo chunki mogą być wspólne z zachowanymi snapshotami.
GC (garbage collection)	Oznacza nieużywane chunki, a po okresie ochronnym usuwa je podczas kolejnego przebiegu GC.	Nie jest lekkim porządkowaniem katalogu ani gwarancją natychmiastowego zwolnienia miejsca. Czyta indeksy i przechodzi po chunk store, więc na HDD może długo obciążać I/O.
Verify	Sprawdza backup względem zapisanych sum kontrolnych.	Nie uruchamia systemu gościa i nie potwierdza, że aplikacja po restore działa poprawnie.
Sync	Kopiuje snapshoty między dwoma PBS, zwykle asynchronicznie.	Nie jest replikacją działającej VM ani natychmiastowym przejęciem usługi po awarii.

Przykładowa retencja 14 kopii dziennych, 8 tygodniowych i 12 miesięcznych może pasować do małej usługi z dobowym Recovery Point Objective (RPO), czyli maksymalną, akceptowalną utratą około doby danych. Nie jest jednak wartością domyślną dla każdego środowiska. Najpierw ustalamy, ile danych można stracić, jak długo trwa restore, jak szybko rosną dane i ile miejsca zostawiamy na GC oraz nagły wzrost backupu.

Verify dla nowych backupów można uruchamiać często, a pełniejsze ponowne sprawdzenie starszych snapshotów przynajmniej okresowo. GC i verify planujemy poza oknem backupowym. Jeżeli datastore jest wolny, jednoczesny backup, verify i GC potrafią stworzyć problem wydajnościowy, choć każda z tych operacji osobno jest poprawna.

Synchronizacja do drugiego PBS ma sens dopiero poza pierwszą domeną awarii. Dla kopii ochronnej nie włączamy bez wyraźnej decyzji opcji remove-vanished: mogłaby skasować na drugim PBS snapshot usunięty wcześniej ze źródła. Domyślnie ta opcja jest wyłączona, co daje drugiej lokalizacji czas na wykrycie przypadkowego albo złośliwego usunięcia.

Jak bezpiecznie przetestować odtworzenie do nowej VM

Test restore wykonujemy na PVE jako root. Nie przywracamy backupu na VMID działającej usługi. Najpierw odczytujemy listę kopii testowej VM i zapisujemy dokładny identyfikator wybranego snapshotu.

pvesm list pbs-lab --vmid 901

BACKUP_ID='pbs-lab:backup/vm/901/2026-10-05T01:15:00Z'
TEST_STORAGE='local-zfs'
qmrestore "$BACKUP_ID" 1901 --storage "$TEST_STORAGE" --unique 1 --start 0

BACKUP_ID zastępujemy identyfikatorem wyświetlonym przez pvesm list. 1901 musi być wolnym VMID, a TEST_STORAGE ma wskazywać storage przeznaczony na test. Opcja --unique 1 nadaje odzyskanej VM nowe adresy MAC, ale nie usuwa jej połączeń sieciowych ani nie zmienia stałej konfiguracji IP wewnątrz systemu gościa. --start 0 zostawia VM wyłączoną po restore.

Przed pierwszym startem sprawdzamy urządzenia odzyskanej VM. Jeżeli nie przygotowaliśmy osobnego, nieroutowanego bridge'a testowego, odłączamy każdy interfejs netN widoczny w wyniku. Poniższy przykład usuwa tylko konfigurację sieci testowej VM 1901; dla dodatkowych wpisów powtarzamy polecenie z ich numerem.

qm config 1901
qm set 1901 --delete net0
qm start 1901

Przed startem sprawdzamy też, czy konfiguracja nie zawiera hostpci albo przekazanego urządzenia USB; takich urządzeń nie podłączamy do testowej kopii. Sukces testu to nie tylko kod zakończenia qmrestore. Potwierdzamy z konsoli start systemu, wersję aplikacji, dostępność oczekiwanych danych i możliwość zalogowania się administracyjnie. Jeżeli VM ma zachować sieć po teście, dodajemy nowy interfejs wyłącznie do przygotowanego bridge'a testowego, nigdy automatycznie do bridge'a produkcyjnego. W przypadku backupu zaszyfrowanego do testu potrzebny jest także zachowany klucz odzyskiwania.

Po udokumentowaniu wyniku usuwamy wyłącznie testową VM, po ponownym sprawdzeniu VMID:

qm status 1901
qm stop 1901
qm destroy 1901 --purge 1

Ostatnie polecenie niszczy VM 1901 i jej dyski. Nie wolno zastępować nim numeru działającej VM. Jeżeli test miał służyć analizie incydentu, zachowujemy VM aż do zakończenia analizy i decyzji o jej usunięciu.

Najczęstsze problemy PBS i pierwszy bezpieczny krok

Poniższe sytuacje powracają w dokumentacji i wątkach społeczności Proxmox. Nie są formalnym rankingiem awarii, lecz dobrym porządkiem pierwszej diagnozy. Zaczynamy od odczytu pełnego błędu i stanu storage, a nie od restartu usług ani kasowania danych.

Objaw	Co sprawdzamy najpierw	Czego nie robimy odruchowo
PVE zgłasza `certificate verify failed` albo storage jest niedostępny.	Na PBS `proxmox-backup-manager cert info`; na PVE `pvesm status --storage pbs-lab`. Porównujemy aktualny fingerprint, nazwę serwera i łańcuch certyfikatu.	Nie wyłączamy kontroli TLS i nie akceptujemy nowego fingerprintu bez ustalenia, dlaczego certyfikat się zmienił.
Usunięto stare backupy, ale datastore nadal jest pełny.	`df -hT`, `df -ih`, listę prune jobów i `proxmox-backup-manager garbage-collection list`. Sprawdzamy, czy GC ma harmonogram i kiedy zakończył się ostatnio.	Nie kasujemy ręcznie `.chunks` i nie oczekujemy, że prune natychmiast zwolni miejsce.
Backup lub restore jest wolny mimo szybkiej sieci.	Log joba, opóźnienia i IOPS dysków, równoległe verify lub GC. Przy ZFS także `zpool iostat -v 1`; na zwykłym storage `iostat -xz 1`.	Nie zakładamy, że 10 GbE eliminuje ograniczenie HDD, RAID, CPU albo wielu małych operacji na chunkach.
Datastore znika po restarcie albo dostajemy `permission denied`.	`findmnt -T "$STORE_PATH"`, `lsblk -f`, `journalctl -b` oraz prawa do samej ścieżki i katalogu `.chunks`. `STORE_PATH` ustawiamy wcześniej na ścieżkę datastore. Sprawdzamy też ACL PBS dla datastore.	Nie tworzymy nowego datastore w tej samej ścieżce, nie uruchamiamy `chmod -R 777` i nie formatujemy dysku przed zabezpieczeniem stanu.
Brak miejsca występuje w zadaniu, choć datastore ma wolną pojemność.	Sprawdzamy pełną ścieżkę z komunikatu oraz `df -hT /var/log/proxmox-backup/tasks` i `df -ih /var/log/proxmox-backup/tasks`.	Nie kasujemy backupów wyłącznie dlatego, że pojawił się `ENOSPC`; pełna może być partycja systemowa lub inode.
Verify kończy się komunikatem `verification failed`.	Otwieramy log nieudanego zadania w PBS, zapisujemy identyfikator snapshotu i porównujemy go z ostatnim poprawnie zweryfikowanym backupem. Sprawdzamy również stan dysków oraz miejsce i inode datastore.	Nie kasujemy w ciemno ostatniej działającej kopii ani nie uznajemy kolejnego `TASK OK` za naprawę uszkodzonego snapshotu. Najpierw testujemy restore znanej dobrej kopii.
Storage jest `active`, ale `pvesm list` nie pokazuje starych kopii albo restore odmawia dostępu.	Sprawdzamy właściciela grupy backupu oraz prawa używanego tokena: `proxmox-backup-manager user permissions 'pve-lab@pbs!pve-lab-01' --path /datastore/pve-lab-backup`. `DatastoreBackup` obejmuje tylko grupy należące do tej tożsamości.	Nie rozwiązujemy problemu odruchowo rolą `DatastoreAdmin`. Po zmianie tokena starsze grupy mogą należeć do poprzedniej tożsamości.
Sync do drugiego PBS przerywa się po kilku minutach.	Log sync joba po obu stronach, ciągły ping podczas transferu, wersję kernela, MTU i rzeczywistą przepustowość. Pierwszy transfer wielu terabajtów planujemy osobno.	Nie wystawiamy PBS bezpośrednio do Internetu tylko po to, by „sprawdzić”, czy sync ruszy. Najpierw zapewniamy VPN, firewall i kontrolę TLS.
Backup jest zaszyfrowany, ale nie ma klucza odzyskiwania.	Ustalamy, gdzie jest keyfile lub master private key i czy procedura została przetestowana poza źródłowym hostem.	Nie zakładamy, że administrator PBS odzyska dane samym dostępem do datastore. Bez klucza zaszyfrowany backup może być bezużyteczny.

Forum Proxmox pokazuje też konkretne odmiany tych problemów: brak miejsca po retencji, błędy verify, powolne odtwarzanie, utracony datastore i timeouty synchronizacji. Są użytecznym materiałem do diagnozy, lecz log konkretnego środowiska ma pierwszeństwo przed dopasowaniem objawu do cudzego wątku.

Co musi być prawdą, zanim uznamy PBS za gotowy

Datastore znajduje się na świadomie wybranym storage i ma rezerwę miejsca na wzrost danych oraz GC.
Każdy PVE lub host ma własną tożsamość albo token z minimalnym zakresem uprawnień.
PBS jest dodany do PVE z poprawnym fingerprintem TLS, a pvesm status pokazuje active.
Backup testowej VM zakończył się poprawnie, a jego snapshot jest widoczny z PVE.
Retencja, GC, verify i powiadomienia mają właściciela, harmonogram oraz nie konkurują bez potrzeby o te same dyski.
Odtworzenie do nowej, odizolowanej VM zostało wykonane i zapisane jako procedura.
Wiadomo, co chroni PBS, a czego nie chroni jego fizyczne położenie. Dla istotnych danych istnieje druga kopia poza tą samą domeną awarii.

PBS daje dużą wartość już w małym środowisku, ale dopiero po przejściu tej listy jest elementem odtwarzalnego planu, a nie tylko kolejną działającą usługą w panelu.

Źródła i dalsza lektura

Mechanizm PBS i integrację z PVE opisuje oficjalna dokumentacja: wprowadzenie i architektura PBS, integracja z Proxmox VE, datastore, kontrola dostępu i 3-2-1, użytkownicy, tokeny i ACL, prune, GC i verify oraz klient i klucze szyfrowania.

Do sekcji problemów wykorzystaliśmy także powtarzające się sytuacje z oficjalnego forum: pełny datastore, błędy verify, wąskie gardło odtwarzania, timeout sync joba i niedostępny datastore.