ghettoVCB Not Working? Common Errors and Fixes

ghettoVCB usually works on the first try, but when it does not, the failure can feel confusing, because the cause is often not the script itself. It is a wrong path, a VM with a leftover snapshot, a cron job that vanished after a reboot, or a configuration value that means something different than you assumed. This guide walks through the most common ghettoVCB problems in the order you are likely to meet them, with a clear fix for each. Work through the symptoms in order, read the actual output, and you will solve most issues without reinstalling anything.

Before you dive into fixes, run two baseline checks. First, run the script in dry run mode against one VM you know exists, and read the output. Second, confirm the backup destination exists and has free space. Those two checks eliminate the simplest causes. If either one fails, fix that first. Deeper troubleshooting on top of a broken path or a full datastore only wastes time and creates new confusion.

Problem: Script Not Found or Permission Denied

If the shell says the script is not found, you are in the wrong directory or you used a relative path. ghettoVCB commands must use full paths, in cron and by hand, so type the complete path to the script, such as /opt/ghettovcb/bin/ghettoVCB.sh for a VIB install, or the real path where you extracted the archive. If the shell says permission denied, the script is not executable. Run chmod +x on the script file with its full path and try again. Both errors are path problems, and both are fixed by typing the exact path and checking the executable bit.

Do not work around a missing script by downloading a fresh copy from an unfamiliar site. Get the script only from the official project repository, and keep your known-good copy in a stable location on a datastore. A backup script that runs as root deserves a trusted source and a stable home, and moving it between temporary folders is how path problems start.

Problem: VM Skipped or Not Found

If the script reports that a VM was not found, the display name is almost always the cause. The name must match the inventory exactly, including spaces and capitalization. List the VMs, copy the exact name, and compare it character by character with the name in your command or list file. A list file with a misspelled name silently backs up nothing for that VM, and the log is the only place that says so. Read the log after every run, and treat a missing VM as a name problem until proven otherwise.

If a VM is skipped rather than missing, check for an existing snapshot. By default, ghettoVCB skips VMs that already have snapshots, because ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP is off. A leftover snapshot from a failed run is the usual cause. Consolidate the snapshot from the client, find out why the previous run left it behind, and only then run the backup again. Do not turn the setting on to work around a leftover snapshot, because that hides the real problem and stacks new snapshots on old ones.

Problem: Script Stops Mid-Backup

A backup that stops halfway, with no clear error, often traces back to output handling. The project documents a known issue where output that is not redirected can fill a buffer and stop the script. The fix is simple and absolute: always redirect output to a log file, on every run, manual or scheduled. If a run stopped without a log, re-run it with a redirect and read the log from the start. The log usually names the step where the run stopped, and that step points at the real cause, whether it is space, a snapshot error, or a destination problem.

Also check the destination free space when a run stops mid-copy. A full backup datastore stalls a copy without a dramatic error, and the script may report the failure in terms that sound like a VM problem. Check space first, because it is the fastest check and the most common cause on a host where rotation has not kept up with growth. If space is the cause, fix rotation and destination size before you re-run, or the next run will stop in the same place.

Problem: Power-Down Backup Waits Forever

A power-down backup that never progresses is usually a VMware Tools problem. The shutdown mode assumes Tools is installed in the guest, and without Tools the script waits for a shutdown that never happens, until the timeout settings give up. Confirm Tools is installed and that a manual shutdown from the client works for that VM. If Tools is missing, install it, or switch that VM back to a snapshot backup without power-down. The timeout settings ITER_TO_WAIT_SHUTDOWN and POWER_DOWN_TIMEOUT control how long the script waits, in iterations of 60 seconds, but lengthening the wait does not fix a guest that cannot shut down. Fix the guest, not the timeout.

Check the shutdown and startup order settings too when several VMs are involved. A VM that depends on another VM may shut down in the wrong order and hang waiting for a service that is already gone. Test power-down backups on a quiet evening with one VM at a time, and only then apply them to a set. A power-down backup is the most consistent kind, and it is also the kind with the most moving parts, so it earns the most testing.

Problem: Cron Job Never Runs or Vanishes

A backup that works by hand but never runs on schedule is usually a cron problem, and cron on ESXi has a specific trap. Crontab changes do not persist across reboots unless they are saved through /etc/rc.local.d/local.sh or the VIB persistence method. If the schedule worked, then stopped after a patching reboot, check the crontab first. If the line is gone, restore it through the persistence method and document the method, so the next reboot does not repeat the loss. Also check that the cron line uses full paths everywhere, because a relative path that works in your shell fails at midnight.

Remember that ESXi hosts usually run on UTC. A job that seems to run at the wrong time is often running exactly on time in host time. Check the host clock, convert your intended window, and adjust the cron time. And if a scheduled run produces no log file at all, the job did not run. Treat a missing log as an emergency: it means the job did not run. Investigate the cron setup before the next scheduled run.

Problem: Email Alerts Never Arrive

Email alerts that never arrive usually mean the firewall or the mail settings, not the backup. Email needs the ESXi firewall email rule opened for outbound port 25, followed by esxcli network firewall refresh. Check the rule, check the server, port, sender, and recipient values in the configuration, and test with a real backup run. If the mail server rejects the message, the rejection may only appear in the mail server’s logs, so check there too. Until an alert has actually arrived in your inbox, do not rely on email as your only check. Read the backup logs directly, on a weekly rhythm, regardless of alerts.

A Simple Troubleshooting Checklist

Dry run succeeds against one known VM, with the exact display name
Full paths are used for the script, list file, config file, and log file
Output is redirected to a log file on every run, and the log is read afterwards
The VM has no leftover snapshot, and the destination has free space
Power-down backups are used only where VMware Tools is confirmed working
The cron line persists across reboots and uses host time correctly
Configuration edits use Unix line endings, one change at a time, with a backup copy

Work through that list in order on every failure, and you will find the cause faster than by trying random fixes. Most ghettoVCB problems are solved by the third or fourth item. Keep the exact output in your notes when you ask for help, along with the command you ran and the configuration values involved. An exact message gets an exact answer, and a vague description gets guesses. Keep logs and backup folders private, because they can contain VM names and configuration details.

Conclusion

Most ghettoVCB failures are not mysterious. They are a wrong path, a misspelled VM name, a leftover snapshot, a full datastore, a missing Tools install, or a cron job that did not survive a reboot. Check the dry run, check the paths, check the log, check the snapshot state, and check the schedule, in that order, and test one change at a time. With that routine, ghettoVCB goes back to being the quiet, reliable script it is meant to be.