Proxmox Backup Server installeren op een VPS

Wat Proxmox Backup Server op een VPS u daadwerkelijk oplevert

Proxmox Backup Server (PBS) op een VPS fungeert als een offsite doel dat hetzelfde protocol spreekt als uw Proxmox VE (virtual environment) cluster. Hierdoor is elke back-up na de eerste incrementeel, gededupliceerd over alle gastsystemen, versleuteld voordat deze uw locatie verlaat en achteraf verifieerbaar. U huurt een VPS met een block volume, installeert PBS op Debian 13, maakt één datastore aan op dat volume en voegt deze in Proxmox VE toe als opslag van het type pbs. De installatie duurt tien minuten. Alles daarna – namespaces, garbage collection, sleutelbeheer en een restore die u daadwerkelijk heeft uitgevoerd – bepaalt of de back-up over een jaar nog waarde heeft.

De reden om PBS te gebruiken in plaats van het kopiëren van vzdump-bestanden naar een gehuurde schijf, is de chunk store. De client splitst elke schijf van een gastmachine in chunks van ongeveer 4 MiB, hasht deze en uploadt alleen de chunks die de datastore nog niet bevat. Voor een draaiende virtuele machine houdt QEMU na de eerste back-up gewijzigde blokken bij in een dirty bitmap, waardoor de volgende run alleen die blokken van de lokale schijf leest. Een gastmachine van 200 GB die per dag 3 GB wijzigt, verstuurt ook ongeveer 3 GB per dag. Dat is wat een thuisverbinding en een gehuurd volume samen laat werken, en het is de reden waarom een VPS als offsite back-updoel beter is dan een reserve-schijf bij een vriend thuis. Als u nog beslist waar de hypervisor zelf moet draaien, behandelt Proxmox thuis versus een gehuurde VPS die vraag afzonderlijk.

Bepaal de grootte van het volume voordat u het huurt

Het bepalen van de grootte is een rekenkundige oefening die u uitvoert op basis van uw eigen cijfers. Neem de ruimte die elke guest daadwerkelijk gebruikt, niet de grootte van de virtuele schijf, en tel daar de dagelijkse wijzigingen bij op, vermenigvuldigd met het aantal dagen dat u de gegevens bewaart. Compressie en deduplicatie verbeteren dit cijfer, dus beschouw het resultaat als een maximum en niet als een streefwaarde.

[
  {
    "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
  }
]

Deze rijen zijn een uitgewerkt voorbeeld, geen meting. Lees de gebruikte ruimte af via df -h in elke guest en lees de dagelijkse wijziging af van de grootte van de tweede en derde back-up in het PBS-taaklogboek zodra deze bestaan.

De mail-guest in het voorbeeld gebruikt 120 GB en wijzigt ongeveer 3.0 GB per dag, dus dertig dagelijkse snapshots vereisen ongeveer 210 GB: één volledige kopie plus dertig dagen aan wijzigingen. Tel de laatste kolom op voor alle 3 guests en het totaal is ongeveer 619 GB. Voeg daar een vijfde aan toe voor indexen, metadata en de ruimte die garbage collection nodig heeft om te werken, wat uitkomt op een volume van 1 TB.

De rest van het plan is bescheiden. PBS functioneert prima met 2 GB RAM en is comfortabel met 4 GB, omdat het intensieve werk aan de kant van het cluster plaatsvindt: de Proxmox VE-node leest de guest-schijven en voert het chunking- en hashing-proces uit. Wat de VPS doet, is chunks schrijven en de twee zware taken uitvoeren: garbage collection en verificatie. Huur de datastore als een apart block volume in plaats van als één grote root-schijf, omdat u een volume later kunt vergroten zonder de server opnieuw op te bouwen.

Proxmox Backup Server installeren op Debian 13

