Proxmox Backup Server 2026 — kompletny przewodnik PL

Czym jest Proxmox Backup Server

Proxmox Backup Server (skrót: PBS) to dedykowany system backupu dla środowisk wirtualizacyjnych Proxmox VE oraz hostów Linux. Jest oddzielnym produktem od Proxmox VE — instalujesz go na osobnym serwerze albo maszynie wirtualnej, a Proxmox VE komunikuje się z nim po sieci.

Trzy główne funkcje, które odróżniają PBS od klasycznego rozwiązania vzdump (wbudowanego w Proxmox VE):

• Deduplikacja na poziomie chunks — dane dzielone na bloki 4 MB, każdy chunk zapisywany tylko raz w datastore, identyfikowany przez SHA-256
• Szyfrowanie po stronie klienta — backupy są szyfrowane na serwerze źródłowym (PVE) przed wysłaniem do PBS, więc nawet administrator PBS nie widzi treści
• Inkrementalny "forever" — pierwszy backup pełny, każdy kolejny zapisuje tylko zmienione chunks; nie wymaga okresowych pełnych jak typowe rozwiązania

W praktyce oznacza to, że dla typowej infrastruktury MŚP (10-30 maszyn wirtualnych z bazami danych, plikami i usługami biznesowymi) zajętość datastore PBS rośnie liniowo z liczbą zmienionych danych, nie z liczbą backupów. To kluczowa różnica architektoniczna.

Architektura: chunks, deduplikacja, szyfrowanie

Format danych w datastore

PBS dzieli dane wirtualnych dysków oraz kontenerów na chunki o stałym rozmiarze 4 MB. Każdy chunk jest:

1. Kompresowany algorytmem zstandard (zstd, level 3 domyślnie)
2. Opcjonalnie szyfrowany AES-256-GCM (jeśli klucz jest skonfigurowany)
3. Zapisywany w datastore pod ścieżką wyznaczaną przez pierwsze 4 znaki SHA-256, np.:

   /mnt/datastore/main/.chunks/abcd/abcd1234567890...zstd

Indeks backupu (plik .fidx dla obrazów dysków, .didx dla katalogów) jest oddzielną strukturą wskazującą jakie chunki składają się na dany backup. Indeks jest mały (kilobajty), chunki są shared globally.

Deduplikacja w praktyce

Rozważmy hipotetyczny scenariusz: maszyna wirtualna z systemem operacyjnym Linux, 80 GB dysku z 30 GB realnie zajętymi. Backup wstępny:

Dla środowisk z wieloma VMami opartymi o ten sam template (np. 20 VM na bazie Debian 12) deduplikacja PBS daje spektakularne oszczędności — typowo >90% w porównaniu do plików tar.

Szyfrowanie AES-256-GCM

Klucz szyfrowania generujesz na PBS, ale szyfrowanie odbywa się po stronie KLIENTA (Proxmox VE) — czyli przed wysłaniem przez sieć. Konsekwencje:

• Administrator PBS nie ma dostępu do treści backupów (chyba że ma też klucz)
• Transmisja sieciowa jest również szyfrowana (TLS) — masz zatem szyfrowanie w tranzycie i w spoczynku
• Klucz musi być przechowywany off-site — utrata klucza = utrata wszystkich backupów
• Verification chunks nie wymaga klucza (sprawdza tylko hash chunks), ale restore tak

Wymagania sprzętowe

Dlaczego ZFS jest preferowany dla PBS

ZFS daje PBS trzy ważne właściwości:

1. Checksumming na poziomie filesystemu — drugi poziom ochrony przed bit-rotem (PBS już ma własne checksumy chunks)
2. Snapshoty datastore — możesz zrobić ZFS snapshot przed major operation (np. upgrade PBS) i wrócić w razie problemu
3. Compression LZ4 — działa razem z zstd PBS, dodatkowa kompresja ~5-15%

Wymagania sieciowe

Backup pełnej VM 100 GB po sieci 1 Gbps trwa ~14 min teoretycznie (przy 100% wykorzystaniu pasma) — w praktyce 20-30 min. Dla większych infrastruktur (50+ VM) zalecane:

• Sieć 10 Gbps między PVE klastrem a PBS
• Dedykowany VLAN backup (oddzielony od ruchu produkcyjnego)
• Dla off-site: 100-1000 Mbps, akceptowalne dla incremental

Instalacja krok po kroku

1. Pobierz ISO Proxmox Backup Server

   Z oficjalnej strony proxmox.com/downloads pobierz najnowszy ISO PBS (4.x). To Debian 13 z preinstalowanym PBS — instalacja taka sama jak Debian, z dodatkowym wyborem storage system na początku.

   # Bezpośrednio na serwerze (jeśli masz tam dostęp do internetu)
   wget https://enterprise.proxmox.com/iso/proxmox-backup-server_4.2-1.iso

