01

What is Our Specialization?

Defining the specialization and why it matters.

VM Backup &
Hypervisor Backup

Our specialization in the VIRCL project. Two layers of protection, implemented on Proxmox VE and compared with VMware.

TeamMoshe Sarkis Marios & Christophe Thill
ClassBTS Cloud Computing
SchoolLycée Guillaume Kroll
TeachersChristian Rodesch & Maurizio Spagnuolo
DateJune 2026
Press → to enter the world · F for fullscreen
VIRCL — Server Virtualization Systems

Project Overview

Deploy two Type-1 hypervisors across four physical servers. Create virtual machines, integrate remote storage, specialize in VM Backup & Hypervisor Backup at both layers, and compare the two platforms head-to-head.

HP01
Proxmox VE 9.1.1
10.0.10.11
HP03
Proxmox VE 9.1.1
10.0.10.31
CLOIF2 NAS
OpenMediaVault
10.0.13.1
HP02
VMware ESXi
10.0.10.21
HP04
VMware ESXi
10.0.10.41
Moshe Sarkis Marios Proxmox Specialist
HypervisorProxmox VE 9.1.1
ServersHP01 + HP03
iLO192.168.0.1 / 192.168.0.3
FocusProxmox
Christophe Thill VMware Specialist
HypervisorVMware ESXi / vSphere
ServersHP02 + HP04
iLO192.168.0.2 / 192.168.0.4
FocusVMware
School Infrastructure — 10.0.10.0/16 | iLO Management — 192.168.0.0/24

Entering the infrastructure…

01 — What is Our Specialization? & Why It Matters

Two layers. One backup strategy.

VM Layer The workload — VMs, disks, config
BACKUP
Hypervisor Layer The platform — host, network, storage

What is a VM backup?

A VM backup captures the entire virtual machine at a point in time: disks, configuration, and optionally RAM. If the VM is corrupted, infected, or accidentally deleted, the backup is the only way back.

What is a hypervisor backup?

While the VM backup protects the workload, the hypervisor backup protects the platform: cluster configuration, network bridges, storage definitions, users, and permissions.

Why this matters

Every business runs on virtualized infrastructure. Ransomware, hardware failure, and human error are not hypothetical — they are daily events. A backup strategy is not optional.

RPO & RTO: the two numbers that define your risk

RPO — Recovery Point Objective How much data can you lose?

If your last backup was 24 hours ago, your RPO is 24 hours. Every transaction in that window is gone.

7 DAYS
0h24h7d
RTO — Recovery Time Objective How long can you stay down?

A full VM restore takes minutes. Rebuilding a hypervisor from scratch takes hours or days.

2 hrs REBUILD TIME
5 min1 hr2+ hrs
02 — Two Layers & Technical Deep Dive

Two different failures.
Two different backups.

VM Backup — Full Machine State

A VM backup is not a file copy. It captures the entire machine state: disk blocks, OS configuration, installed applications, and optionally live RAM. When restored, the VM boots exactly as it was — no reinstallation, no reconfiguration, no patching gaps.

Hypervisor Backup — The Infrastructure Blueprint

A hypervisor backup captures the platform topology: network bridges, storage mappings, virtual switches, resource pools, and access controls. It is the blueprint that tells the infrastructure how to host the VMs. Without it, you have the machines but nowhere to run them.

Three backup modes. One trade-off: downtime vs consistency.

No downtime

Snapshot

QEMU live snapshot — the VM keeps running while the backup is taken.

Consistency: crash-consistent
Use for: production VMs

Seconds of pause

Suspend

The VM is paused, backed up, then resumed — a short freeze for a cleaner state.

Consistency: better
Use for: sensitive applications

Minutes of downtime

Stop

Full shutdown, backup, restart — nothing changes on disk during the backup.

Consistency: full
Use for: maintenance windows

VM backup modes trade-off: downtime vs consistency

A snapshot is not a backup.

A snapshot is a delta disk that depends on the base disk. When the storage underneath dies, the snapshot dies with it. Real backups live on separate storage.

3·2·1

Three copies of the data, on two different media, one off-site. Ours live on the CLOIF2 NAS.

03 — Proxmox vs VMware

The verdict.