Sinds augustus 2026 is de huidige combinatie Proxmox Backup Server 4 op Debian 13, met codenaam trixie. Oudere handleidingen koppelen PBS 2 aan Debian 11; aangezien de codenaam onderdeel is van de repository-definitie, levert het kopiëren van een oude suite-naam een apt-foutmelding op over een ontbrekend release-bestand. Begin met een schone Debian 13-image. Voer alles hieronder uit als root, of met sudo zoals geschreven.

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

De checksum moet 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45 zijn. Als dit niet het geval is, stop dan. Een onjuiste keyring betekent dat u op het punt staat pakketten te installeren die zijn ondertekend door een partij die u niet heeft gecontroleerd.

Schrijf /etc/apt/sources.list.d/pbs.sources met de no-subscription repository; dit is de juiste keuze voor een server zonder supportcontract:

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

De webinterface reageert op HTTPS-poort 8007. Log in als root@pam met het systeem-rootwachtwoord, omdat PBS deze gebruiker authenticeert via PAM (pluggable authentication modules), dezelfde accounts die het besturingssysteem gebruikt. Het certificaat is zelfondertekend en uw browser zal dit melden. De vingerafdruk van dat certificaat is de waarde die Proxmox VE later vastlegt (pins), dus de waarschuwing is verwacht gedrag en geen probleem dat opgelost moet worden.

Poort 8007 is een inlogformulier op het openbare internet, dus laat deze niet voor iedereen openstaan. Eén nftables-bestand dekt dit af. Het schrijven van /etc/nftables.conf wist de huidige regelset, dus sla dit over als iets anders de firewall op deze machine al beheert.

#!/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
  }
}

Pas het toe met sudo systemctl enable --now nftables en houd een tweede SSH-sessie open terwijl u dit doet: policy drop plus één typefout in de SSH-regel sluit u buiten van uw eigen server. Vervang 203.0.113.7 door het adres van waaruit uw cluster verbinding maakt. Als dat adres dynamisch is, verbreed de regel dan naar het bereik van uw provider of beëindig de verbinding in een tunnel. Houd er rekening mee dat de meeste VPS-panelen een aparte netwerkfirewall voor de machine hebben die dezelfde poort moet toestaan.

Plaats de datastore op een eigen volume

De datastore mag niet op het root-bestandssysteem staan. Wanneer een datastore een gedeeld root-bestandssysteem vult, mislukt de back-up en stopt alles op de server, inclusief de logging die u nodig heeft om de oorzaak te achterhalen. Koppel het block-volume, formatteer het, mount het, en maak pas daarna de datastore aan binnen het mount-point.

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

Gebruik de apparaatnaam uit lsblk. Dit is /dev/vdb op de meeste KVM-images en /dev/sdb op andere; ga er nooit zomaar vanuit. Voeg de mount toe aan /etc/fstab op basis van label, zodat een hernoeming van het apparaat na een reboot er niet voor zorgt dat de datastore naar de verkeerde schijf wijst:

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 hoort het apparaat, het pad en de opties inclusief rw,relatime weer te geven. In die ene regel schuilen twee fouten. Als de mount niet aanwezig is en u de datastore toch aanmaakt, schrijft PBS naar het root-bestandssysteem onder het mount-point. De volgende succesvolle mount verbergt die data zonder deze te verwijderen: de datastore lijkt dan leeg en het root-bestandssysteem blijft vol. Als de opties noatime bevatten, weigert PBS te werken, omdat het een veiligheidscontrole op de toegangstijd uitvoert bij het aanmaken van de datastore en bij elke garbage collection.

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

Dit creëert een .chunks-directory die 65536 subdirectories bevat, genaamd 0000 tot en met ffff. Een datastore bestaat uit honderdduizenden kleine bestanden, niet uit enkele grote. Hieruit volgen twee zaken. Het kopiëren van een datastore met een standaard file-level tool is te traag om bruikbaar te zijn, en een volume-snapshot van een provider die wordt gemaakt terwijl back-ups draaien, is geen consistente kopie. Dit is dezelfde reden waarom snapshots geen back-ups vervangen in andere scenario's.

