Proxmox Backup Server in detail: deduplicatie, verificatie en retentie in een private cloud

Bijna niemand kijkt naar zijn back-ups tot de dag dat ze nodig zijn. Dan komen alle vragen tegelijk: bestaat de kopie? Is hij intact? Van wanneer is hij? Hoe lang duurt een restore? Staat hij op dezelfde plek als het systeem dat zojuist is uitgevallen? En de vervelendste vraag van allemaal: heeft iemand ooit aangetoond dat dit werkt?

In Proxmox VE-omgevingen beantwoordt Proxmox Backup Server (PBS) die vragen beter dan de meeste alternatieven in het opensource-ecosysteem. We schreven eerder over hoe Proxmox van “alternatief” naar standaard is gegroeid en over het verschil tussen back-up en replicatie. Dit artikel gaat een stap verder en duikt in de mechaniek: wat deduplicatie precies doet, waarom verificatie geen optie maar noodzaak is, waarin prune en garbage collection verschillen, hoe één server meerdere klanten kan bedienen zonder dat er iets door elkaar loopt, hoe u één enkel bestand terughaalt zonder de hele machine aan te raken, en wat dat alles betekent voor het ontwerp wanneer de infrastructuur in een private cloud draait met opslag in twee Madrileense zones op meer dan 10 kilometer van elkaar.

PBS is niet “weer een back-uptool”

Proxmox Backup Server is een Linux-distributie op basis van Debian, grotendeels geschreven in Rust en uitgebracht onder de GNU AGPLv3-licentie. Hij is gebouwd voor één taak: gegevens van virtuele machines, containers en fysieke servers opslaan en teruggeven. Versie 4.2, uitgebracht in april 2026, is gebaseerd op Debian 13.4 “Trixie”, Linux-kernel 7.0 en ZFS 2.4, en voegt officiële ondersteuning toe voor S3-compatibele objectopslag als backend, versleuteling in sync-jobs en het gelijktijdig verwerken van meerdere back-upgroepen.

Het praktische verschil met een klassieke dump naar schijf of NAS zit in drie mechanismen die samenwerken: deduplicatie (hoeveel ruimte het kost), verificatie (of het bruikbaar is) en retentie (hoe lang kopieën bewaard blijven en wanneer ruimte echt vrijkomt). Wie die drie begrijpt, dimensioneert goed. Wie dat niet doet, eindigt met een volle repository, kopieën die niemand ooit heeft gecontroleerd en een restore die een experiment wordt.

Deduplicatie: waarom 30 kopieën geen 30 keer de ruimte kosten

PBS slaat geen monolithische back-upbestanden op. Het splitst de gegevens in blokken —chunks van gemiddeld zo’n 4 MiB—, berekent van elk de SHA-256-hash en bewaart het blok precies één keer binnen de datastore. Duikt datzelfde blok morgen opnieuw op, dan noteert de back-up alleen een verwijzing.

Drie gevolgen die u helder moet hebben voordat u iets dimensioneert:

Elke back-up is incrementeel, maar wordt teruggezet als een volledige. Na de eerste kopie voegt elke run alleen nieuwe blokken toe. Bij het terugzetten hoeft geen keten van incrementals te worden gereconstrueerd: elke snapshot staat op zichzelf.
De deduplicatie is globaal binnen de datastore. Ze beperkt zich niet tot één VM: tien machines met hetzelfde besturingssysteem delen het gemeenschappelijke deel één keer. En omdat namespaces binnen dezelfde datastore leven, kunt u omgevingen (productie, acceptatie, klanten) scheiden zonder die besparing te verliezen.
De rekensom “omvang van de VM × aantal kopieën” klopt niet. Het is de som die iedereen in de eerste vergadering maakt, en er komt altijd een absurd getal uit. Het werkelijke verbruik is daar een fractie van, want wat groeit is niet het aantal kopieën maar de hoeveelheid data die ertussen verandert.

Dat laatste punt verandert het gesprek. De nuttige vraag is niet “hoeveel neemt elke back-up in beslag?”, maar “hoeveel data verandert er per dag op dit platform?”. Een transactionele database en een fileserver met documenten die nauwelijks worden aangeraakt kunnen op schijf even groot zijn en totaal verschillende back-upopslag vragen.