Two approaches. One goal.

Proxmox VE integrates backup directly into the hypervisor. VMware vSphere relies on third-party tools from the ecosystem. Both protect VMs and hosts, but the path, cost, and control differ.

Proxmox VMware
ProxmoxVMwareBetter
VM backup toolvzdump, built in3rd party (Veeam, …)Proxmox
Backup formatVMA + ZSTDVMDK + VMXTie
Hypervisor configtar /etc/pve, CLI onlyvCenter backup, GUIVMware
Enterprise optionPBS, freeVeeam, ≈ $400+ / socket / yearProxmox

Proxmox: backup is built in.

01

GUI backup

vzdump ships with the hypervisor — snapshot mode, ZSTD, straight from the web UI.

02

CLI backup

The same engine scripted: vzdump 100 --mode snapshot --compress zstd

03

Custom script

My bash wrapper adds logging to /var/log/vm_backup.log for an audit trail.

04

Scheduled, to the NAS

Weekly job to the CLOIF2 NAS over NFS, retention: keep last 3 — no human required.

VMware: backup is an ecosystem.

  • +CBT + VADP: mature APIs built exactly for incremental backups
  • +vCenter config backup is built in and can be scheduled
  • +Huge tool ecosystem: Veeam, Rubrik, Cohesity
  • −No native VM backup tool: third-party software required
  • −And it is paid — licensing decides what you get
04 — Live Demo & Problem-Solving

Now live: backup, restore, and the fix.

01

GUI backup

VM → Backup → Backup now: snapshot mode, ZSTD, target: NAS storage.

02

CLI backup

vzdump 100 --mode snapshot --compress zstd — same engine, scriptable.

32 GB→2.86 GB one VM, one compressed archive
03

Backup script

My bash wrapper with logging to /var/log/vm_backup.log.

04

Restore

qmrestore backup.vma.zst 200 — the proof the backup actually works.

05

Hypervisor config

tar -czf hp01-config.tar.gz /etc/pve … — the second layer, 15 KB that saves a rebuild.

# back up a running VM, no downtime
root@HP01:~# vzdump 100 --mode snapshot --compress zstd
INFO: starting backup of VM 100
INFO: backup mode: snapshot
INFO: vzdump-qemu-100-…vma.zst (2.86 GB)
INFO: backup finished successfully

# restore to a new VM id — the real test
root@HP01:~# qmrestore vzdump-qemu-100-….vma.zst 200
restore vma archive … progress 100% OK

# back up the hypervisor config
root@HP01:~# tar -czf hp01-config.tar.gz \
  /etc/pve /etc/network/interfaces /etc/hosts …
hp01-config-20260608.tar.gz (15 KB)
Proxmox GUI backup dialog
GUI · vzdump
Backup completed
Result · 2.86 GB

What went wrong: the NFS problem

The problem

"Read-only file system"

Adding the NFS share to Proxmox failed — backups could not be written to the NAS at all.

The fix

rw, no_root_squash

The OpenMediaVault export was read-only. Changed the NFS share options to rw,no_root_squash, remounted, and verified with a test write.

The lesson

Never trust an unwritten target

Verify export options on both ends before relying on a backup target — and test a restore, not just the backup job.

05 — Takeaways

Six things to remember.

01

A snapshot is not a backup.

It depends on the base disk — when the storage dies, the snapshot dies too.

02

Always two layers.

Back up the VMs and the hypervisor config — one without the other protects nothing.

03

Snapshot mode for production.

Zero downtime; keep suspend and stop for maintenance windows.

04

Separate storage, 3-2-1.

Three copies, two media, one off-site — mine live on the CLOIF2 NAS.

05

A backup only counts once tested.

Every backup here was verified with qmrestore — restore is the real proof.

06

Never trust an unwritten target.

Verify export options on both ends before relying on a backup target.

Questions?

We are happy to answer.

TeamMoshe Sarkis Marios & Christophe Thill
SpecializationVM Backup & Hypervisor Backup
ProgramBTS Cloud Computing
SchoolLycée Guillaume Kroll, Luxembourg
TeachersChristian Rodesch & Maurizio Spagnuolo
VIRCL
01 / 22
←→ navigate · F fullscreen