How to backup Vmware ESX VM using Script

— ny_wk

To backup a VMware ESXi VM with a script, place the free ghettoVCB.sh tool and a plain-text VM list on a datastore, set your backup destination inside the config, then run ./ghettoVCB.sh -f vmlist over SSH as root. This guide walks through a reliable, repeatable VMware ESXi backup workflow using ghettoVCB, including the exact commands, the common pitfalls that silently skip machines, and how to verify your backups actually restore.

ghettoVCB is the long-standing, community-maintained shell script for hot-backing-up running virtual machines directly on an ESXi host — no vCenter license, no third-party agent, and no extra hardware required. It snapshots each VM, clones the disks to a target datastore, then deletes the snapshot, so guests stay online during the copy. That makes it ideal for labs, small businesses, and any environment where commercial backup software is overkill.

The problem ghettoVCB solves

Out of the box, ESXi gives you no built-in, scheduled, file-level VM backup. The vSphere APIs that commercial tools (Veeam, Nakivo, Veeam Agent) hook into require a paid edition. If you are running the free ESXi hypervisor or a small cluster, you still need a dependable way to copy whole VMs to a second datastore, a NAS, or removable storage so you can recover from a failed disk, a botched patch, or ransomware.

The classic answer in many shops — including the legacy setup this guide is based on, where backups landed in /vmfs/volumes/VSBASE-SAN-BK-8/vmbackup — is ghettoVCB. It produces a self-contained copy of each VM (the .vmx, the -flat.vmdk disks, and metadata) that you can register and power on directly, with no proprietary backup format to unpack.

A note on “ESX” vs “ESXi” (legacy vs modern)

The original procedure referenced the classic VMware ESX hypervisor (the version with the heavyweight Linux “Service Console”). ESX is end-of-life — VMware replaced it with the thin ESXi architecture, and even older ESXi releases have reached end of general support. Everything below targets modern ESXi (6.x / 7.x / 8.x), which is what you should be running. The ghettoVCB commands are nearly identical; the main differences are that you enable SSH from the host UI and use the ESXi shell rather than the old Service Console.

Before you start: prerequisites

• Root SSH access to the ESXi host (enable SSH from the DCUI or the host client under Host → Actions → Services).
• A backup destination datastore with enough free space for full VM copies — ideally on different physical storage (a separate SAN LUN, a NAS via NFS, or an external drive).
• The ghettoVCB script (download the latest from the official GitHub project, lamw/ghettoVCB, or install the VIB/offline bundle).
• A short maintenance awareness window — backups are hot, but disk I/O rises while disks clone.

Critical caveat: the destination must be a different datastore from where the live VMs run. Backing a VM up onto the same disk it lives on gives you zero protection against a disk failure and wastes space.

Step-by-step: backup a VMware ESXi VM with the script

This is the core VMware ESXi backup sequence. Run everything as root in the ESXi shell.

1. Connect over SSH as root. From your workstation:
   ssh root@esxi-host-ip
2. Go to your backup working directory. Datastores live under /vmfs/volumes/. Pick the folder that holds your script and where backups will be organised:
   cd /vmfs/volumes/VSBASE-SAN-BK-8/vmbackup
   Two key files live here: ghettoVCB.sh (the backup engine) and vmlist (the list of VMs to back up). Keep the original ghettoVCB-restore.sh alongside them for recoveries.
3. Confirm the backup destination in the config. Open the script (or, better, a separate config file) and check the destination variable points at the right datastore:
   vi ghettoVCB.sh
   Look for VM_BACKUP_VOLUME and make sure it reads something like /vmfs/volumes/VSBASE-SAN-BK-8/vmbackup. This must already be set correctly before you run anything.
4. Build the VM list. Edit the plain-text list, one VM name per line:
   vi vmlist
   Enter the exact display name of every VM on this host you want backed up. To temporarily skip a machine, prefix its line with # (a comment), e.g. #test-server-01. Save and quit (:wq).
5. Dry-run first. Always validate before a real run — it confirms names resolve and destinations are reachable without copying a byte:
   ./ghettoVCB.sh -f vmlist -d dryrun
6. Run the backup. When the dry run is clean, execute the real backup of every VM in the list:
   ./ghettoVCB.sh -f vmlist
   ghettoVCB snapshots each VM, clones its disks to the destination, then removes the snapshot. Output streams to the console (and to a log if configured).

To back up a single VM without editing the list, use -m:
./ghettoVCB.sh -m my-vm-name

Important behavior and naming gotchas

Two real-world quirks trip people up, and both come straight from production experience.

1. Duplicate datastore names force different paths

vCenter will not let two datastores share a name, but standalone ESXi hosts can. When a host already has a datastore called, say, VSBASE-SAN-BK-8, a second host’s equivalent might be mounted as MSA60-VSBASE-2-BK. Your cd path therefore changes depending on which host you are on. Never assume the path — list the volumes first:
ls /vmfs/volumes/