Namespaces voorkomen dat twee hosts met elkaar conflicteren

Een datastore is standaard plat. Back-ups worden benoemd als vm/100, ct/101 en host/<name>. Twee clusters die elk een guest met ID 100 hebben, schrijven naar dezelfde groep; hun snapshots raken verweven en een retentieregel die voor de een is geschreven, telt ook de snapshots van de ander mee. Namespaces geven elke bron een eigen boomstructuur binnen één datastore.

Maak deze aan op de PBS-host. Het argument --repository heeft de vorm [[auth-id@]server[:port]:]datastore, dus een lokale variant leest als root@pam@localhost:store1, en het commando vraagt om het root-wachtwoord.

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'

Deduplicatie wordt niet beïnvloed door deze splitsing. Chunks worden gedeeld over de gehele datastore, dus tien Debian-guests verspreid over drie namespaces slaan nog steeds slechts één kopie van het basissysteem op. Dat is het argument voor één datastore met namespaces in plaats van één datastore per host: afzonderlijke datastores betekenen afzonderlijke chunk-pools, en afzonderlijke chunk-pools betekenen dat u meerdere keren betaalt voor dezelfde Debian-installatie.

Geef elke bron een eigen account, beperkt tot de eigen namespace. Een API (application programming interface) token is een inloggegeven dat bij een gebruiker hoort en eigen rechten draagt; dit is wat u wilt op een machine die gestolen zou kunnen worden.

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'

Het token-commando toont het geheim slechts één keer:

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

Kopieer het nu, want PBS bewaart geen vorm van het token die het opnieuw aan u kan tonen. Bekijk het toegangscontrole-commando twee keer. Het benoemt het token, backup@pbs!pve-home, en niet de gebruiker, omdat token-rechten alleen worden berekend op basis van vermeldingen die het token zelf benoemen. Een vermelding voor alleen backup@pbs laat het token zonder enige toegang achter, en de eerste back-up faalt dan op rechten in plaats van op iets dat zichtbaar is in het netwerk. Het pad is net zo belangrijk: een token dat beperkt is tot /datastore/store1/pve-home kan niets lezen of verwijderen in de office-namespace, waardoor één gecompromitteerd cluster de geschiedenis van een andere locatie niet kan vernietigen.

De VPS toevoegen als back-upopslag in Proxmox VE

Lees eerst de certificaat-vingerafdruk op de PBS-host.

sudo proxmox-backup-manager cert info | grep Fingerprint

Voer daarna op een willekeurige node van het cluster het volgende uit:

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

Plak de waarde cert info die werd getoond op de plek van de tijdelijke aanduiding op de derde regel. Door --password zonder waarde mee te geven, vraagt pvesm erom, zodat het token-geheim niet in uw shell-geschiedenis terechtkomt. Het wordt opgeslagen in /etc/pve/priv/storage/pbs-offsite.pw en de opslagdefinitie zelf komt in /etc/pve/storage.cfg, die naar elke node in het cluster wordt gerepliceerd; u configureert dit dus eenmalig voor het gehele cluster.

--prune-backups keep-all=1 vertelt Proxmox VE dat er niets verwijderd mag worden. Retentiebeleid hoort thuis aan de kant van PBS, wat verderop wordt behandeld, om een reden die helder is: het token heeft dan geen rechten nodig om te verwijderen. Hierdoor kan een cluster dat door ransomware wordt versleuteld, niet de offsite-geschiedenis wissen die juist bedoeld is als hersteloptie.

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

pvesm status toont active in de statuskolom, met de totale en gebruikte opslagruimte van de datastore ernaast. inactive betekent dat de node geen TLS-sessie (transport layer security) kon opzetten naar poort 8007; dit duidt eerder op een firewall- of vingerafdrukprobleem dan op een probleem met de inloggegevens.

