Proxmox backupstrategieën: snapshots, vzdump en Proxmox Backup Server

Eerst het antwoord: de strategie in drie lagen

Voor een Proxmox-host die ertoe doet, is dit de werkende strategie:

1. Snapshots voor het komende uur: maak er een voor risicovolle wijzigingen (upgrades, ingrepen in de configuratie), rol terug als het misgaat, verwijder hem daarna. Snapshots leven op de opslag van de VM: ze beschermen tegen je eigen fouten, niet tegen de host zelf.
2. Geplande vzdump-backups voor de komende maand: backups in snapshot-modus volgens een schema, met bewaarregels, naar opslag die niet dezelfde schijven zijn waar de VM's op draaien.
3. Proxmox Backup Server zodra de aantallen groeien: gededupliceerde, incrementele, versleutelde, geverifieerde backups naar een tweede machine, offsite gesynchroniseerd. Hier worden dagelijkse backups met volledige geschiedenis van elke guest betaalbaar genoeg om ook echt te doen.

En de regel die dit alles van schijnveiligheid in echte bescherming verandert: een backup zonder restore is een hypothese. Plan restoretests zoals je de backups plant.

Snapshots zijn geen backups

Belangrijk om precies vast te leggen, want de GUI plaatst "Snapshot" verleidelijk dicht bij "Backup". Een VM-snapshot bevriest een moment in de tijd op dezelfde opslag waar de VM op leeft: sterft de opslag, dan sterft de snapshot mee. Langlevende snapshots tasten bovendien de prestaties aan en compliceren de opslag naarmate de deltas zich opstapelen.

Waar snapshots uitstekend voor zijn, is precies waar backups te traag voor zijn: een directe undo-knop rond een risicovolle wijziging. Maak er een, doe het gevaarlijke ding, bevestig, verwijder de snapshot. Minuten tot uren levensduur: het advies uit onze Debian-upgradegids om "eerst je rollbackplan te bepalen", concreet gemaakt in één klik. (RAID is, voor de volledigheid, geen van beide: dat is beschikbaarheid, een derde zaak.)

Laag 2: vzdump, goed ingericht

vzdump is de ingebouwde backupengine van Proxmox: het produceert een compleet, op zichzelf staand archief van een guest, herstelbaar op elke Proxmox-host. Het verschil tussen "we draaien vzdump" en een echte strategie zit in vier instellingen.

Modus: snapshot, met de guest agent

Gebruik snapshot-modus voor routineschema's: het maakt backups van draaiende guests met hooguit een korte hapering. De consistentie hangt af van één ding dat mensen overslaan: de QEMU guest agent in elke VM (het pakket qemu-guest-agent, plus het vinkje bij de VM-opties). Daarmee bevriest vzdump de bestandssystemen van de guest (fs-freeze/fs-thaw) op het moment van opname, zodat het archief een crash-consistent (of beter) image bevat in plaats van een inconsistente. Reserveer stop-modus voor de guests waar de zekerheid van een koude kopie de geplande downtime waard is, en voor databases blijft extra zekerheid de moeite waard: een dump op applicatieniveau (pg_dump, enzovoort) volgens een schema binnen de guest kost weinig en maakt restores mogelijk op manieren die een disk image niet kan.

Schema en bewaartermijn

Configureer dit onder Datacenter → Backup: welke guests, wanneer (nachtelijk, gespreid als de opslag gedeeld is), en (het onderdeel dat zowel dataverlies als volle schijven voorkomt) de bewaartermijn. Proxmox ruimt op volgens regels: keep-daily=7, keep-weekly=4, keep-monthly=6 geeft je bijvoorbeeld een maand aan dagelijkse granulariteit en een staart van twee seizoenen, automatisch opgeruimd. Elke bewaarregel is beter dan de twee standaarden die mensen in de praktijk draaien: "bewaar alles tot de schijf vol zit" en "bewaar er 1".

Doel: niet dezelfde schijven

Een backup op de opslag die hij beschermt, is een snapshot met extra stappen. Minimaal haalbaar doel: elke opslag die onafhankelijk kan uitvallen, een tweede lokale array, NFS elders, of (laag 3) een PBS-datastore op een andere machine.

Fleecing: voor trage doelen

