Restore a VM from a ghettoVCB Backup: Step by Step

A backup you have never restored is a promise, not a protection. Sooner or later you will need to keep that promise, whether a VM is corrupted, a datastore fails, or a bad update needs rolling back. Restoring from a ghettoVCB backup is deliberately simple, because the backup is just ordinary VM files. You register the backed-up configuration file, power the VM on, and check that it works. This guide walks through that process, the decisions you must make before you restore over an existing VM, and the testing habit that turns a backup into something you can rely on.

Before you restore anything, find the backup you mean to use. Browse the backup destination and identify the VM folder and the dated backup folder inside it. Confirm the folder contains the VMDK files and the VMX file, and check the date on the folder name against the point in time you want to return to. Restoring the wrong date is easy when several rotations sit side by side, and it is a mistake you notice only after the VM is running. Write down the full path to the VMX file you plan to register before you type any command.

Register the Backed-Up VMX

The standard restore is to register the backed-up .vmx file with the host. From the shell, the command looks like this: vim-cmd solo/registervm /vmfs/volumes/datastore1/backups/VM_NAME/VM_NAME.vmx, with the path replaced by the real path to your backed-up VMX file. The command returns an identifier for the newly registered VM. You can also do the same job from the client by browsing the datastore, finding the VMX file, right-clicking it, and choosing to add it to the inventory. Both routes end in the same place: the VM appears in the inventory, powered off, ready to check before you start it.

Before you power it on, open the VM settings and confirm the basics. Check that the disks point at the backed-up VMDK files in the backup folder, not at the original datastore. Check the network assignment, because a restored VM that powers on with the same network settings as a running original can cause an address conflict. Check the name, so you can tell the restored copy apart from the original in the inventory. A minute of checking here prevents the most common restore accident, which is powering on a copy that fights with the original.

The Restore Helper Script

The project also ships a restore helper, ghettoVCB-restore.sh, which automates parts of the restore process. If you installed from the archive, it sits beside the backup script. If you installed the VIB, check the project docs for its location in your install. The helper is worth knowing about, and the manual registration method is worth learning first, because the manual method teaches you what the helper does and leaves you able to restore even if the helper is unavailable. Read the helper’s documentation before you use it on a real VM, and test it on a non-critical restore first, just as you tested the backup script.

Whichever method you use, the restore does not move the backup files. Registration points the host at the files where they sit, in the backup destination. That has a consequence worth thinking about. If the backup destination is slow NFS storage, the restored VM will run from that storage until you move it. For a quick check, that is fine. For a VM going back into production, plan to migrate it to proper production storage after you confirm it works, and keep the backup files intact until the migration is done.

Restoring Over an Existing VM

Restoring over a VM that still exists is the highest-risk restore, and it needs a decision before you act. If the backup should replace the original, shut the original VM down first, and remove or unregister the original before you register the backup. Registering a second copy while the original is running invites confusion, address conflicts, and the chance of editing the wrong copy. If the original might still hold data you need, do not delete it. Unregister it and keep its files, or rename its folder, so the data survives even if you decide the restore was the right call. Deleting the original is permanent, and a restore done in a panic is the worst moment to make a permanent decision.

Write down what you are about to do, in plain language, before you do it: which VM, which backup date, whether the original stays or goes, and where the restored VM will run. That note takes thirty seconds and it is the document you will be grateful for if the restore goes wrong and you need to explain the state of things to someone else. Backups are technical, but restores are decisions, and decisions deserve a written record.

Test the Restored VM Before You Trust It

Power the restored VM on and watch it boot. Log in if you can, and check the things that matter for that VM: its services start, its data is at the date you expected, and its applications respond. A VM that boots is not automatically a good restore. A database VM that boots with data from the wrong week is a bad restore wearing a good disguise, so check the data, not just the boot screen. If the VM is part of a set, check its partners too, because a restore that rolls one VM back in time while its partners stay current can break the application in ways no single-VM check will catch.

Restoring to different storage or a different host may need path adjustments. The VMX file records where its disks live, and if those paths do not match the new location, the VM will complain when it starts. Keep this general rule in mind: after a move, check disk paths first, fix them from the client or by editing the VMX while the VM is powered off, and re-check before you power on. Document any path changes you make, so the next restore does not have to rediscover them.

Test Restores on a Schedule

Pick one VM per month and restore it to an isolated location, without touching production
Boot the restored VM, log in, and verify the data date and the key services
Confirm the backup folder, the VMX path, and the disk paths all match your notes
Record the test result, the backup date used, and anything that needed fixing
Fix the backup job when a test fails, and re-test before the next scheduled run
Never treat a backup as proven until a restore from it has actually booted

A monthly restore test is the cheapest insurance in this whole subject. It proves the backups, the restore procedure, and your own notes, all at once. The month you skip the test is the month the backup job silently broke, and that pattern repeats often enough that you should assume it will happen to you. Schedule the test the way you schedule the backup, and keep the results where the team can see them.

Conclusion

Restoring from ghettoVCB means registering the backed-up VMX, checking disks and networks before power-on, and verifying the data, not just the boot. The restore helper can automate parts of the job, and the manual method is worth knowing regardless. Decide before you restore over an existing VM, keep the original’s files until you are sure, and test restores on a schedule. A backup that has been restored and booted is a backup you can trust. Everything else is a hope.

How to Restore a VM from a ghettoVCB Backup