virtualbox.org

I am putting together a VirtualBox host to host a number of VMs (http, mail, mysql, ftp). As a part of this process I want to make backup images on a nightly basis that can be used to quickly restore these machines should the host fail (this is in addition to other redundancy measures).

My thought has been to take a snapshot right before the backup is run, allowing the main VDI to be backed up without it being modified. From what I've read on the VirtualBox forums, it appears that the way to restore a VM on another host machine is to just create a new VM that uses the VDI from the backup. Indeed, I have found that trying to register an existing VM xml file from another host seems to cause trouble. Is this the best way to restore a VM on another machine (copy VDI and create a new VM), or is there a better way that I am missing? I have read a bit about the export/import functionality included in 2.2.0; is this functionality suitable for regular backups in a production environment?

Another thought I have been throwing around is using LVM snapshots for making backups as opposed to VirtualBox snapshots. They both seem to be a means to the same end, but I was wondering if there was a distinct advantage to either approach.

TIA

Using snapshots for backups is not the way to go. Any new data in the VM will NOT go to the base VDI, but it's own snapshot file. It's better to shut down the VM, or save it's state, then backup the VDI file and start it again. With Saved State, you will restore the backup as if the power failed for the machine, so only the active memory is lost. That is a lot better than a week or longer of changes when using snapshots.

I understand that taking a snapshot will cause new data to be written to a new VDI; that is my intent. My reasoning is that by grabbing a copy of the base VDI every night, we wouldn't lose more than a day of data, while allowing the VM to stay online right up until the very end of the backup. My process would go something like this.

1. Take snapshot (subsequent data written to snapshot VDI)
2. Create backup of base VDI
3. Shutdown VM (required to discard snapshot)
4. Discard snapshot (merging disk changes back into main VDI)
5. Start VM

The result here should be under 60 seconds of total downtime for the VM (the time needed to shutdown, discard, and boot). Is my reasoning sound, or am I missing something?

It is a possible way to create backups, but it's not the fastest. My idea for saving it's state is a lot faster. Taking a snapshot alone will take about the same time as saving it's state and resume it, so you can only imagine that having to reboot the VM will add a lot more time for the process. And not only that, but the backup process can be automated using a script with the save state option.

I'm afraid that I still don't see the logic in how a "pause--offline copy--resume" cycle will result in less downtime than my method; especially for VMs with large VDIs. However, it has made me consider another possibility. Wouldn't the VM downtime be reduced even further by using a LVM snapshot to catch the paused system state, then immediately resuming the VM?

1. Pause VM
2. start LVM snapshot
3. Resume VM
4. Copy VDI, state, etc. as convenient
5. Remove snapshot

Of course, that's the fastest way. But when not using LVM, my method is, IMO, easier to do and a bit faster.