2. Zainstaluj system

   Boot z ISO, instalator GUI. Wybierz storage system: ZFS RAID-Z2 dla danych chunks (jeśli masz 4+ HDD), ZFS mirror NVMe dla rpool (system + index). Skonfiguruj sieć — IP, gateway, DNS.

   # Po instalacji zaktualizuj system
   apt update && apt full-upgrade -y

3. Skonfiguruj repozytorium

   Domyślnie PBS używa pbs-enterprise (wymaga subskrypcji). Bez subskrypcji przełącz na pbs-no-subscription:

   # Wyłącz enterprise repo
   sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pbs-enterprise.list
   
   # Dodaj no-subscription repo
   echo "deb http://download.proxmox.com/debian/pbs trixie pbs-no-subscription" \
     > /etc/apt/sources.list.d/pbs-no-subscription.list
   
   apt update && apt full-upgrade -y

4. Otwórz GUI PBS

   Połącz się przez przeglądarkę: https://IP-PBS:8007. Zaloguj jako root@pam z hasłem ustawionym w instalacji. Pierwsze logowanie pokaże ostrzeżenie certyfikatu (self-signed) — zaakceptuj lub wgraj swój cert (ACME / Let's Encrypt można skonfigurować w GUI).

5. Utwórz użytkownika dla zadań backupu

   Nie używaj root@pam dla backupów z PVE — utwórz dedykowanego użytkownika z minimalnymi uprawnieniami:

   # Utwórz user
   proxmox-backup-manager user create backup@pbs --password ''
   
   # Nadaj rolę DatastoreBackup tylko na konkretnym datastore
   proxmox-backup-manager acl update /datastore/main DatastoreBackup --auth-id backup@pbs
   
   # Wygeneruj API token (zalecane zamiast hasła)
   proxmox-backup-manager user generate-token backup@pbs pve-token1
   # Zapisz wyświetlony token — pokazuje się tylko raz!

Konfiguracja datastore i szyfrowania

Tworzenie datastore

Datastore to fizyczna lokalizacja gdzie PBS zapisuje chunki. Możesz mieć wiele datastore (np. fast-ssd dla DB, cold-hdd dla archiwum).

# GUI: Datastore → Add → wybierz katalog (np. /mnt/datastore/main)

# CLI:
proxmox-backup-manager datastore create main /mnt/datastore/main \
  --comment "Główny datastore produkcyjny" \
  --gc-schedule "sun 04:00" \
  --prune-schedule "daily 03:00"

Parametry:

• gc-schedule — kiedy uruchamiać Garbage Collection (zalecane: niedziela 4:00, poza godzinami szczytu)
• prune-schedule — kiedy stosować retencję (codziennie 3:00 typowo)
• Po utworzeniu możesz dodać verify-schedule dla weryfikacji integralności

Klucz szyfrowania

Klucz generujesz JEDEN RAZ na PBS i kopiujesz na klientów (PVE):

# Wygeneruj klucz (na PBS jako root)
proxmox-backup-client key create /root/backup-key.json \
  --kdf scrypt

# Wpisz hasło ochrony klucza (drugi czynnik) — opcjonalne ale zalecane
# Powstaje plik backup-key.json z kluczem AES-256

# Wydrukuj wersję paper-backup
proxmox-backup-client key paper-key /root/backup-key.json \
  > /root/backup-key.paper.txt
# Plik .paper.txt zawiera klucz w formie czytelnej dla człowieka — DRUKUJ I CHOWAJ W SEJFIE

Następnie kopiujesz klucz na klientów (PVE):

# Z PBS na każdy node Proxmox VE
scp /root/backup-key.json root@pve-node1:/etc/pve/priv/backup-key.json
# Plik /etc/pve/ jest replikowany w klastrze automatycznie

Integracja z Proxmox VE

Dodanie PBS jako storage w PVE

W Proxmox VE: Datacenter → Storage → Add → Proxmox Backup Server. Wymagane pola:

Tworzenie zadania backupu

Datacenter → Backup → Add. Możesz określić:

• VM/CT — wybrane lub all (z exclusion)
• Schedule — cron format: 2:00 (codziennie 2:00), mon..fri 22:00
• Storage — pbs-main
• Mode — snapshot (live, brak przerwy), suspend (krótka pauza), stop (offline)
• Compress — zstd zalecane (szybkie + dobry ratio)
• Mailto — email do raportów (sukces/awaria)

# Konfiguracja przez CLI
pvesh create /cluster/backup \
  --id "daily-all" \
  --schedule "2:00" \
  --storage pbs-main \
  --vmid all \
  --mode snapshot \
  --compress zstd \
  --mailto biuro@firma.pl \
  --mailnotification failure

