How to Restore ESX 4 VM

— ny_wk

To restore an ESX 4 VM from a ghettoVCB backup, you SSH into the host, edit a plain-text restore_list file that maps each backup folder to a target datastore and disk format, then run ./ghettoVCB-restore.sh -c restore_list and let the script re-register the virtual machine. This guide walks through the full ghettoVCB restore workflow, the disk-format choices, the pitfalls that quietly break a restore, and how to verify the VM is genuinely healthy afterward.

Note up front: VMware ESX/ESXi 4.x reached end of general support years ago and should not run production workloads today. The procedure below is documented faithfully for anyone maintaining a legacy host, an isolated lab, or migrating off old infrastructure. The modern equivalents on supported releases are covered near the end.

The Problem: Recovering a VM When There Is No vCenter Backup Product

On small ESX 4 deployments there was rarely a commercial backup tool. Administrators leaned on ghettoVCB — a free, community shell script written by William Lam that snapshots a running VM, copies its VMDK files to a backup datastore, then removes the snapshot. It is reliable and lightweight, but it only solves half the problem. When a guest is deleted, corrupted, or a datastore dies, you need the matching companion script, ghettoVCB-restore.sh, to turn that backup folder back into a bootable, registered virtual machine.

The restore is not a drag-and-drop operation. ghettoVCB stores each backup as a timestamped directory containing the VMX configuration and one or more VMDK disks. The restore script reads a configuration file you supply, copies those disks to a live datastore in the disk format you specify, fixes up the VMX, and registers the result with the host so it appears in the vSphere/VI Client. Getting the restore_list syntax exactly right is the whole game.

Prerequisites Before You Restore an ESX 4 VM

• A completed ghettoVCB backup already exists for the target VM — the backup script must have run successfully against the source server beforehand.
• SSH access to the ESX/ESXi host (PuTTY on Windows, or any terminal). On ESX 4 classic you may need to enable SSH for root in the service console firewall; on ESXi 4 enable the SSH service in the security profile.
• The ghettoVCB-restore.sh script present on the host and marked executable.
• Enough free space on the destination datastore to hold the restored disks (thick formats need the full provisioned size).
• The exact path to the backup, including the timestamped sub-folder.

Step-by-Step: Restore an ESX 4 VM with ghettoVCB-restore.sh

1. Log in to the host. Open PuTTY and connect to the ESX 4 server as root over SSH.
2. Go to the backup location. Change into the directory that holds your VM backups, for example: cd /vmfs/volumes/VSBASE-SAN-BK-9/vmbackup The volume name and path will differ per host, so confirm yours with ls /vmfs/volumes/ first.
3. Find the backup folder. Each VM has its own directory, and inside it one timestamped folder per backup run, e.g. test1/test1-2010-04-13--1. Verify it contains a .vmx file and the .vmdk disks before continuing.
4. Open or create the restore_list file. Edit it with vi restore_list. Each line describes one VM to restore using three semicolon-separated fields: <backup_dir_or_tgz>;<datastore_to_restore_to>;<disk_format>
5. Add the line for your VM. Point at the timestamped backup folder, choose a live datastore, and pick a disk format. For a VM named test1: /vmfs/volumes/VSBASE-SAN-BK-9/vmbackup/test1/test1-2010-04-13--1;/vmfs/volumes/Storage1-9;1 Here 1 means restore the disk as zeroedthick (see the format table below). Save and exit (:wq in vi).
6. Run the restore. Execute the script against your config file: ./ghettoVCB-restore.sh -c restore_list The -c flag tells the script which restore-list file to read. The script copies the disks, rewrites the VMX, and registers the VM.
7. Watch for the completion banner. A successful run prints a clear summary, for example: ################## Completed restore for test1! ##################### followed by the start time, end time, and duration (a small VM typically finishes in a couple of minutes).
8. Confirm the VM appears. The restored guest is registered automatically and shows up in the VI / vSphere Client inventory without any manual Add to Inventory step.

Understanding the Disk-Format Field

The third field in each restore_list line controls how ghettoVCB-restore.sh provisions the VMDK on the destination datastore. Choosing the wrong value either wastes space or fails on a datastore that does not support that format.

If you are unsure, thin (2) is the most forgiving for a recovery on a busy datastore, while zeroedthick (1) mirrors typical production provisioning. Always make sure the destination has room: an eagerzeroedthick restore writes the entire provisioned size immediately.

Restoring Multiple VMs or from a .TGZ Archive