De eerste back-up uploadt alle gegevens, dus voer de berekening uit voordat u begint. 200 GB is 1600 gigabit, en een 100 Mbit-uplink verplaatst 0,1 gigabit per seconde. De minimale duur is dus ongeveer vierenhalf uur, maar in de praktijk duurt het langer. Start de back-up op een moment dat u de bandbreedte niet nodig heeft. Elke volgende run verstuurt alleen nieuwe datablokken.

Client-side encryptie en de locatie van de sleutel

De VPS is een computer die niet uw eigendom is. Versleutel op de client; de datastore bevat dan brokken (chunks) die de provider niet kan lezen.

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

Dit schrijft een nieuwe sleutel naar /etc/pve/priv/storage/pbs-offsite.enc, die alleen leesbaar is voor root en wordt gerepliceerd met de rest van /etc/pve. Vanaf de volgende back-up versleutelt de client elke chunk voordat deze wordt verzonden. De server kan nog steeds uw snapshots en hun grootte weergeven, maar kan de inhoud niet lezen.

Nu het onderdeel dat dit een back-up maakt in plaats van een risico. Een gegenereerde sleutel heeft geen wachtwoordzin en bestaat alleen op het cluster dat hij beschermt. Als dat cluster wordt gestolen of door iemand anders wordt versleuteld, bevat de VPS gegevens die niemand kan openen. Kopieer de sleutel van het cluster op de dag dat u deze aanmaakt.

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 print de sleutel als een document dat bedoeld is om op papier af te drukken en elders te bewaren. Behandel het bestand zelf als het geheim dat het is, aangezien iedereen die het bezit elke back-up die ermee is gemaakt, kan ontsleutelen. Voor een grotere opstelling ondersteunt PBS ook een hoofdsleutel, een RSA (Rivest Shamir Adleman) sleutelpaar aangemaakt met proxmox-backup-client key create-master-key, waarbij elke back-up zijn eigen versleutelingssleutel opslaat, versleuteld met de publieke helft, terwijl de private helft offline blijft voor herstel.

Eén consequentie van dit ontwerp is het waard om te weten voordat u begint, in plaats van daarna. Bij versleutelde back-ups wordt de chunk-digest berekend op basis van de platte tekstinhoud gecombineerd met de versleutelingssleutel. Hierdoor produceren twee identieke chunks die met verschillende sleutels zijn versleuteld, verschillende digests en vindt er nooit ontdubbeling tussen plaats. Het wijzigen van de sleutel betekent dat de volgende back-up alles opnieuw uploadt, en de oude chunks blijven staan totdat hun snapshots zijn opgeschoond en verzameld. Beslis over versleuteling vóór de eerste upload.

Pruning van markeringen, garbage collection voert opschoning uit

Dit is de sectie die vaak wordt overgeslagen, en het is de sectie die de schijfruimte vult. Het prunen van een snapshot verwijdert de metadata: het manifest, de indexen, het logboek en de notities. Er worden echter geen chunks verwijderd. Chunks worden gedeeld tussen snapshots, dus kan het systeem niet weten of een chunk ongebruikt is totdat elke resterende index is gelezen; garbage collection is de taak die deze indexen leest. Een datastore met een prune-schema maar zonder garbage collection-schema zal alleen maar blijven groeien.

Stel beide in. Eerst de retentie, één taak per 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

Stel daarna het collectie-schema in op de datastore, enkele uren na de prune-taak en buiten het back-upvenster:

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

Controleer de splitsing zelf eenmaal op de PBS-host:

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

Voer de prune-taak uit, voer daarna df uit, en het cijfer voor gebruikt geheugen verandert niet. Voer garbage collection uit, voer daarna df opnieuw uit, en het cijfer verandert wel.