2. VMs with existing snapshots are skipped

If a VM already has a snapshot when ghettoVCB runs, the script skips that VM and moves to the next one. This is by design — backing up a machine on top of an existing snapshot risks an inconsistent copy. It also means a forgotten snapshot from a previous patch window can quietly leave a critical server unbacked-up. Always check for and consolidate stale snapshots before a run.

Common pitfalls (and how to avoid them)

• Wrong destination datastore. If VM_BACKUP_VOLUME points at the same store the VMs run on, you have no real protection. Verify it every time you reuse a script.
• Editing vi on Windows-saved files. If you uploaded vmlist from Windows, stray carriage returns (\r) can break name matching. Recreate the file on the host or strip CRs with sed -i 's/\r$//' vmlist.
• Out of space mid-clone. A full VM copy needs as much room as the provisioned disks. Check free space first: df -h | grep vmbackup.
• Silent snapshot skips. As above — a pre-existing snapshot means no backup. Read the run output; do not assume “no error” means “backed up.”
• SSH disabled. ESXi turns SSH off by default and may warn it is enabled. Enable it only for the maintenance window, or run ghettoVCB from a cron job on the host.
• No retention limit. Without VM_BACKUP_ROTATION_COUNT, old backups pile up and fill the destination. Set it (e.g. keep the last 3) in the config.

Verification: prove the backup actually works

A backup you have never tested is a hope, not a recovery plan. Verify on three levels.

1. Check the files exist and are complete. In the destination, each VM gets a timestamped folder containing the .vmx and the full -flat.vmdk files:
   ls -lah /vmfs/volumes/VSBASE-SAN-BK-8/vmbackup/my-vm-name/
2. Read the log for a success line. ghettoVCB writes a per-run status; confirm it reports Final status: All VMs backed up (or notes exactly which were skipped) rather than errors.
3. Do a real test restore. The only true verification is bringing a backup back to life on a non-production host:
   ./ghettoVCB-restore.sh -c restore_list -l restore.log
   Then register the restored .vmx in the host client and power it on to confirm the guest boots and the data is intact.

Scheduling automated VMware ESXi backups

Manual runs are fine for one-offs, but real protection is automatic. ESXi runs a cut-down BusyBox cron. To schedule a nightly run, add a line to /var/spool/cron/crontabs/root (note: ESXi resets this on reboot unless you persist it via /etc/rc.local.d/local.sh):

0 2 * * * /vmfs/volumes/VSBASE-SAN-BK-8/vmbackup/ghettoVCB.sh -f /vmfs/volumes/VSBASE-SAN-BK-8/vmbackup/vmlist > /vmfs/volumes/VSBASE-SAN-BK-8/vmbackup/last_run.log 2>&1

This kicks off a full backup of every listed VM at 2:00 AM and captures the output. For long-term integrity, combine on-host backups with an off-site copy (rsync the backup datastore to a remote NAS) so a single-site disaster cannot take out both your VMs and their backups — the classic 3-2-1 rule: three copies, two media types, one off-site.

Quick command reference

Key Takeaways

• ghettoVCB gives free, agentless hot backups of running ESXi VMs — no vCenter or paid edition needed.
• The core workflow is edit vmlist, confirm the destination, then ./ghettoVCB.sh -f vmlist over root SSH.
• A VM with an existing snapshot is silently skipped — always clear stale snapshots and read the run log.
• Datastore paths differ per host because standalone ESXi allows duplicate names — verify with ls /vmfs/volumes/, never assume.
• A backup is only real once test-restored; pair on-host copies with an off-site sync for the 3-2-1 rule.

Frequently Asked Questions

Is ghettoVCB free and is it safe for production?

Yes. ghettoVCB is a free, open-source community script (project lamw/ghettoVCB) that uses VMware’s own supported snapshot and clone mechanisms. Many small and mid-size shops rely on it in production. It is not officially supported by VMware, so always test restores and keep an off-site copy.

Can ghettoVCB back up VMs while they are running?

Yes — that is its main strength. It takes a VMware snapshot, clones the now-static base disks to the destination, then deletes the snapshot, so the guest stays powered on the whole time. For databases or transactional apps, use the guest-quiescing option for an application-consistent copy.

Why did ghettoVCB skip one of my virtual machines?

The two most common reasons are an existing snapshot on that VM (ghettoVCB deliberately skips it) or a name mismatch between vmlist and the VM’s actual display name. Check the log, remove old snapshots, and confirm exact names.

How do I restore a VM from a ghettoVCB backup?

Use ghettoVCB-restore.sh with a restore-config file pointing at the backup folder and a target datastore, then register the restored .vmx in the host client and power it on. The backup is a standard VM, so you can also manually copy it back and register it.

For more hands-on system administration and VMware walkthroughs, subscribe on YouTube: @explorenystream.