Strategia retencji GFS

GFS (Grandfather-Father-Son) to klasyczna strategia retencji backupów. PBS implementuje ją natywnie przez prune:

W praktyce daje to ~25 backupów per VM rozłożonych w czasie: ostatni tydzień szczegółowo, miesiąc miesięcznie, lata rocznie.

# Przykład: ustaw retencję dla datastore
proxmox-backup-manager datastore update main \
  --keep-last 3 \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12 \
  --keep-yearly 2

# Test prune (DRY-RUN — pokazuje co usunie, ale nie usuwa)
proxmox-backup-client prune --dry-run vm/100 main

Garbage Collection

Prune oznacza chunki jako nieużywane, ale nie usuwa ich z dysku. To robi Garbage Collection (GC). Cykl:

1. Phase 1: GC mark — przegląda wszystkie indexy backupów i oznacza używane chunks
2. Phase 2: GC sweep — usuwa chunki nieoznaczone w Phase 1, jeśli są starsze niż 24h (safety margin)

# Manualne uruchomienie GC
proxmox-backup-manager garbage-collection start main

# Status
proxmox-backup-manager garbage-collection status main

Weryfikacja integralności

Verification sprawdza czy chunki nie zostały uszkodzone (bit-rot, błąd dysku). Bez verification pierwszy raz dowiesz się o uszkodzeniu przy próbie restoru — czyli ZA PÓŹNO.

Konfiguracja verify-job

# Dodaj verify-job dla datastore main
proxmox-backup-manager verify-job create verify-main \
  --store main \
  --schedule "sat 22:00" \
  --outdated-after 30 \
  --ignore-verified true

# Parametry:
# - schedule: kiedy uruchamiać (sobota 22:00 = mało ruchu)
# - outdated-after: re-weryfikuj po 30 dniach (chunks które już były zweryfikowane)
# - ignore-verified: pomiń chunks zweryfikowane wcześniej (przyspiesza)

Verification działa na poziomie chunks (sprawdza każdy hash SHA-256). Czas pełnej weryfikacji: ~1-2 godziny per TB datastore (ZFS HDD).

Co zrobić gdy verification znajdzie błąd

1. Sprawdź log: journalctl -u proxmox-backup-proxy | grep verify
2. Zidentyfikuj uszkodzony chunk (hash SHA-256)
3. Sprawdź dysk: smartctl -a /dev/sdX — jeśli dysk umiera, wymień
4. Jeśli masz sync-job na drugi PBS — usuń uszkodzony chunk, sync przywróci go z replicy
5. Jeśli nie masz repliki — backup VM jest stracony, ale tylko TEN konkretny snapshot. Pozostałe są bezpieczne (deduplikacja: chunk uszkodzony to często chunk wspólny dla wielu backupów, ale są też nadrabiane przy następnym backupie)

Restore — pełen VM i pojedyncze pliki

Pełen restore VM

Najprostsza droga: przez GUI Proxmox VE. Datacenter → wybierz storage PBS → Backups tab → wybierz backup → Restore. Możesz przywrócić jako:

• Original VMID — zastępuje istniejącą VM (uwaga: dane bieżące są tracone!)
• New VMID — bezpieczniejsze, tworzy nową VM, oryginał zostaje

# Restore z CLI
qmrestore /var/lib/pve/local-storage/dump/vzdump-qemu-100-2026_05_07-02_00_01.vma.zst 100 \
  --storage local-zfs \
  --unique 1

# Restore z PBS storage
qmrestore pbs-main:backup/vm/100/2026-05-07T02:00:01Z 200 \
  --storage local-zfs

Restore pojedynczych plików (file-level)

To killer feature PBS — możesz wyciągnąć pojedynczy plik z backupu VM bez restoru całej maszyny.

W GUI: wybierz backup → File Restore. PBS uruchamia tymczasową mini-VM która montuje obraz dysku tylko-do-odczytu, parsuje filesystem (ext4/xfs/ntfs/zfs) i pokazuje strukturę katalogów. Klikasz na plik → Download → dostajesz plik.zip.

Działa dla:

• VM z linuxowym FS (ext4, xfs, btrfs, zfs)
• VM z Windows (NTFS)
• Kontenerów LXC (każdy wspierany FS Linuxa)
• Zaszyfrowanych dysków LUKS — wymaga klucza LUKS oprócz klucza PBS

Replikacja PBS-to-PBS i tape

Sync-job (replikacja off-site)

Strategia 3-2-1 wymaga off-site. Najtańsza i najbardziej elastyczna implementacja: drugi PBS w innej lokalizacji + sync-job.