Aan de hypervisorkant versnelt één detail het proces aanzienlijk: Proxmox VE gebruikt de dirty bitmaps van QEMU om te weten welke blokken van een VM sinds de vorige kopie zijn gewijzigd, zonder de hele schijf opnieuw te lezen. Die kaart leeft in het geheugen en gaat verloren wanneer de machine wordt afgesloten of gemigreerd; bij de volgende run leest PBS de schijf weer volledig, maar verstuurt en bewaart alleen wat werkelijk nieuw is. Een af en toe tragere back-up na onderhoud is dus geen storing.

Verificatie: corruptie ontdekken zolang het nog niet uitmaakt

Het vervelende aan bit rot is dat het zich niet aankondigt. Een blok kan degraderen op het medium, een hardware- of softwarefout kan al weggeschreven gegevens beschadigen, en er gaat nergens een lampje op rood. De back-up staat gewoon in de lijst, met datum en omvang. Op de dag dat u hem nodig hebt, opent hij niet.

PBS lost dit op met planbare verificatiejobs: ze lezen de opgeslagen blokken opnieuw, herberekenen de hashes en vergelijken die met de originelen. Wat dat oplevert is niet het voorkomen van corruptie, maar het naar voren halen van het moment waarop u haar ontdekt: niet midden in de nacht tijdens een calamiteit, maar op een willekeurige dinsdag, wanneer de goede kopie elders nog bestaat en er ruimte is om te reageren.

Twee operationele details die in grote repositories het verschil maken:

Verificatie kan zo worden ingesteld dat ze al geverifieerde snapshots van de laatste N dagen overslaat, zodat elke ronde zich richt op het nieuwe in plaats van wekelijks de hele repository opnieuw te lezen.
Een snapshot die de verificatie niet doorstaat, wordt gemarkeerd. Zorg dat die markering bij een mens terechtkomt en niet alleen in een logregel: een als defect gemarkeerde en genegeerde back-up is precies even nuttig als geen back-up.

Twee dingen mag u daarbij niet verwarren. Verificatie bewijst dat de blokken intact zijn; ze bewijst niet dat de dienst opstart. Of een database opkomt, de applicatie verbinding maakt en het bedrijf kan doorwerken, bewijst alleen een echte restore. Verificatie is de noodzakelijke voorwaarde; de periodieke hersteltest de voldoende.

Retentie en garbage collection: twee verschillende dingen die iedereen door elkaar haalt

Hier zit het meest voorkomende misverstand rond PBS, en de reden dat repositories vollopen: prune maakt geen ruimte vrij.

Prune past het retentiebeleid toe en bepaalt welke snapshots niet langer nodig zijn. Het verwijdert de verwijzing naar de back-up, maar raakt de blokken niet aan: die zijn gededupliceerd en worden hoogstwaarschijnlijk nog door een andere kopie gebruikt.
Garbage collection (GC) haalt de ruimte terug. Ze loopt de datastore door, markeert de blokken waarnaar nog wordt verwezen en verwijdert de wezen. Daarbij houdt ze een tijdsmarge aan zodat er nooit blokken van een lopende back-up worden gewist — daarom verschijnt de vrijgekomen ruimte niet meteen.

Beide processen worden apart ingepland, en beide móéten ingepland worden. Een omgeving met retentiebeleid maar zonder periodieke GC blijft groeien tot iemand een melding krijgt dat de schijf vol is, meestal in het weekend.

Voor het beleid zelf laat PBS een piramide met meerdere niveaus toe: laatste N, dagelijks, wekelijks, maandelijks en jaarlijks. Een redelijk startpunt voor een productieplatform:

Niveau	Voorbeeld	Waarvoor
Laatste	3 kopieën	Een recente fout terugdraaien (een deployment, een verwijdering)
Dagelijks	7	Terug naar elke dag van de afgelopen week
Wekelijks	4	De maand dekken met weinig herstelpunten
Maandelijks	6-12	Historie en zakelijke eisen
Jaarlijks	1-5	Wettelijke of contractuele verplichtingen, waar die gelden

De verleiding om alles “voor het geval dat” te bewaren is begrijpelijk, maar retentie is geen technische beslissing: het is een zakelijke en, in sommige sectoren, ook een wettelijke. Leg haar schriftelijk vast met wie verantwoordelijk is voor de gegevens, in plaats van haar over te laten aan wie de job configureert.

Versleuteling aan de clientzijde: wat de externe kopie mogelijk maakt

PBS versleutelt aan de clientzijde, op de Proxmox-node zelf, voordat de gegevens het netwerk verlaten, met AES-256-GCM. De back-upserver bewaart informatie die hij niet kan lezen. Dat heeft twee praktische kanten:

U kunt kopieën naar een externe locatie of naar objectopslag sturen zonder dat de bestemming een vertrouwenspunt hoeft te zijn. De data reist versleuteld en blijft versleuteld.
Wie de sleutel kwijtraakt, raakt de back-ups kwijt. Er is geen herstelpad. Behandel de sleutel als een kritiek bedrijfsmiddel: een kopie buiten de omgeving die hij beschermt, een geprinte versie op een veilige plek en een vastgelegde procedure over wie erbij mag.

Eén technisch detail verrast vaak: deduplicatie blijft werken met versleuteling aan, maar alleen tussen back-ups die dezelfde sleutel delen. Een aparte sleutel per klant of per omgeving is een legitieme keuze voor isolatie; weet alleen dat het de ruimtebesparing verkleint, omdat die verzamelingen onderling geen blokken meer delen.

Sinds versie 4.2 kennen ook de sync-jobs versleuteling: push-jobs versleutelen vóór verzending en pull-jobs kunnen extern versleutelde data ontsleutelen, met sleutelbeheer centraal geregeld samen met tape.

De kopie ver genoeg wegbrengen: sync-jobs tussen locaties

Eén repository blijft, hoe goed geverifieerd ook, een single point of failure. PBS regelt de spreiding met sync-jobs tussen servers of datastores: in pull-modus haalt de bestemming op, in push-modus duwt de bron. In beide gevallen reizen alleen de ontbrekende blokken, waardoor een dagelijkse replica tussen locaties ook bij grote volumes prima haalbaar is. Versie 4.2 verwerkt meerdere groepen gelijktijdig, wat vooral opvalt wanneer er latency in het spel is.

Eén PBS voor meerdere klanten: waar namespaces voor dienen

Namespaces zijn hiërarchische onderverdelingen binnen één datastore, en precies het onderdeel dat van een back-upserver een multitenant-platform maakt. Daarmee kan één PBS-instantie meerdere klanten, meerdere bedrijfsonderdelen of meerdere clusters bedienen zonder dat er iets door elkaar loopt.

Isolatie via rechten. Elke namespace heeft eigen ACL’s. Een klant, een partner of een intern team ziet alleen zijn tak van de boom, en API-tokens worden met precies die scope uitgegeven: wat ernaast staat, valt niet te tonen, terug te zetten of te verwijderen.
Eigen beleid. Retentie, verificatie en sync worden per namespace ingesteld. Een klant met zeven dagen en een klant die jaren moet bewaren, leven in dezelfde repository zonder dat de een zijn regels aan de ander oplegt.
Zonder extra opslagkosten. De deduplicatie blijft globaal binnen de datastore, dus klanten scheiden vermenigvuldigt de opslag niet. Versleutelt elke klant met een eigen sleutel, dan is de isolatie sterker maar worden blokken alleen nog binnen elke verzameling gedeeld: dat is de prijs van die scheiding.
Bestemming voor sync-jobs. Een sync-job kan elke externe bron in een specifieke namespace laten landen. Dat is het gebruikelijke patroon wanneer meerdere clusters, vestigingen of klanten samenkomen op één PBS.

Zo werken managed providers en partners die back-up as a service aanbieden: één repository, veel tenants, gescheiden accounts. Met twee eerlijke kanttekeningen. Ten eerste zijn er geen harde quota per namespace: groei stuurt u met het retentiebeleid en met monitoring, niet met een limiet die een uitdijende klant afremt. Ten tweede geldt het vrijmaken van ruimte (GC) voor de hele datastore, dus onderhoudsvensters plant u globaal en niet per klant.

In 4.2 kunnen groepen en namespaces bovendien worden verplaatst, handig wanneer de oorspronkelijke structuur te krap wordt — een klant die groeit, een omgeving die apart moet — en u wilt herordenen zonder back-ups opnieuw te maken.

Back-ups vanuit de machine zelf: proxmox-backup-client en losse bestanden

Tot hier ging het over back-ups van de volledige machine, zoals u die vanuit Proxmox VE start. Maar PBS kan meer: er is proxmox-backup-client, een client die binnen de VM, de container of een fysieke Linux-server wordt geïnstalleerd en precies de mappen back-upt die u opgeeft, met een eigen planning, eigen versleuteling en eigen namespace.

Dat verandert wat u kunt terughalen, en hoe snel:

Eén enkel bestand terughalen — een per ongeluk verwijderde bijlage, een configuratiebestand, de datamap van een applicatie — zonder de hele machine terug te zetten of een parallelle kopie op te starten om er één map uit te vissen.
Specifieke paden met een andere frequentie beschermen. De datamap van een applicatie kan elk uur worden geback-upt terwijl de volledige machineback-up dagelijks blijft.
Servers dekken die niet in dat cluster draaien: fysieke machines, legacysystemen of hosts elders die hun data naar dezelfde repository sturen, met dezelfde versleuteling en dezelfde retentie.

De werkwijze is eenvoudig: client installeren, de repository opgeven en de gekozen paden back-uppen. Die reizen in pxar-formaat en worden net als al het andere gededupliceerd en versleuteld.

proxmox-backup-client backup data.pxar:/var/www 
  --repository backup@pbs@pbs.intern:opslag 
  --ns klant-a

Die archieven kunt u vervolgens tonen of mounten om er alleen uit te halen wat nodig is, zonder de hele set te downloaden.

Zie het als aanvulling, niet als vervanging. De volledige machineback-up brengt de dienst terug na een calamiteit; de client in de machine lost het “ik heb net een bestand gewist” van een willekeurige dinsdagochtend op. Voor VM-back-ups biedt Proxmox VE daarnaast file-level restore vanuit de interface zelf en live restore, waarbij de machine opstart terwijl het terugzetten op de achtergrond doorloopt. Met die drie routes is vrijwel elk reîl incident afgedekt.

Hoe dit landt in een Proxmox private cloud bij Stackscale

Alle theorie hierboven komt neer op één heel concrete vraag: waar leven de blokken? Bij Stackscale bouwen we de back-up van Proxmox-omgevingen op Archive-opslag, bereikbaar via NFS of via een S3-compatibele API, en beschikbaar op fysiek gescheiden locaties: twee zones in Madrid, op meer dan 10 kilometer van elkaar, plus een derde in Amsterdam.

Die afstand is geen brochuredetail. Het is wat twee datacenters buiten hetzelfde fysieke incident houdt — brand, overstroming, een stroomstoring in één gebied — terwijl de latency metropolitaan blijft: laag genoeg om dagelijks, of zelfs meerdere keren per dag, te synchroniseren zonder dat het een probleem wordt. Het is het verschil tussen “we hebben een kopie in een ander rack” en “we hebben een kopie in een andere risicozone”.

Referentiearchitectuur

Laag	Waar	Waarvoor
Primaire datastore	Archive in Madrid, zone A (NFS of S3)	Referentiekopie. Alle back-upjobs schrijven hierheen
Replica	Archive in Madrid, zone B (>10 km) of Amsterdam	Dagelijkse sync-job. Overleven bij verlies van een hele locatie
Snelle laag (optioneel)	All-flash netwerkopslag	Meest recente kopieën, voor frequente restores en lage RTO
Lokale schijf van de PBS-host	Back-upserver	Hooguit tijdelijke buffer. Nooit de enige repository

Het ontwerpprincipe is eenvoudig: de referentiekopie staat altijd op Archive, niet op de schijf van de server die de back-ups maakt. Een lokale repository hangt af van de gezondheid van één specifieke machine en levert geen redundantie; gaat die server verloren in hetzelfde incident als het cluster, dan verdwijnt ook het vermogen om te herstellen. Snelle lagen zijn een cache om restores te versnellen, niet de bron van waarheid.

Met deze opzet is de 3-2-1-regel meer dan een slogan: drie kopieën (productie plus twee repositories), op verschillende media en systemen, met minstens één buiten de primaire locatie. En dat alles met de gegevens in Europese datacenters, iets wat in heel wat sectoren is opgeschoven van technische voorkeur naar contractuele eis.

Een operationele kalender die werkt

Belangrijker dan de architectuur is dat iemand haar levend houdt. Een verstandig startpunt voor een productieplatform:

Taak	Richtfrequentie	Opmerking
Back-up van VM’s en containers	Dagelijks, in een venster met weinig belasting	Met bandbreedtelimieten als het netwerk met productie wordt gedeeld
Sync naar de tweede locatie	Dagelijks, na het back-upvenster	Alleen nieuwe blokken reizen mee
Verificatie	Wekelijks, met overslaan van wat al geverifieerd is	Met een melding aan een mens, niet alleen in het log
Prune	Dagelijks	Past het beleid toe; maakt geen ruimte vrij
Garbage collection	Wekelijks	Dit is wat de ruimte werkelijk terughaalt
Hersteltest	Elk kwartaal, en na belangrijke wijzigingen	Terugzetten én opstarten, niet alleen verifiëren

Zes fouten die steeds terugkomen

