Schedule ghettoVCB Backups with Cron on ESXi

A backup that depends on you remembering to run it will fail on the week you are busiest, which is exactly the week you will need it. Scheduling turns ghettoVCB from a command you run into a routine the host runs, whether you are watching or not. On ESXi, scheduling means cron, and cron on ESXi has quirks that will quietly undo your schedule if you do not know them. This guide shows you a working cron setup, the persistence trick that keeps it alive across reboots, and the testing habit that proves the schedule actually ran.

Before you schedule anything, prove the manual command works. Run a dry run, then a real backup of one VM, and read the log. Scheduling a command that has never succeeded by hand only automates the failure. You also need the full paths to the script, the VM list file, the configuration file, and the log file written down, because cron jobs on ESXi must use full paths. A cron job that works in your interactive shell because your current directory happens to be right will fail at midnight when the working directory is different.

A Cron Line That Works

A typical schedule runs the backup at midnight, Monday through Friday. The cron line from the project docs looks like this: 0 0 * * 1-5 /path/ghettoVCB.sh -f /path/backuplist > /path/ghettoVCB-backup-$(date +\%s).log, with every path replaced by your real paths. Read it piece by piece. The first two fields set the time to midnight. The next fields set every day of the month and every month. The 1-5 limits the run to Monday through Friday. Then comes the full path to the script, the list file option, and a redirect that writes output to a log file whose name includes the current time in seconds, so each run gets its own log instead of overwriting the last one.

The output redirect is not decoration. The project notes a known issue where output that is not redirected can fill a buffer and stop the script mid-backup. Redirecting to a log file avoids that problem and gives you the record you need to check the run. Always redirect, in cron and by hand. Also note the escaped percent sign in the date command inside the cron line. Cron treats an unescaped percent sign specially, so the backslash matters. Copy the pattern carefully, and test the line before you trust it.

Make the Schedule Survive a Reboot

Here is the quirk that catches almost everyone. ESXi cron runs in the BusyBox shell, and changes you make to the crontab do not persist across a reboot. Edit the crontab, reboot the host for patching, and your backup schedule is gone, silently. The fix is to persist the change through the host’s startup script. The documented approach is to edit /etc/rc.local.d/local.sh so that, at boot, it stops the cron daemon, appends your crontab line to /var/spool/cron/crontabs/root, and restarts the daemon. The VIB install also provides a supported persistence method, so check the project docs for the method that matches your install.

Whichever persistence method you use, treat it as part of the backup system and document it. Write down where the cron line lives, how it is restored at boot, and when you last verified it. After every host reboot, patching cycle, or ESXi upgrade, check that the cron job is still present and that the next scheduled run actually happens. A schedule that survived six months and died in the last patch cycle is the most common way a ghettoVCB setup quietly stops protecting VMs.

Watch the Timezone

ESXi hosts tend to run on UTC, and your cron schedule runs on host time, not on the time shown on your laptop. A job you think runs at midnight local time may actually run in the middle of your working day if the host clock is UTC and you are hours ahead. Check the host time from the shell before you set the schedule, and convert your intended local time to host time. Then pick a window when the VMs are quietest. Snapshots briefly stun VMs and add I/O load, so the small hours of the night, in host time, are usually right. Write the intended window down in both times, so the next person reading the cron line is not confused.

Daylight saving changes add another wrinkle. If your local timezone shifts during the year and the host stays on UTC, the effective local time of the backup shifts too. That is rarely a problem for a nightly job, but it is worth knowing when you compare a backup timestamp with an incident that happened in local time. Logs record host time, so keep that in mind when you reconstruct what happened.

Test the Schedule Like a Real Run

Installing a cron line is not testing it. After you add the schedule, watch its first run. Stay up for it, or check first thing the next morning, and read the whole log. Confirm the final status line, confirm the backup files appeared, and confirm the snapshots are gone. Then check the second run too, because the first run can succeed while the second fails on rotation or space. Two clean scheduled runs in a row is a reasonable definition of a working schedule. One run is a good start, not proof.

Set a calendar reminder to review the backup logs weekly, even if email alerts are configured. Email alerts help, but they depend on the firewall rule for outbound port 25 and on a mail server that accepts the messages, and any of those links can break. A weekly five-minute log review catches silent failures that no alert ever reported. If a scheduled run ever produces no log file at all, treat that as an emergency, because it means the job did not run, and the VMs have no backup from that night.

Schedule Habits That Keep Backups Honest

Use full paths for the script, list file, config file, and log file in every cron line
Redirect output to a dated log file on every run, without exception
Persist the crontab through local.sh or the VIB method, and re-check after every reboot
Convert your intended backup window to host time, remembering the host usually runs UTC
Watch the first two scheduled runs end to end, and review logs weekly after that
Keep the VM list file and the configuration file under the same change discipline as the schedule

Those habits are the difference between a schedule and a hope. Cron will run whatever line you give it, on time, forever, including a line with a typo that backs up nothing. The checking habit is what makes the automation trustworthy, and it costs less time than one manual backup a week.

Conclusion

Scheduling ghettoVCB with cron means a full-path command, a dated log redirect, a midnight weekday window in host time, and a persistence method that survives reboots. Test the first two runs, review logs weekly, and re-check the schedule after every patch cycle. A backup routine that runs itself and proves itself in its logs is the routine that will still be there on the night you need it.

How to Schedule ghettoVCB Backups with Cron on ESXi