The restore_list file can hold one line per VM, so a single run can recover several guests in sequence — handy after a datastore loss. The first field also accepts a compressed .tgz archive if your backups were stored that way, not just an uncompressed folder. Keep each entry on its own line and double-check the destination datastore for every one; mixing up two similarly named volumes is the most common cause of a misplaced restore.

Common Pitfalls When You Restore an ESX 4 VM

• Wrong or partial path. Pointing at the VM folder instead of the timestamped backup sub-folder is the number-one mistake. The path must end at the dated directory (or the .tgz), not the parent.
• Trailing spaces or smart quotes. If you pasted the line from a web page or document, hidden whitespace and curly quotes break parsing. Retype the semicolons and quotes by hand in vi.
• Script not executable. A Permission denied error means you must run chmod +x ghettoVCB-restore.sh first.
• Insufficient datastore space. Thick formats fail mid-copy if the target volume cannot hold the full provisioned size. Check with df -h or vdf -h before starting.
• Name collision. Restoring a VM whose name or folder already exists on the destination can clash. Restore to a clean datastore folder, or remove the stale copy first.
• SSH disabled. If PuTTY cannot connect, SSH is likely turned off in the host firewall/security profile — enable it before you begin.
• Network/MAC conflicts after power-on. If you restore a copy while the original still exists, you can get duplicate MAC addresses or IP conflicts. Power on only one instance.

Verification: Confirm the Restore Actually Worked

The completion banner only proves the files copied — it does not prove the VM is healthy. Verify properly:

1. Check the inventory. Confirm the VM is listed in the VI/vSphere Client and shows the expected datastore in its settings.
2. Inspect the files. From the host, ls -lh /vmfs/volumes/Storage1-9/test1 should show the VMX and a VMDK whose size matches the original.
3. Power it on. Boot the VM and watch the console. If you cloned rather than recovered, answer the I Copied It prompt so the host regenerates the UUID and avoids identity clashes.
4. Log in to the guest. Confirm the OS boots, services start, and recent data is present up to the backup timestamp.
5. Reconfigure networking if needed. Reattach the correct port group and verify the IP, especially if the restore landed on a different host or VLAN.
6. Review the script output. Re-read the run log for any non-fatal warnings about specific disks before you trust the VM.

The Modern Equivalent on Supported vSphere Releases

If you have moved past ESX 4, the same recovery concepts apply with newer, supported tooling:

• ghettoVCB still exists and is maintained for modern ESXi; the restore syntax is conceptually identical, but always use the version matching your host.
• OVF/OVA export and deploy via the vSphere Client or ovftool gives you a portable, supported backup-and-restore path for individual VMs.
• Snapshot-based backup products (Veeam, Nakivo, Veaam-style agentless tools) use the vStorage APIs for Data Protection (VADP) for application-consistent backups and granular restores.
• VM templates and clones in vCenter handle rapid re-provisioning of known-good guests.

The discipline that makes any of these work is the same one ghettoVCB taught: test your restores, not just your backups. A backup you have never restored is only a hopeful guess.

Key Takeaways

• A working ghettoVCB backup must exist first; the restore only rebuilds what was already captured.
• Drive the recovery with a restore_list file using the format backup_path;target_datastore;disk_format, then run ./ghettoVCB-restore.sh -c restore_list.
• Disk-format codes are 1 = zeroedthick, 2 = thin, 3 = eagerzeroedthick — match them to your space and feature needs.
• Most failed restores trace back to a wrong path, hidden whitespace/smart quotes, missing execute bit, or insufficient datastore space.
• Always verify by booting the guest, answering I Copied It if needed, and confirming data and networking — never trust the completion banner alone.

Frequently Asked Questions

What does ghettoVCB-restore.sh actually do during a restore?

It reads your restore_list, copies the backed-up VMDK disks to the target datastore in the requested format, rewrites the VMX configuration, and registers the VM with the host so it appears in the client inventory automatically — no manual add step required.

What is the correct restore_list syntax?

One line per VM with three semicolon-separated fields: the full path to the timestamped backup folder (or .tgz), the destination datastore path, and the disk-format code. Example: /vmfs/volumes/.../test1/test1-2010-04-13--1;/vmfs/volumes/Storage1-9;1.

Why does my restored VM ask whether I moved or copied it?

When a VM with the same identity is brought back, the host detects a potential UUID conflict and prompts at first power-on. Choose I Copied It to generate a fresh UUID and MAC if the original may still exist, or I Moved It to keep them if it does not.

Is ESX 4 safe to use today?

No — ESX/ESXi 4.x is end-of-life and unpatched, so keep it off the production network. Use this procedure only for legacy maintenance, lab work, or migrating data onto a supported vSphere release, then move to a current backup tool.

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