Dimensioneren door te vermenigvuldigen. Opslag berekenen als omvang maal aantal kopieën leidt tot onrealistische budgetten en veel te korte retentiekeuzes.
Prune inplannen en GC vergeten. De ruimte komt niet vanzelf terug.
Verificatie verwarren met een hersteltest. Het zijn verschillende controles en de ene vervangt de andere niet.
De encryptiesleutel bewaren in de omgeving die hij beschermt. Neemt het incident het cluster mee, dan neemt het ook de sleutel mee.
Alleen ontwerpen voor de grote ramp. De meeste echte restores gaan over één bestand of één map, niet over een heel datacenter; zonder proxmox-backup-client of file-level restore dwingt elk klein incident tot het opbouwen van een volledige VM.
De enige kopie in hetzelfde gebouw laten staan. Pas een replica op een tweede locatie op kilometers afstand maakt van een back-up een echt plan B.

Veelgestelde vragen

Hoeveel ruimte heb ik echt nodig voor 30 dagen back-ups?

Dat hangt af van hoeveel data er verandert, niet van de totale omvang van de machines. Omdat de deduplicatie globaal is binnen de datastore en back-ups incrementeel zijn, vermenigvuldigt 30 dagen bewaren het verbruik niet met 30: het ligt veel dichter bij de omvang van de eerste kopie plus de opgetelde dagelijkse verandering. Meet de werkelijke veranderingsgraad een paar weken voordat u de dimensionering vastlegt.

Wat is het verschil tussen prune en garbage collection?

Prune past het retentiebeleid toe en haalt snapshots uit de lijst, maar verwijdert geen blokken omdat die meestal met andere kopieën worden gedeeld. Garbage collection zoekt de blokken op waarnaar geen enkele back-up meer verwijst en verwijdert die; pas dan komt ruimte vrij. Allebei moeten worden ingepland.

Als ik back-ups verifieer, moet ik dan nog restores testen?

Ja. Verificatie controleert of de opgeslagen blokken intact zijn; niet of het systeem opstart, of de database consistent is, of de applicatie werkt. Alleen een periodieke hersteltest, waarbij de dienst echt opstart, valideert de hele keten.

Is het veilig om back-ups op een externe locatie te bewaren?

Met versleuteling aan de clientzijde wel: de data wordt met AES-256-GCM versleuteld op de Proxmox-node voordat ze vertrekt, en de bestemming kan haar niet lezen. De keerzijde is het sleutelbeheer: zonder sleutel geen restore, dus bewaar hem buiten de omgeving die hij beschermt.

Waarom is het belangrijk dat de twee zones in Madrid meer dan 10 km uit elkaar liggen?

Omdat dat beide locaties buiten hetzelfde fysieke incident houdt — brand, overstroming, een stroomstoring in één gebied — terwijl de latency metropolitaan blijft. Zo kunt u dagelijks of vaker synchroniseren zonder operationele boete, en voldoet u aan de eisen voor geografische scheiding van een continuïteitsplan zonder Spanje te verlaten.

Kan ik met één Proxmox Backup Server meerdere klanten bedienen?

Ja, met namespaces. Elke klant werkt in zijn eigen tak van de datastore, met eigen rechten, API-tokens, retentie en verificatie, terwijl de deduplicatie globaal blijft en het scheiden dus geen extra opslag kost. Houd er rekening mee dat er geen harde quota per namespace bestaan en dat garbage collection de hele datastore raakt.

Kan ik één bestand terughalen zonder de hele machine terug te zetten?

Ja, op twee manieren. Op een VM-back-up biedt Proxmox VE file-level restore rechtstreeks vanuit de interface. En installeert u proxmox-backup-client in de machine, dan back-upt u de paden die u belangrijk vindt volgens een eigen planning en kunt u ze daarna tonen of mounten om alleen het nodige eruit te halen.

Kort samengevat

Proxmox Backup Server doet het moeilijke deel goed: weinig opslaan, corruptie op tijd opmerken en data snel teruggeven. Wat hij niet voor ons kan beslissen: hoe lang dingen bewaard blijven, waar de tweede kopie staat, wie de sleutels beheert en hoe vaak een echte restore wordt getest. Die vier beslissingen scheiden een back-up die gerust stelt van een back-up die er alleen zo uitziet.

Bij Stackscale ontwerpen we het geheel — Proxmox-cluster, PBS en Archive-opslag op meerdere locaties — als één stuk. Bouwt of herziet u de back-upstrategie van uw Proxmox-omgeving, dan denken we graag mee.