How to Back Up VMware ESXi Virtual Machines

Backing up VMs on ESXi sounds like it should be a solved problem, and on a licensed vSphere environment it mostly is. The trouble starts on free ESXi, where the most common backup tools simply refuse to connect — and a lot of people don’t find out until their first restore test fails. The license you’re running decides which methods are even available to you.

This guide covers the realistic options: why free ESXi blocks the standard backup interface, how snapshot-based backups actually work, the two free routes that do work (ghettoVCB and OVF export), where third-party tools fit, and the rule that matters more than any tool — a snapshot on the same datastore is not a backup, and a backup that never leaves the host isn’t protection.

Why free ESXi blocks most backup tools#

Commercial backup products talk to ESXi through the vSphere Storage APIs for Data Protection (VADP). VADP lets a backup server read a VM’s virtual disks directly and efficiently, including changed-block tracking so only the changed blocks move after the first run. It’s the backbone of nearly every paid VMware backup tool.

The catch: the free ESXi license disables write access to those APIs. The interface is there, but it’s read-only in a way that prevents backup tools from doing their job, so they fail to register the host or error out when a job starts. This isn’t a bug or a setting you can flip — it’s the licensing line VMware draws between free and paid.

That leaves three workable approaches on free ESXi:

• Snapshot-based scripts that run on the host — ghettoVCB being the well-known one.
• Manual OVF/OVA export of individual VMs.
• Guest-level backup, where an agent inside each VM backs up its own files like any physical machine.

How snapshot-based backups work#

Almost every VM-level backup, free or paid, leans on the same trick. The goal is to copy a disk that isn’t being written to while the VM stays running, and a snapshot makes that possible.

The sequence:

1. The backup creates a temporary snapshot of the VM. From that moment, the original base disk (the VMDK) stops changing — all new writes go into the snapshot delta file.
2. With the base disk now static, the backup process copies it to the backup location.
3. When the copy finishes, the backup deletes the snapshot, which merges the delta (all the writes that happened during the copy) back into the base disk.

The snapshot only exists for as long as the copy takes. ghettoVCB automates exactly this on the host; VADP-based tools do the same thing through the API with changed-block tracking layered on top so they don’t recopy unchanged blocks every time.

Option 1: ghettoVCB for free ESXi#

ghettoVCB is a community shell script that runs directly on the ESXi host and performs snapshot- based backups of running VMs to a local datastore or an NFS share. It’s the de facto answer for free ESXi because it doesn’t need VADP — it does the snapshot/copy/delete dance itself, on the host, as root.

The basic shape of a run: you define which VMs to back up (a list file or all VMs), point it at a backup datastore, and run the script or schedule it with cron on the host.

# Back up a specific list of VMs defined in vm_list, using a config file
./ghettoVCB.sh -f vm_list -g ghettoVCB.conf

# Or back up every VM on the host
./ghettoVCB.sh -a -g ghettoVCB.conf

Key settings live in the config file — where backups go, how many rotations to keep, and the disk format:

VM_BACKUP_VOLUME=/vmfs/volumes/backup-datastore/backups
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=3
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_COMPRESSION=0

It works well, but treat it with the respect anything running as root on a hypervisor deserves:

• It’s unsupported by VMware — community-maintained, no vendor to call.
• It runs as root on the host, so a bad config can affect production VMs.
• Test the restore, not just the backup. A ghettoVCB backup restores by copying the VM folder back and re-registering it; confirm that path works before you rely on it.

Option 2: Manual OVF / OVA export#

OVF (and its single-file cousin OVA) is a portable, full-copy export of a VM. It’s a clean way to grab a complete, self-contained copy of a VM that you can move to another host or keep as an archive. The usual tool is OVF Tool from a workstation, or the export option in the ESXi web client.

# Export a VM to OVF using ovftool (run from a management workstation)
ovftool "vi://root@esxi-host/MyVM" "C:\backups\MyVM\MyVM.ovf"