# Na PBS-A (źródło) — utwórz remote do PBS-B
proxmox-backup-manager remote create pbs-offsite \
  --host pbs-offsite.firma.pl \
  --auth-id sync@pbs!sync-token \
  --password '' \
  --fingerprint 'XX:YY:ZZ:...'

# Utwórz sync-job
proxmox-backup-manager sync-job create offsite-daily \
  --remote pbs-offsite \
  --remote-store main \
  --store main \
  --schedule "daily 06:00" \
  --transfer-last 7

Parametr transfer-last 7 oznacza: synchronizuj tylko 7 ostatnich snapshotów per VM. Oszczędza ruch sieci i miejsce na off-site.

Tape backup (PBS Tape)

Od PBS 2.1 wbudowane wsparcie LTO. Wymaga:

• Biblioteka taśmowa lub standalone drive (LTO-7/8/9)
• Konfiguracja tape pools (kolekcje taśm), tape changer, tape backup jobs
• Procedura rotacji taśm off-site

Tape jest tańsze niż off-site PBS dla bardzo dużych datasets (>100 TB) lub gdy compliance wymaga "air-gapped" media. Dla MŚP off-site PBS jest tańszy, prostszy i szybszy w restore.

Najczęstsze błędy

1. Brak klucza szyfrowania off-site — w razie awarii PBS i utraty dysku z kluczem, backupy są bezużyteczne. Fix: wydrukuj paper-key, zapisz w sejfie + KeePass + zaszyfrowany cloud.
2. Datastore na pojedynczym dysku bez RAID — utrata dysku = utrata wszystkich backupów. Fix: minimum ZFS mirror, idealnie RAID-Z2.
3. Brak verify-job — bit-rot w chunks pozostaje niezauważony do pierwszej próby restoru. Fix: verify weekly z outdated-after 30.
4. GC nigdy nie uruchamia się — datastore puchnie mimo prune. Fix: sprawdź gc-schedule i log journalctl -u proxmox-backup-proxy.
5. Backup baz danych bez quiesce — snapshot jest crash-consistent ale baza może być uszkodzona. Fix: qm guest exec dump przed backup, lub wyłączenie bazy na 30s podczas snapshot.
6. Token bez ograniczeń — token backup@pbs!token1 z prawami root. Fix: ACL DatastoreBackup tylko na konkretnym datastore, nigdy Admin.
7. Brak monitoring — backup się nie udaje, nikt nie wie. Fix: Zabbix template dla PBS (sprawdza ostatni successful backup per VM, status sync-jobs, wolne miejsce datastore, errors verify).
8. Datastore na slow HDD bez SSD index — prune i verify trwają długo, GC blokuje. Fix: NVMe dla rpool z indeksem, HDD dla chunks danych.
9. Pełen backup raz w tygodniu zamiast incremental forever — niepotrzebnie zajmuje miejsce i sieć. Fix: standardowa konfiguracja PBS to incremental forever, NIE rób fulli okresowych.

Kiedy warto wdrożyć PBS

Warto:

• Środowisko Proxmox VE z 5+ VMami (dedup daje wymierne oszczędności)
• Wymagania compliance (RODO, ISO 27001, NIS2) co do retencji i szyfrowania
• Strategia 3-2-1 (PBS on-site + drugi PBS off-site)
• Częste przywracanie pojedynczych plików (file-restore PBS)
• Ograniczone miejsce na backup storage (deduplikacja 70-95%)
• Wymagana incremental forever (brak okresowych fulli)

Może nie warto:

• Pojedyncza VM dla małej firmy — vzdump na NAS wystarczy, prościej
• Środowisko bez Proxmox VE (PBS Client działa standalone, ale stack mniej spójny)
• Wymagania backupu aplikacyjnego z szyfrowaniem na poziomie tabeli (lepiej narzędzie aplikacyjne, nie maszynowe)
• Backup przez sieć WAN bez kompresji i szyfrowania end-to-end (PBS to ma, ale wymaga tuning sieci)

Cennik wdrożenia PBS przez Sztorm IT

Wszystkie pakiety obejmują: wstępny audyt środowiska, instalację PBS, konfigurację datastore, klucz szyfrowania z paper-backup, integrację z PVE, ustawienie GFS, verify-job, dokumentację techniczną, 30 dni wsparcia powdrożeniowego.

Często zadawane pytania (FAQ)

Powiązane materiały

• PBS — co to jest i dlaczego potrzebujesz?
• ZFS vs Ceph — który storage do backupu?
• Klaster Proxmox — konfiguracja krok po kroku
• Proxmox VE vs VMware vSphere 2026
• Cennik subskrypcji Proxmox (PVE/PBS/PMG)