VM backup methods: agentless vs. inside the guest

In short

There are two ways to back up a virtual machine. Agentless backups run the backup app once, on the host or next to it, and back up whole VMs through Hyper-V, VMware vSphere or Proxmox VE. In-guest backups install the backup app inside each VM and treat it like any other computer. Agentless is usually the better default for whole-VM protection and fast recovery. In-guest makes sense when you need file-level or application-level backups, or when the hypervisor can't see the data.

How it works

Agentless: back up VMs from the hypervisor

The backup app talks to the hypervisor and backs up each selected VM as a whole: its configuration and its virtual disks. Nothing is installed inside the guests.

Changed block tracking (CBT) and the other modes

Changed block tracking means the hypervisor keeps track of which disk blocks changed since the last backup, so the backup app only reads those blocks. Backups are much faster and put less load on the host and the network.

• Hyper-V, Latest VM state (Changed Block Tracking): takes a temporary checkpoint, reads the disk from it, and asks Hyper-V which sectors changed since the last backup, so unchanged data is reused. This is the one to pick on Windows Server 2016 or Windows 10 and later.
• Hyper-V, Latest VM state (Standard): works the same way, but without the change tracking, so it reads the whole disk each time.
• Hyper-V, All VM snapshots: uses VSS and backs up the current disks plus every existing Hyper-V checkpoint (AVHDX files). It only works on Windows Server. Use it if you need the checkpoints themselves.
• VMware, Latest VM state (Changed Block Tracking): the recommended mode. CBT must be turned on for each VM. The backup falls back to reading the full disk when more than half of the disk has changed, or when the disk size or change tracking ID has changed.
• VMware, Latest VM state (Standard): reads the full disk each time.
• Proxmox: CBT is the default. You can also choose a full backup. For containers, you choose how they're isolated during the backup: Snapshot (the default), Stop or Suspended.

Both "Latest VM state" modes store each VM as one flat disk image per backup, so you don't need the checkpoint chain to restore.

In-guest: the backup app inside the VM

Here you install the backup app inside each VM, the same as on a physical machine. Then you pick whatever Protected Items make sense for that guest: File and Folder, Disk Image, or an application such as Microsoft SQL Server. Each VM shows up as its own device in the Web Portal.

Restore options

Agentless backups give you the most recovery choices:

• Restore a whole VM straight back into Hyper-V, VMware or Proxmox, including onto a different hypervisor type than the one it came from.
• Restore the virtual disk files (for example VHDX or .img) to import by hand.
• Granular restore: pull individual files out of a VM backup without restoring the whole machine.

Disk Image backups taken by the app inside a guest (or on a physical machine) can also be restored into a new Hyper-V or VMware VM. That's useful for moving a physical server to a VM.

What this means for you

Pick agentless when:

• You want to protect whole VMs and bring them back fast after a host failure.
• The client has many VMs on one host or cluster, and you'd rather manage one backup app than one per guest.
• You want to be able to restore a VM onto a different hypervisor later.

Pick the app inside the guest when:

• You need application-aware backups of something running in the guest, such as SQL Server, or you only need certain folders.
• The VM uses Hyper-V pass-through disks. Hyper-V can't back these up from the host, so install the app inside the guest to cover that data, or convert the pass-through disks to VHDX.
• The hypervisor isn't one of the supported ones, or you don't have the host access agentless backups need.

Use both when you want whole-VM recovery plus file-level or database backups of a key server. For example, back up the VM agentlessly and run SQL Server backups from inside the guest.

Watch-outs:

• VMware: turn on CBT for each VM before the first backup, or every backup reads the full disk. Independent disks aren't backed up, and the app needs a vSphere role with the right privileges (see VMware vSphere).
• Hyper-V consistency: with Hyper-V integration services installed in the guest, backups are application-consistent (a production checkpoint). Without them, they're crash-consistent. Backups taken on a Hyper-V Replica host are always crash-consistent.
• Restored disk size: "Latest VM state" restores are thick-provisioned, so each disk takes its full size on the destination. Make sure the target has room.
• Billing: each guest VM you back up is billed at the per-VM rate for its platform, whichever method you use. Installing the backup app inside a VM doesn't add a Server or Workstation license charge. See "How it's billed" below.
• Quotas: you can cap how many Hyper-V guests, VMware guests, Proxmox VMs and Proxmox containers a user can protect. These quotas are on the user's Profile tab in the Web Portal. See Set storage and usage quotas.

Not sure which fits a client's setup? Email support@magnusbox.com and we'll talk it through.

How it's billed

Each guest VM (or Proxmox container) you back up is billed on its own, at the per-VM rate for its platform (VMware, Hyper-V or Proxmox). That's the same whichever method you use:

• Installing the backup app inside a VM doesn't add a Server or Workstation license charge.
• The Disk Image add-on doesn't apply to VMs.

For current per-VM pricing, contact support@magnusbox.com. To see what each client is using, see License Usage.

Related tasks

• Microsoft Hyper-V
• VMware vSphere
• Proxmox VE
• Disk Image - Walkthrough
• Best Practices
• Supported platforms and system requirements
• Set storage and usage quotas