Garbage collection verloopt in twee fasen. Fase één doorloopt elke index in de datastore en werkt de toegangstijd (atime) bij van elke chunk waarnaar die indexen verwijzen. Fase twee verwijdert de chunks waarvan de toegangstijd ouder is dan de afkapdatum. Dit is 24 uur en 5 minuten vóór de start van de taak, of het begin van de oudste back-up die nog wordt geschreven, afhankelijk van welke datum het vroegst is. Deze marge bestaat omdat Linux bestandssystemen standaard mount met relatime, wat een toegangstijd ongeveer eens per dag bijwerkt in plaats van bij elke leesactie. Een chunk die een uur geleden is geschreven, wordt dus nooit verwijderd, zelfs niet als er nog niets naar verwijst. Ruimte die vrijkomt door een prune verschijnt pas bij de eerste collectie die meer dan een dag nadat de chunk voor het laatst is aangeraakt, wordt uitgevoerd. Een datastore die lijkt niets te hebben teruggewonnen, bevindt zich vaak simpelweg binnen dat venster.

Op een kleine VPS is dit de zwaarste taak die de machine uitvoert, omdat het elk chunk-bestand op het volume moet controleren (stat). Het taaklogboek eindigt met een samenvatting van wat is verwijderd en wat nog in de wachtrij staat vanwege de respijtperiode. Als er veel in de wachtrij staat, voer de taak dan de volgende dag opnieuw uit. PBS stelt gc-atime-safety-check en gc-atime-cutoff beschikbaar als opties voor het tunen van de datastore, maar beide moeten ongewijzigd blijven: ze bestaan voor opslagmedia die geen toegangstijden kunnen registreren. Het uitschakelen van de veiligheidscontrole op een bestandssysteem dat met noatime is gemount, is de manier waarop u chunks verliest waarnaar actieve snapshots nog verwijzen.

Verificatie bewijst dat de chunks nog leesbaar zijn

Een back-up die correct is geüpload, kan een jaar later onleesbaar zijn. Verificatie leest chunks opnieuw in en vergelijkt deze met de checksums die in de index zijn opgeslagen. Hierdoor wordt schade volgens een schema ontdekt in plaats van pas tijdens een herstelactie.

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

Houd het aantal threads laag op een kleine VPS. Verificatie wordt beperkt door schijf- en CPU-capaciteit en zal anders concurreren met andere processen op de server. Gebruik voor een planning het tabblad Verify Jobs van de datastore in de webinterface: een wekelijkse taak die reeds geverifieerde snapshots overslaat en alles ouder dan 30 dagen opnieuw controleert, dekt na verloop van tijd de gehele opslag zonder dubbel werk te verrichten.

Een snapshot die niet door de verificatie komt, wordt in het datastore-overzicht gemarkeerd als mislukt. Negeer dit niet. Chunks worden gedeeld, dus een enkele beschadigde chunk van een basisimage zorgt er meestal voor dat elke snapshot die ernaar verwijst, faalt. De oplossing is om de mislukte snapshots te verwijderen en een nieuwe back-up te draaien, waardoor de ontbrekende chunks opnieuw worden geüpload. Als er fouten blijven optreden, verdenk dan de opslag onder de datastore en stel schijfgezondheidsmonitoring op de VPS in, zodat de schijf u waarschuwt voordat de verificatietaak dat doet.

Test een restore, en test deze vervolgens zonder het cluster

U weet pas of een back-up werkt als u er een heeft teruggezet. Er zijn twee tests, en deze controleren verschillende zaken.

Volledige guest, op het cluster:

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

De eerste kolom van pvesm list is het volume-ID, en de tijdstempel is daar onderdeel van; kopieer dus uw eigen ID in plaats van het voorbeeld over te typen. Herstel naar een ongebruikt guest-ID en naar een andere opslaglocatie, en start de guest vervolgens met de netwerkinterface losgekoppeld. Herstel nooit over een draaiende guest heen om te controleren of back-ups werken, omdat een restore die halverwege faalt u ook de werkende kopie kost.

De tweede test is de test die niemand uitvoert. Ga ervan uit dat het gebouw waarin het cluster staat verloren is gegaan, en herstel vanaf een machine die er nooit deel van uitmaakte. Voeg op elke Debian 13-machine de client-only repository toe als /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

