Når hypervisoren skifter, holder de backupjobs, der tager kopier gennem VMware’s grænseflade, op med at virke for de maskiner, der flytter. Backupværktøjet skal enten understøtte den nye platform eller udskiftes, og gendannelse på den nye platform skal være testet, før de gamle jobs og kopier lægges væk.
Om værktøjerne gengiver vi, hvad producenterne selv skrev 8. november 2026. Ingen af dem er prøvet her.
Hvad der holder op med at virke
Et backupværktøj til VMware tager typisk kopier på hypervisorniveau: det beder vCenter om et øjebliksbillede og læser diskene derfra. Når maskinen flytter til en anden platform, findes den ikke længere i vCenter. Jobbet fejler eller tager kopi af ingenting.
Fire ting skal derfor ses efter:
- Jobbene. Hvert job, der peger på en VMware-maskine, skal erstattes af et job på den nye platform.
- Gendannelse af ældre kopier. Kopier taget på VMware kan måske kun gendannes til VMware. Spørg producenten, om de kan gendannes på den nye platform, og hvordan.
- Opbevaringstid. Har I krav om at gemme kopier i en bestemt tid, skal de gamle kopier kunne læses i hele perioden, også efter VMware er slukket.
- Programmer i maskinerne. Backup af databaser og e-mail inde i maskinerne kan fortsætte uændret, hvis den sker med agenter i styresystemet. Det skal tjekkes.
Hvad de store værktøjer understøtter
I version 13 af Veeam Backup & Replication står der pr. november 2026 en lang række platforme ud over vSphere. Blandt dem er Hyper-V, AHV, Proxmox VE, XCP-ng, Citrix XenServer, oVirt KVM, HPE Morpheus VM Essentials, Scale Computing HyperCore og Sangfor aSV, plus en kategori for øvrige hypervisorer. Platforme bygget på KubeVirt, herunder OpenShift Virtualization, har ikke deres eget punkt. Hver platform har egen udvidelse eller vejledning, og Proxmox-delen installeres som en særskilt maskine. Versioner pr. platform og forskelle i funktioner har vi ikke læst. Listen er læst gennem et resumé af Veeams navigation, og den skal tjekkes i Veeams dokumentation for jeres version.
Andre værktøjer har vi ikke gennemgået for understøttelse af hypervisorer. Et eksempel er Bareos, der har åben kode under AGPLv3, og hvor selskabet bag sælger abonnementer. Hvilke hypervisorer det understøtter, har vi ikke læst. Hvem der ejer de store backupproducenter, står i hvem ejer backupsoftwaren.
Det, platformene selv har
Nogle platforme har backup indbygget eller som eget produkt:
- Proxmox VE har sit eget backupprodukt, Proxmox Backup Server, med krypterede kopier, hvor kun ændringer gemmes, og ifølge dokumentationen kan det også skrive til bånd.
- Harvester har indbygget backup af virtuelle maskiner til NFS, S3 eller NAS.
- Xen Orchestra til XCP-ng har backup indbygget som en del af værktøjet.
- Kubernetes og KubeVirt bruger værktøjer til backup af Kubernetes, fx Velero og Kanister. Kanister er et projekt i CNCF, oprindeligt lavet af et team hos Veeam.
Indbygget backup er nemt at sætte op. Den deler til gengæld skæbne med platformen. Går I væk fra platformen igen, følger backuppen ikke med. Det er en overvejelse, ingen regel, og backup-løsningen binder også beskriver den fra exit-planens side.
Det, der skal testes først
Ingen producent har en liste over, hvad der skal testes efter et skifte. Det følgende er sitets egen metode.
- Gendannelse af en hel maskine på den nye platform fra en ny kopi. Mål tiden.
- Gendannelse af en enkelt fil fra en maskine. Mange gendannelser i hverdagen er enkelte filer.
- Gendannelse af en database til et bestemt tidspunkt, hvis I har databaser med logbackup.
- Gendannelse af en gammel kopi fra VMware-tiden, hvis den skal kunne bruges.
- Kopien uden for platformen. Kan kopien læses, hvis platformen er væk? Hvor ligger den, og hvem har adgang?
- Uforanderlighed. Er kopierne beskyttet mod sletning og kryptering, som de var før? Se uforanderlig backup.
Skriv tiderne ned, og sammenhold dem med de krav, I har til gendannelse. Hvis tiden er længere end før, er det en oplysning til ledelsen, før de gamle jobs slukkes.
Rækkefølgen i skiftet
Sæt backup op på den nye platform, før den første produktionsmaskine flytter. Lad jobbene på VMware køre, indtil den sidste maskine er flyttet og testet. Gem de gamle kopier i den tid, kravene siger, og hold dem læsbare. Først derefter slukkes den gamle backup.
Hvad det kræver, og hvad det koster at lade være
Arbejdet kræver tid til at læse backupproducentens understøttelse, sætte jobs op og teste gendannelse. Mange databaser trækker tiden ud fra dage mod uger. Hvis værktøjet skal udskiftes, kommer licens, opsætning og uddannelse oveni.
At lade være betyder, at maskiner kan køre på den nye platform uden virksomme kopier, indtil nogen opdager det. Det er den situation, hvor et nedbrud koster mest, fordi intet kan gendannes. Testen giver noget, selv om intet går galt: dokumentation for, at gendannelse virker, og tider, der kan bruges i beredskabet.
Det skal I lade være med
- At flytte maskiner før backuppen virker på den nye platform · ellers står de uden kopi.
- At slukke den gamle backup før sidste test · de gamle kopier kan være de eneste.
- At regne med, at gamle kopier kan gendannes overalt · spørg producenten.
Det skal valget kunne vise
- ☐ Backupværktøjets understøttelse af den nye platform, læst for jeres version.
- ☐ Plan for gamle kopier og deres opbevaringstid.
- ☐ Resultater af de seks test med tider.
- ☐ Kopi uden for platformen, med sted og adgang.
- ☐ Datoen, hvor den gamle backup slukkes, og hvem der godkender det.
Kilder
- Veeam Help Center, VBR 13 User Guide, platform support, og Veeam Backup for Proxmox VE, læst 8. november 2026 (resumé og indholdsfortegnelse).
- Proxmox, Proxmox Backup Server overview og dokumentation, læst 8. november 2026.
- Harvester docs v1.6, læst 8. november 2026.
- Bareos, bareos.com, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find jeres backupværktøjs liste over understøttede platforme for jeres version, og læg den ved siden af den platform, I overvejer.
Læs også: Gendannelse fra cloud · 3-2-1-1-0
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