Als backups naar een traag doel (NFS over een dunne verbinding, een druk bezette HDD-array) guests traag maken, komt dat doordat de schrijfacties van de guest wachten op het backupdoel. Fleecing (--fleecing enabled=1,storage=local-lvm) buffert oude blokken in plaats daarvan op snelle lokale opslag, waardoor de I/O van de guest wordt losgekoppeld van de snelheid van het doel: een onopvallende functie die de meest voorkomende klacht "backups vertragen productie" oplost.

Laag 3: Proxmox Backup Server

De beperking van vzdump is rekenkundig: elke backup is een volledig archief, dus dagelijkse backups van een VM van 200 GB kosten 200 GB per dag, en de meeste van die bytes zijn dag na dag identiek. Proxmox Backup Server (een gratis open-source begeleidend product dat je op een tweede machine installeert) verandert die rekensom:

• Deduplicatie + incrementele overdracht. Data wordt opgeslagen als content-addressed chunks; ongewijzigde chunks worden één keer opgeslagen, en van draaiende VM's wordt incrementeel een backup gemaakt met QEMU dirty bitmaps: alleen blokken die sinds de laatste backup zijn beschreven, worden überhaupt gelezen, laat staan verzonden. Praktisch effect: na de eerste backup kosten nachtelijke backups van grote VM's enkele minuten en gigabytes, niet honderden daarvan. (Containers krijgen hun eigen versneller: de wijzigingsdetectiemodus metadata slaat ongewijzigde bestanden over door ze te vergelijken met de metadata van de vorige snapshot.)
• Hoeveel bespaart dedup? Proxmox publiceert eerlijk gezegd geen officiële ratio. Het hangt af van hoe diep je bewaartermijn gaat en hoe vergelijkbaar je guests zijn. Community-rapportages komen doorgaans uit op een factor van 5–12× bij dagelijkse backups en een verstandige bewaartermijn; een ratio rond 1× betekent meestal gewoon dat de bewaartermijn op één snapshot staat.
• Verificatie tegen bitrot. Geplande verify jobs herberekenen de checksums van opgeslagen chunks, zodat stille opslagcorruptie wordt ontdekt voordat de restore plaatsvindt waarvoor de data nodig was. Dit is PBS's stille killerfunctie: koude archieven rotten onzichtbaar weg; geverifieerde archieven niet.
• Encryptie aan de clientzijde (AES-256-GCM): backups worden versleuteld voordat ze de PVE-host verlaten, zodat de PBS-machine (of de S3-bucket erachter) nooit platte tekst bevat. Bewaak de sleutel goed; PBS ondersteunt een op papier afdrukbare hoofdsleutel voor noodgevallen.
• Offsite sync. Sync jobs repliceren datastores tussen PBS-instanties (push of pull, alleen delta's). Een tweede PBS op een andere locatie maakt van de opzet een echte 3-2-1. Sinds PBS 4.2 is S3-compatibele objectopslag een officieel ondersteunde datastore-backend, waardoor "offsite kopie in een bucket" ook een volwaardige optie is.
• Restore-ergonomie: restore van losse bestanden (pluk één bestand uit een VM-image-backup via de GUI) en live-restore (start een VM direct op vanaf de backup terwijl die terugstreamt, RTO in minuten voor de ongeduldigen).

De implementatievorm op dedicated servers is eenvoudig: PBS wil zijn eigen machine (backups op de hypervisor beschermen niets), met een zwaar op capaciteit ingerichte opslagconfiguratie (qua RAID: raidz2/RAID 6-territorium) en een pijp die dik genoeg is om restorevensters acceptabel te houden (de rekensom uit de sizing-gids voor het restorevenster geldt hier ook: 4 TB over 1 Gbit/s is ~9 uur; bij 10 Gbit/s wordt dat minder dan een uur). PVE-hosts krijgen vervolgens elke nacht een Datacenter → Backup-taak gericht op de PBS-datastore, PBS draait prune + garbage collection + wekelijkse verify, en (als de data het rechtvaardigt) stuurt een sync job data naar een tweede locatie.

Hoe zit het met replicatie en Ceph?

Twee verwante functies worden aangezien voor backups. ZFS-replicatie (pvesr) kopieert guest-volumes volgens een schema naar een andere node (tot wel elke minuut), uitstekend voor snelle failover met lokale opslag, maar het repliceert elke verwijdering en elke corruptie trouw mee, binnen enkele minuten; het is beschikbaarheid, geen geschiedenis. Ceph is vergelijkbaar: zelfherstellende, gerepliceerde opslag die je door ransomware versleutelde blokken met foutloze redundantie bewaart. Beide werken samen met backups (ze dekken het scenario "de node is uitgevallen"; backups dekken het scenario "we hebben afgelopen dinsdag nodig"). Geen van beide vervangt ze. Meer over allebei in de cluster- en HA-gids.

De restore-oefening

Minimaal elk kwartaal: restore één VM naar een tijdelijke VMID (qmrestore of via de GUI, restore-as-new: het overschrijft het origineel niet), start hem op, bevestig dat de applicatie ook echt werkt, verwijder hem weer. Twintig minuten die "we hebben backups" omzetten in "we hebben restores". Terwijl je toch bezig bent: neem de tijd op. Verrast de timing je, dan is dat beter nu dan tijdens een incident: dan ontdek je of live-restore, meer bandbreedte, of een fijnmaziger bewaartermijn de moeite van het configureren waard is.

Veelgestelde vragen

Zijn backups in snapshot-modus van een draaiende database veilig?

Veilig, met ruimte voor verbetering. Doordat de guest agent bestandssystemen bevriest op het moment van opname, is de image consistent op bestandssysteemniveau, en moderne databases (PostgreSQL, MySQL/InnoDB) herstellen daar probleemloos van: het komt neer op herstel na een stroomstoring, waar ze voor ontworpen zijn. Wat een disk image je niet geeft, is de vrijheid om naar een specifiek moment terug te gaan of eenvoudig een gedeeltelijke restore te doen, dus voeg voor databases die ertoe doen applicatieniveau-dumps of WAL-archivering toe binnen de guest. De combinatie (image-backups voor herstel van het hele systeem, dumps voor chirurgisch precies herstel) is het verstandige antwoord.

Hoe vaak moet ik een backup maken?

Werk terug vanaf de vraag "hoeveel werk kunnen we ons veroorloven te verliezen?" Dat is je backupinterval. Een nachtelijke backup is de standaard ondergrens voor gewone guests; dankzij het incrementele kostenmodel van PBS is meerdere keren per dag voor drukke databases ruim betaalbaar (en pvesr-replicatie kan de kloof in beschikbaarheid daarnaast verkleinen tot een minuut). Wat net zo zwaar weegt: de bewaartermijn. Corruptie en ransomware worden vaak pas dagen later ontdekt. Een strategie met slechts drie nachtelijke backups kan de schade in elke kopie laten doorwerken voordat iemand het merkt.

Kan PBS ook een backup maken van dingen die geen Proxmox-guests zijn?

Ja: de proxmox-backup-client draait op elke Linux-host en stuurt backups op bestandsniveau naar dezelfde gededupliceerde, versleutelde, geverifieerde datastores. Als je toch al PBS draait, is het een logische plek voor de configuratie en data van je niet-gevirtualiseerde machines: één backupinfrastructuur, één bewaarbeleid, één plek om restores te testen.

Beschermt dit tegen ransomware?

Het is het grootste deel van het antwoord, met twee voorwaarden. Eerst scheiding: een PBS die alleen bereikbaar is via zijn API met eigen inloggegevens, is niet versleutelbaar door een gecompromitteerde guest, maar backups op een NFS-share die de hypervisor read-write mount, zijn dat wel. Ten tweede geschiedenis en sync: een bewaartermijn die diep genoeg teruggaat om achter de besmetting te komen, verify jobs zodat je weet dat de chunks intact zijn, en een offsite sync (tweede PBS of S3) die een enkele gecompromitteerde locatie niet kan bereiken. De encryptie aan de clientzijde van PBS beschermt je backups tegen de opslag; scheiding van toegang beschermt ze tegen de aanvaller.

Uitrollen op Serverside

De voor de hand liggende PBS-inzet hier is een tweede dedicated server: een zwaar op capaciteit ingerichte opslagconfiguratie, op het private netwerk met je Proxmox-hosts zodat het nachtelijke backupverkeer nooit je publieke bandbreedte raakt, in een ander faaldomein dan de host die hij beschermt. Provisioning binnen een minuut op ASN 55285, en dezelfde Proxmox-ready images overal.

De rest van de serie: eerste installatie, netwerken, LXC versus VM's, en (waar replicatie en failover de taak van backups overnemen) clustering en hoge beschikbaarheid.