De integratie tussen Veeam Backup & Replication 13.1 en Proxmox VE heeft veel belangstelling gewekt omdat het belooft afbeeldingsback-ups zonder permanente componenten op de knooppunten van de cluster te maken. De details van de interne werking zijn echter bijna niet publiekelijk gedocumenteerd. Na het analyseren van een laboratorium met een Proxmox VE 9 cluster en het observeren van het gedrag tijdens een back-up, is het mogelijk om beter te begrijpen hoe het proces eigenlijk plaatsvindt.
De kernpunten van Veeam-back-up in Proxmox in 20 seconden
- Veeam installeert geen permanente software op de Proxmox knooppunten tijdens de back-up.
- Er wordt gebruikgemaakt van een worker-virtuele machine die automatisch wordt aangemaakt en beheerd.
- De schijf van de beschermde machine wordt geëxporteerd via NBD door QEMU.
- De worker ontvangt die export zonder rechtstreeks toegang te krijgen tot de originele volume.
- Het mechanisme is gebaseerd op native functies van QEMU.
Een van de opvallendste aspecten van deze implementatie is dat de hypervisor vrijwel onaangeroerd blijft. In tegenstelling tot andere virtualisatieplatforms waarbij persistent componenten of specifieke services op de hosts worden ingezet, verscheen tijdens deze test geen extra pakketten van Veeam op de Proxmox-knooppunten en ook geen permanente agents binnen de beschermde virtuele machine.
Het gebruikte laboratorium bestond uit een Proxmox VE 9-cluster met twee knooppunten, een zelfstandige Veeam Backup & Replication 13.1-installatie en een Windows-virtuele machine met een schijf van 40 GB.
De hoofdrolspeler is de worker-virtuele machine
In werkelijkheid voert niet de Proxmox-knooppunt het zware werk uit, maar een virtuele machine genaamd worker.
Tijdens de back-uprun rekt Veeam:
- Automatisch de worker opnieuw in.
- Deze wordt gestart zodra de back-up begint.
- Door middel van QEMU Guest Agent wordt gecontroleerd of het systeem correct is opgestart.
- De back-up wordt uitgevoerd.
- De worker wordt weer uitgeschakeld zodra het proces is voltooid.
Dit verklaart waarom, bij een normale installatie van de Proxmox-plugin, deze workers meestal uitgeschakeld blijven en alleen worden geactiveerd bij back-upproblemen.
Directe communicatie met QEMU
Een andere interessante observatie kwam tijdens het analyseren van de monitor QMP (QEMU Machine Protocol) van de beschermde virtuele machine.
Tijdens de back-up gaf een handmatige aanvraag aan de monitor een timeout. Het functioneerde weer normaal zodra het werk was voltooid.
Dit is enkel een waarneming uit dit specifieke laboratorium en vormt geen door Veeam of Proxmox gedocumenteerde beperking. Toch suggereert het dat tijdens de kopie operatie het beter is om geen administratieve handelingen op de virtuele machine uit te voeren, zoals het handmatig maken van een snapshot of het starten van een live migratie.
De schijf wordt nooit door de worker direct geopend
Het meest interessante onderdeel van de analyse was het inspecteren van de QEMU-processen.
Aanvankelijk leek het logisch dat de worker rechtstreeks toegang zou krijgen tot het opslagvolume van de beschermde machine. Dat gebeurt echter niet.
Tijdens de test:
- Hield het QEMU-proces van de worker geen descriptor open voor het volume van de virtuele machine.
- Was het QEMU van de beschermde VM dat het volume openhield.
- Datzelfde proces startte een NBD-server (Network Block Device) die luisterde op de loopbackinterface.
- De worker-QEMU verbond zich simpelweg met deze NBD-export.
Het vastleggen van het netwerkverkeer tussen deze processen liet zelfs de initiële handshake zien van het protocol, met de manifestaties van de NBDMAGIC– en IHAVEOPT-ketens, die typerend zijn voor het NBD-protocol.
Met andere woorden, de schijf wordt nooit direct door de worker geopend. Wat de worker ontvangt, is een export gemaakt door de QEMU van de virtuele machine zelf, gebruikmakend van de native mechanismen van de hypervisor.
Zo passen snapshots
Deze observatie helpt ook om het gedrag van snapshots beter te begrijpen.
Tijdens de back-up blijven nieuwe schrijfbewerkingen op de virtuele machine plaatsvinden volgens de ingestelde snapshotconfiguratie (ofwel op de eigen LUN of op een externe tijdelijke opslag).
Maar ongeacht die configuratie blijft de worker lezen uit de NBD-export van de QEMU, zonder direct toegang te hebben tot het fysieke volume.
Dit detail maakt duidelijk dat een snapshot niet als een apart volume hoeft te worden gepresenteerd voor de worker om het te kunnen lezen.
Een belangrijk punt voor productieomgevingen
Naast de technische werking is er een belangrijk aandachtspunt voor het gebruik van deze oplossing in bedrijfsomgevingen.
De documentatie van Veeam geeft aan dat toegang tot de Proxmox-hosts vereist dat een account met root-privileges of met verhoogde rechten wordt gebruikt. Heden wordt geen authenticatie via SSH-sleutels of accounts beschermd door MFA ondersteund.
In organisaties met strikte beveiligingsbeleid of strikte controle op administratorrechten, moet dit aspect vooraf worden gepland, omdat het mogelijk specifieke uitzonderingen op het beveiligingsbeleid vereist.
Hoewel Veeam veel van het interne proces abstraheert, laat deze analyse zien dat de aanpak vooral gebruikmaakt van bestaande QEMU-mogelijkheden, zoals de export van schijven via NBD. Dit resulteert in een mechanisme dat geen permanente softwareinstallaties op de hosts vereist en de impact op de hypervisor beperkt door het verwerkingstoezicht te delegeren aan een tijdelijke virtuele machine die automatisch wordt beheerd door het backup-platform.