Where OVF export fits:

• Templates and golden images you want to keep outside the datastore.
• A safety copy before a major change — an OS upgrade, an application migration.
• Moving a VM between environments, including out of VMware entirely. OVF is a common starting point when people migrate VMware VMs to Proxmox.

Where it falls short: the VM usually needs to be powered off for a clean export, the process is manual and slow, and there’s no incremental option. It’s a backup method for occasional full copies, not a nightly job for running production VMs.

Option 3: Third-party and guest-level backup#

If the host runs a paid vSphere license, the commercial tools become an option, and they’re worth it for anything beyond a couple of VMs. VADP-based products give you incremental backups with changed-block tracking, application-aware processing for things like databases, and centralized scheduling and restore — including granular file-level recovery from an image backup. Several vendors offer a free tier that covers a handful of VMs, which can be enough for a small shop, as long as the host isn’t on the free ESXi license.

The other route that works on any license is guest-level backup: install a normal backup agent inside each VM and back it up like a physical server. You lose the host-level conveniences — no single image of the whole VM, no capturing the VM’s configuration, more agents to manage — but it sidesteps the VADP restriction entirely and gives you application-aware, file-level backups inside the guest. For a small number of important VMs on free ESXi, it’s a perfectly sound approach.

Why snapshots aren’t backups#

This is the misconception that costs people their data, so it’s worth stating plainly: a snapshot is not a backup. A snapshot is a point-in-time delta that lives on the same datastore as the VM and depends on the original base disk to mean anything. If the datastore fails, the host dies, or ransomware encrypts the volume, the snapshot is gone right alongside the VM it was supposed to protect.

Snapshots also degrade the VM the longer they live. Every write goes into a growing delta file, which consumes datastore space and slows the VM down. A pile of old snapshots is a common cause of a full datastore and a stunned VM.

What snapshots are actually for: a short-term rollback point during a risky change — a patch, a driver update, an application install. Take it, do the work, confirm everything’s fine, then delete it. The full reasoning, including the failure modes that catch people out, is in the guide on why VMware snapshots are not backups.

Get a copy offsite#

A backup that lives on the same host, or even the same site, as the original isn’t protecting you against the failures that matter most — a dead host, a fire, a flood, or ransomware that reaches every reachable share. The standard worth following is 3-2-1: at least three copies of the data, on two different types of media, with one copy offsite.

For ESXi, that usually means: the running VM (copy one), a local backup on a separate NAS or datastore (copy two), and a third copy pulled offsite — another building, a colocation rack, or cloud object storage. The mechanism matters less than the separation. The goal is that no single event can destroy both the VM and the only backup of it.

Pick the method that fits your license#

The honest decision tree for ESXi backups is short:

• Free ESXi, a few VMs: ghettoVCB for scheduled host-level backups, or guest-level agents inside the important VMs. OVF export for the occasional full archive.
• Free ESXi, you want supported tooling: the cleanest fix is often to move up to a paid vSphere Essentials tier, or to migrate to a platform with built-in backup — Proxmox VE includes native VM backup, which is one reason teams move from VMware to Proxmox.
• Paid vSphere: a VADP-based backup product, with changed-block tracking and app-aware jobs, plus an offsite copy.

Whatever you choose, the two non-negotiables are the same: get a copy off the host, and test a real restore on a schedule. A backup you’ve never restored is a guess, not a safety net.

Wrapping up#

ESXi backups come down to your license first and your tooling second. Free ESXi closes the door on VADP, so you lean on ghettoVCB, OVF export, or guest-level agents; a paid license opens up the commercial tools and their incremental, app-aware jobs. Across all of them, the same two rules decide whether you’re actually protected: snapshots are not backups, and a backup that never leaves the host isn’t a backup either.

Start by confirming the license, pick the method that fits, get a copy offsite, and test the restore. For more on snapshot behavior and moving workloads off VMware, see the virtualization guides.