Vul de drie placeholders tussen aanhalingstekens in met uw eigen waarden, en neem de archiefnaam op de laatste regel over van wat snapshot files heeft weergegeven. Dit bewijst wat de eerste test niet kan: dat uw kopie van het sleutelbestand daadwerkelijke gegevens ontsleutelt, en dat u de client kunt aansturen vanaf een machine die nooit de configuratie van uw cluster heeft bevat. Noteer de vier benodigde waarden, de repository-string, het token-secret, de vingerafdruk en het sleutelbestand, en bewaar deze samen op de plek waar uw calamiteitenplan naar verwijst.

Wat deduplicatie wel en niet doet voor uw schijfgebruik

Deduplicatie is reëel en werkt over de gehele datastore. Tien Debian-guests delen één kopie van het basissysteem, waardoor de tweede identieke guest bijna geen opslagruimte kost. Het bespaart ook uploadbandbreedte, omdat de client een checksum verstuurt in plaats van data voor elk blok dat de server al bezit.

Het is belangrijk om duidelijk te zijn over wat het niet doet.

• Het verkleint geen data die wijzigt. Een database die elke nacht grote delen van zijn bestanden herschrijft, produceert elke nacht nieuwe blokken, en retentie vermenigvuldigt deze.
• Het werkt niet over de grens van een encryptiesleutel heen, zoals hierboven beschreven.
• Het werkt niet over de grens van een datastore heen; dit is het voornaamste argument voor namespaces.
• Het voorkomt niet dat een volume volloopt. Wanneer de datastore vol is, mislukken back-ups en zijn de enige oplossingen een groter volume of een kortere retentieperiode.

Plaats geen extra deduplicatielaag onder de datastore. Blokken komen al gededupliceerd en gecomprimeerd aan vanaf de client. ZFS-deduplicatie onder een datastore verbruikt daarom onnodig RAM-geheugen voor het zoeken naar overeenkomsten die al verwijderd waren voordat ze werden weggeschreven. Een standaard ext4 of xfs op het volume is hier de juiste keuze.

De webinterface rapporteert een deduplicatiefactor voor de datastore. Dat getal beschrijft uw guests en is het enige cijfer waar u op kunt plannen, aangezien gepubliceerde ratio's de data van anderen beschrijven. Als u ook back-ups op bestandsniveau nodig heeft van machines die geen Proxmox-guests zijn, draai deze dan naast elkaar op dezelfde VPS: PBS is een hypervisor-bewuste doelomgeving voor volledige guests, terwijl restic en BorgBackup zich richten op mappen, en restic back-ups naar een VPS geschikt zijn voor laptops en zelfstandige servers waar PBS niet voor bedoeld is.

Foutmodi en wat u zult zien

De opslag toont als inactief. pvesm status --storage pbs-offsite geeft inactive weer wanneer de node geen TLS-sessie naar poort 8007 kan voltooien. Controleer de firewall op de VPS, vervolgens de afzonderlijke netwerkfirewall van de provider en daarna de fingerprint. Een fingerprint die niet langer overeenkomt met het certificaat resulteert in dezelfde zichtbare fout als een geblokkeerde poort, en deze wijzigt telkens wanneer het certificaat wordt vervangen.

De eerste back-up mislukt door rechten. Het toegangscontrole-item moet de token benoemen in plaats van de gebruiker, en het moet de namespace dekken waar de opslag naar verwijst. Bevestig beide op het tabblad met rechten van de datastore in de webinterface voordat u elders gaat zoeken.

Garbage collection weigert te starten. De veiligheidscontrole voor de toegangstijd is mislukt, wat bijna altijd betekent dat het datastore-bestandssysteem is gemount met noatime. Voer findmnt -no OPTIONS /mnt/datastore/store1 uit om dit te bevestigen, corrigeer de optie in /etc/fstab en voer een remount uit. Schakel de controle niet uit om dit te omzeilen.

