Back Up a VM with ghettoVCB: First Backup Guide

Your first ghettoVCB backup should be small, slow, and boring. One virtual machine, one destination, and your full attention on the output. Resist the urge to back up everything on the host in the first hour. A single VM teaches you the whole workflow: how the script finds the VM, what a snapshot does, where the files land, and what a successful log looks like. Once that one backup works and you have checked the files, repeating it for the rest of your VMs is just more of the same.

This guide assumes ghettoVCB is already installed and you have SSH access as root. It also assumes you have a backup destination with enough free space for a full copy of the test VM. Pick a non-critical VM for the first run, ideally a small one. If something goes wrong, you want the lesson to be cheap. Read the whole guide once before you type anything, then run the commands in order.

Start With a Dry Run

Every first backup should start as a dry run. A dry run walks through the whole process, checks the VM and the configuration, and reports what it would do, without copying any files. Run the script with the dry run option and the display name of your test VM: ghettoVCB.sh -m TestVM -d dryrun, using the full path to the script and the exact display name of your VM as it appears in the inventory. Display names matter here, and they must match exactly, including spaces and capitalization. If the script cannot find the VM, the name is the first thing to check.

A successful dry run reports “Final status: OK, only a dryrun” in its output. Read the lines before that final status too. They tell you which VM was found, which datastore it lives on, and where the backup would go. If any of those details look wrong, stop and fix the configuration or the command before you run a real backup. A dry run is free, and it catches the mistakes that are expensive when files start copying.

Back Up a Single VM

When the dry run looks right, run the real thing for the same VM. Drop the dry run option and keep everything else the same: ghettoVCB.sh -m TestVM, again with the full script path. The script takes a snapshot of the running VM, copies the VMDK files and the related VM files to the backup destination, and then deletes the snapshot. On a small VM this takes minutes. On a large VM it can take much longer, and the time depends on the size of the disks, the speed of the destination storage, and how busy the host is. Do not interrupt a running backup because it looks slow. Let it finish, and use the time to watch the log output.

Always redirect the output when you run the script by hand, and always do it when you automate. The project notes a known issue where output that is not redirected can fill a buffer and stop the script mid-backup. A simple redirect to a log file, such as appending > /path/ghettoVCB-backup.log to your command with a real log path, avoids the problem entirely and leaves you a record you can read later. Treat the log as part of the backup, not as an optional extra.

Check What Was Backed Up

When the script finishes, read the final status line first. A successful run reports “Final status: All VMs backed up OK!”. If you see that line, the script believes the backup completed. Then verify it yourself, because a status line is a claim, not proof. Browse to the backup destination and look for a folder named after the VM, containing the VMDK files, the VMX file, and the other VM files. Compare the sizes roughly with the originals, allowing for the disk format you chose. A backup folder that is empty, tiny, or missing the VMX file is not a backup, whatever the log says.

Also check that the snapshot is gone. In the client, the VM should show no snapshot after a successful run. A leftover snapshot means the run did not finish cleanly, even if files were copied. Consolidate it, find out why it was left behind, and fix the cause before the next run. The next run will skip a VM that still has a snapshot, by default, so a leftover snapshot quietly turns into a missing backup the following night.

Back Up From a List, or Back Up Everything

Once one VM works, you will want more. The list option lets you name the VMs to back up, one display name per line, in a plain text file, and run the script against that file: ghettoVCB.sh -f /path/backuplist. The file is easy to maintain, and it is the option most people settle on, because it lets you choose exactly which VMs are protected and in what order. Keep the list file on stable storage, edit it with an editor that writes Unix line endings, and re-read it after every change. A stray blank line or a misspelled name silently changes what gets backed up.

The all-VMs option, ghettoVCB.sh -a, backs up every VM the host knows about. It is convenient, and it is also indiscriminate. It will include templates, test VMs, and VMs you never meant to protect, and it will spend time and space on all of them. Use it when you genuinely want everything, and use a list file when you want control. For most small hosts, the list file is the better habit, because the list is also your record of what is supposed to be protected.

Use a Configuration File

So far the script has used its default configuration. For real use, you will point it at a configuration file with the -g option, for example ghettoVCB.sh -g /opt/ghettovcb/ghettoVCB.conf with the real path to your config file. The configuration file sets the backup destination, the disk format, how many old backups to keep, and the snapshot and power options. The configuration guide on this site explains every setting, but the key habit is simple: never run a scheduled backup without knowing which configuration file it used. A backup that used the wrong config may have written to the wrong datastore.

Per-VM policies are possible too. With a list file and a configuration directory, the -c option lets different VMs use different settings, so a critical VM can keep more rotations than a test VM. That is an advanced setup, and you should get the single shared configuration working first. Complexity belongs after the basics are proven, not before.

Good Habits for Every Backup Run

Dry run first whenever you change the command, the list, or the configuration
Use full paths for the script, the list file, the config file, and the log file
Redirect output to a log file on every run, manual or scheduled
Read the final status line, then verify the backup files and the snapshot state yourself
Run backups outside peak hours, because snapshots briefly stun the VM and add I/O load
Keep backups on different storage from the VMs they protect

Those habits look dull, and that is the point. Backups fail quietly when nobody checks them. A routine that includes a dry run, a log read, and a file check takes a few extra minutes and catches the failures that matter. The most dangerous backup setup is the one that has never been checked and is assumed to work.

Conclusion

Your first ghettoVCB backup is a dry run, then a single VM, then a check of the files and the snapshot state. From there, a list file and a configuration file turn one backup into a routine that covers the VMs you care about. Always use full paths, always redirect output to a log, and always verify the result yourself. When that routine is proven on one VM, you are ready to schedule it, and the scheduling guide is the natural next step.

How to Back Up a VM with ghettoVCB: Your First Backup