I have several virtual machines running on Virtualbox. I want to take a backup of these virtual machines and store in source control for disaster recover. From what I understand, snapshots of these virtual machines aren't going to do the trick as far as disaster recovery is concerned.

These backups will be taken periodically, and I'm going to automate them using Jenkins automation server. I have been using an article from TechRepublic as a resource for operating VirtualBox from command line as far as exporting virtual appliances.

My thoughts on the process executed by the Jenkins job are as follows (all actions performed from command line):

  1. Power down the particular virtual machine to be backed up (and leave virtualbox running).
  2. Run the VirtualBox export command:

    vboxmanage export UBUNTUSERVER164 -o ubuntu_server_new.ova
  3. Run command to bring the virtual machine back up.

  4. CD into the directory where VirtualBox virtual appliances are stored.
  5. Copy the newly created virtual appliance (.ova format), to a local backup directory.
  6. Compress (tar), the copied .ova file in the local backup directory.
  7. Remove the uncompressed copy of the .ova file in the local backup directory.
  8. Git commit the compressed virtual appliance, and Git push to BitBucket.

Some questions I have about using this approach:

  • Where are VirtualBox's virtual appliances stored by default?
  • What would the shell command look like to power down the virtual machine pre backup?
  • What would the shell command look like to power on the virtual machine post backup?

Here's an easy approach for your task:

  1. Shut down the guest through an SSH session running in the guest

    ssh -t user@virtualmachine sudo poweroff
    • Poweroff the virtual machine using VBoxManage controlvm [nameofmachine] poweroff is not recommended as it may lead to data loss.
  2. Export the virtual machine to OVA format

    VBoxManage export [nameofmachine] -o /path/[name].ova
    • OVA format will use the compressed VMDK format for the VDI. Further compression may not be needed.
    • Exporting will need the time for several cups of coffee.
  3. Copy the resulting (huge) OVA file to whatever location your backup needs to be.

  4. Import the backup

    VBoxManage import [filename.ova] [--dry-run] [--vsys 0 --vmname <name>]
    • Make a dry run for a display of options you may need. Take care to give it another name if you had still kept the original name.
  5. Run the imported virtual machine

    virtualbox --startvm [name]
  • The 1st one can be a one-liner: ssh -t user@virtualmachine sudo poweroff (and shorter :P ) – Rinzwind Jul 13 '17 at 18:47
  • @Rinzwind yeah... shortage ftw :) – Takkat Jul 13 '17 at 19:03
  • Just for reference I do not need to SSH into these machines as they are virtual machines running inside of virtualbox on my Jenkins host machine. My Jenkins jobs can execute VirtualBox shell commands against the VMs without SSH as they are on the same machine. – J0991 Jul 13 '17 at 19:37
  • @J0991: that's even better then. :) – Takkat Jul 14 '17 at 6:26
  • Something I've noticed online is a bit of a discussion around sending the shutdown signal verses executing the command to power down the machine. Anybody have any experience either way with these two approaches when exporting an appliance from virtualbox? I've heard executing the command poweroff can cause issues with exporting due to the VMs state? – J0991 Jul 14 '17 at 12:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.