De datastore blijft alleen maar groeien. Prune-taken worden uitgevoerd en er wordt niets teruggewonnen. Of er is geen schema voor garbage collection, of elke collectie valt binnen het respijtvenster van 24 uur omdat deze direct na de back-ups wordt uitgevoerd. Controleer het schema met proxmox-backup-manager datastore show store1.

Een back-up die voorheen snel was, duurt nu uren. Een guest die is gestopt, gemigreerd of hersteld, verliest zijn dirty bitmap. Hierdoor leest de volgende run de volledige schijf aan de kant van het cluster, ook al wordt er maar weinig geüpload. Het taaklogboek toont een lange duur met een klein uploadcijfer, en de daaropvolgende run is weer snel. Als elke taak op de VPS traag is, ligt de oorzaak meestal buiten de datastore, en is CPU steal time door een luidruchtige buur het eerste wat u moet meten.

FAQ

Waarom blijft mijn Proxmox Backup Server datastore groeien wanneer de prune-taak draait?

Omdat pruning alleen snapshot-metadata verwijdert: het manifest, de indexen, het logboek en de notities. De chunks blijven op de schijf staan totdat garbage collection de chunks verwijdert waarnaar geen enkele index meer verwijst. Stel een schema in voor de datastore met proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' en controleer dit door df -h uit te voeren op het datastore-pad voor en na proxmox-backup-manager garbage-collection start store1. Houd rekening met een vertraging van ten minste een dag, omdat fase twee alleen chunks verwijdert waarvan de toegangstijd ouder is dan 24 uur en 5 minuten.

Hoeveel schijfruimte heeft een Proxmox Backup Server VPS nodig?

Tel de ruimte op die elke gast daadwerkelijk gebruikt en voeg daar de dagelijkse wijziging per gast vermenigvuldigd met het aantal dagen dat u de back-ups bewaart aan toe. Dat totaal is een bovengrens, aangezien compressie en deduplicatie in uw voordeel werken. Voeg ongeveer een vijfde toe voor indexen en werkruimte en rond vervolgens af naar een schijfgrootte die u kunt aanschaffen. Controleer na twee weken opnieuw het werkelijke verbruik in de datastore-weergave, omdat een schatting vóór de eerste back-up altijd in de ene of de andere richting onjuist is.

Waar moet de encryptiesleutel voor back-ups worden opgeslagen?

Overal, behalve uitsluitend op het cluster dat de sleutel beschermt. Proxmox VE bewaart deze op /etc/pve/priv/storage/<storage>.enc, wat wordt gerepliceerd naar elk knooppunt en dus verloren gaat bij verlies van het cluster. Kopieer de sleutel op de eerste dag, print deze uit met proxmox-backup-client key paperkey en bewaar die kopie in een ander gebouw. Let er ook op dat de sleutel deel uitmaakt van de chunk-digest; het later vervangen van de sleutel betekent dat de volgende back-up alles opnieuw uploadt.

Heb ik één datastore per Proxmox-host nodig, of namespaces?

Eén datastore, één namespace per bronhost of cluster. Deduplicatie werkt binnen een datastore en niet tussen datastores; splitsen per host zorgt er dus voor dat dezelfde basisimages meerdere keren worden opgeslagen. Namespaces houden de back-upgroepen gescheiden, zodat twee hosts die beide een gast met ID 100 hebben niet kunnen conflicteren. Een toegangscontrolepad in de vorm van /datastore/store1/pve-home beperkt het API-token van elke host tot zijn eigen namespace.

Kan een kleine VPS fungeren als Proxmox backup server?

Meestal wel voor een homelab, omdat het chunking- en hashing-proces plaatsvindt op het Proxmox VE-knooppunt in plaats van op de back-upserver. De VPS schrijft chunks en voert de twee zware taken uit: garbage collection en verificatie. Geef de server 4 GB RAM en houd het aantal verificatiethreads laag. Plan beide taken buiten het back-upvenster. Als ze desondanks veel langer duren dan de schijf zou moeten vereisen, meet dan de steal time voordat u een groter abonnement aanschaft.