Backup of VMs

[MatthK]

Hi

From what I understand is that backing up a running VM is not recommended, unless you do it inside the guest. Somehow the few minutes of downtime bother me a little bit, however in practical life that should probably not be an issue at all. So I have created the following small script to backup my various VMs individually. The script does the following:

- Define the variables at the beginning
- Check the state of the VM and shut it down if it is running
- Check in a loop if the VM is powered off (wait max. 60 seconds or then abort)
- Copy the directory to the specified location
- Start the VM again (only if it was running before)
- Send out an email with the results

The script also creates a logfile with date/time stamps. I run this script with cron once per day during the night, and have one script for each VM that I want to backup. A typical VM is backed up in less than 5 minutes in my case. Can that be further reduced?

My question though is whether this is a valid and "safe" way to keep a backup of my VMs. In case of a failure of the system for example, can I simply take the backed up directory and fire the same VM up on a different machine? Would the new machine need to be the same OS and/or Virtualbox version? Or could it be a different Virtualbox version, with different hardware?

Also, are there any crucial steps that I missed, or is this a reasonable way to backup my VM?

Code: Select all

#!/bin/bash

# =============== Set your variables here ===============
MYMAIL=email@inter.net
VMDIR="/home/user/VMs/Proxy/"
EXPORTDIR="/mnt/backup/vmbackup/"
LOGDIR="/home/user/logs/"
LOGNAME="proxy.log"
VM="Proxy"
ERR="nothing"
SECONDS=0
STARTUP=1

LOGFILE="$LOGDIR$(date +"%Y-%m-%d-%T")-$LOGNAME"

cdt=$(date)
echo "${cdt}: Backing up VM ${VM}" >> $LOGFILE

# Get the vm state
VMSTATE=$(vboxmanage showvminfo "$VM" --machinereadable | grep "VMState=" | cut -f 2 -d "=")
cdt=$(date)
echo "${cdt}: ${VM}'s state is: ${VMSTATE}." &>> $LOGFILE

# If the VM's state is running or paused, save its state
if [[ $VMSTATE == \"poweroff\" ]]; then
  # skip the wait
  cdt=$(date)
  echo "${cdt}: VM ${VM} is already powered off" &>> $LOGFILE
  STARTUP=0
else
  # Shut down the VM
  cdt=$(date)
  echo "${cdt}: Shutting down the VM ${VM}" &>> $LOGFILE
  vboxmanage controlvm "$VM" acpipowerbutton
  if [ $? -ne 0 ]; then ERR="shutting down"; fi
  # cdt=$(date)
  # echo "${cdt}: Waiting 60 seconds to let the VM ${VM} shut down" &>> $LOGFILE
  # sleep 60s
fi

max_wait=$((SECONDS+60))
cnt=1
# Check state of VM
VMSTATE=$(vboxmanage showvminfo "$VM" --machinereadable | grep "VMState=" | cut -f 2 -d "=")
# Wait a maximum of 60 seconds to avoid an infinite loop in case the VM can't be stopped
while [[ $VMSTATE != \"poweroff\" ]]
do
   cdt=$(date)
   echo "${cdt}: ${cnt} loop(s) waiting for the VM ${VM} to shut down. Current state is ${VMSTATE}" &>> $LOGFILE
   # Wait a few seconds before checking again
   sleep 5s
   # Checking state of VM again
   VMSTATE=$(vboxmanage showvminfo "$VM" --machinereadable | grep "VMState=" | cut -f 2 -d "=")
   cnt=$(( $cnt + 1 ))
   # If loop has taken more than 60 seconds, break it to avoid an infinite loop
   if [ $SECONDS -gt $max_wait ]; then break; fi
done

# Check if VM is now powered off
# VMSTATE=$(vboxmanage showvminfo "$VM" --machinereadable | grep "VMState=" | cut -f 2 -d "=")
cdt=$(date)
echo "${cdt}: ${VM}'s state is: ${VMSTATE}." &>> $LOGFILE

if [[ $VMSTATE == \"poweroff\" ]]; then
   eval cp -R "${VMDIR}" $EXPORTDIR
   cdt=$(date)
   echo "${cdt}: VM ${VM} has been copied from ${VMDIR} to ${EXPORTDIR}" &>> $LOGFILE
else
   ERR="not powered off"
   cdt=$(date)
   echo "${cdt}: Not exporting because the VM ${VM} is not powered off." &>> $LOGFILE
fi

if [[ $STARTUP == 1 ]]; then
   vboxmanage startvm "$VM" --type headless &>> $LOGFILE
   if [ $? -ne 0 ]; then 
      ERR="starting up"
   else
      cdt=$(date)
      echo "${cdt}: VM is started up again" >> $LOGFILE
   fi
fi

# Calculate duration
duration=$SECONDS
duration="Operation took $(($duration / 60)) minutes, $(($duration % 60)) seconds." &>> $LOGFILE

# Notify the admin
if [ "$ERR" == "nothing" ]; then
  MAILSUBJECT="VM ${VM} succesfully backed up"
  MAILBODY="Virtual Machine ${VM} was succesfully backed up!"
  MAILBODY="$MAILBODY"$'\n'"$duration"
#  MAILBODY=$(echo $MAILBODY && cat $LOGFILE)
else
  MAILSUBJECT="Error $ERR VM ${VM}"
  MAILBODY="There was an error ${ERR} VM ${VM}."
  MAILBODY=$(echo $MAILBODY && cat $LOGFILE)
fi

# Send the mail
echo "$MAILBODY" | mail -s "$MAILSUBJECT" $MYMAIL

[granada29]

I think that is a good way of backing up the VM. In the event you need to restore to a new machine, you need to add it to your configuration (VirtualBox Manager) and then verify the settings before running the VM.

i.e.
RAM - does new machine have enough?
CPUs - ditto
Network Interface(s): do they have same ID?

Probably more things as well but those are the obvious ones.

Edit to add:
Best to not use snapshots. They're bound to be a source of grief in the restore.
Use same versions of VirtualBox if possible - saves messing about with Guest Additions.
I have done this many times between macOS and Linux and it has always worked well.

[MatthK]

Thanks, that is re-assuring.

I found a little improvement in times of downtime, by first copying the directory to a local disk, before copying it away. The local disk is faster than the Gigabit network connections. So my most important VM is now down 2 minutes 33 seconds instead of 6 minutes 4 seconds.

And yes, it obviously needs to have "room" on the new host and should have the same network settings.

[arQon]

It's a reasonable way IFF you want to be able to do bitwise validation of the image, which you obviously don't since you'd need the VM to be down for that stage as well. That being the case, especially since you're trying to put a very large image onto *very* slow storage, you'd almost certainly be better off running it through CloneVDI (--keepuuid --compact) instead: that was a net win for me going onto an enterprise HDD more than twice as fast as GbE, so it would be a much larger one for you.

add> For reference, the 16GB VDI I backed up this morning took just under a minute, on a very old machine.

[MatthK]

Didn't know about CloneVDI. However, since my host is Linux box, it's not gonna fly for me.

[scottgus1]

CloneVDI can apparently run on Linux using Wine, please see viewtopic.php?t=22437

However, there is a tremendous benefit in confirming that the backup was copied correctly, and bit-wise FC file compare is the way to do that. A backup that for some reason didn't copy correctly isn't a real backup, it's only an increase in carbon footprint.

CloneVDI will copy only the parts of the disk files that need copying, thus reducing copying time. But the copy isn't an identical copy, so no way to confirm integrity for backup purposes.

As a perspective in backup times, I used to back up 5 VMs with about 450-ish total GB disk files in about 5 hours, doing basic file copy, FC file compare, and an SHA256 hash to check offsite backups. I also backed up the VMs to a separate fast drive on the host, then while the VMs restarted, I used the copies on the separate host drive as sources for further backup copies to other standby hosts and over-the-internet offsite backup.

[MatthK]

How do you do that bit-wise FC file compare on Ubuntu in a command line? What are some good tools for that?

Obviously, I potentially like to integrate that into the script, so it should work from the command line.

[scottgus1]

I'm no Linux guru, unfortunately. Try a web-search:

linux file compare command

[arQon]

If you have good enough backups from within the guests, running the images through CloneVDI or etc isn't an issue. I do things this way because the images are solely to save me having to reinstall and reconfigure in case of disaster. If you're backing up the entire VM *for its data* instead of for its own sake, you're probably Doing It Wrong. (Though personally I'd make an exception for anything involving the hellscape that is the Windows registry).

Yes, there's always a risk/return tradeoff to be made, but e.g. an hour's worth of downtime simply isn't an option in a lot of scenarios; or the "validated" backups may just be a net loss compared to having to rebuild a machine once every few years - especially since you'd have to lose the VM *and* have a corrupted backup at the same time. If the previous backup is only a day old in that case rather than a month old solely *because* the backup ran quickly enough that it actually happens on a decent schedule, that's a lot more valuable than a hypothetically-better approach that lost three weeks of changes instead - it's just not an approach I'd be happy with if that machine had the only copy of my medical or pension records on it, etc.

I think that as long as people aren't trying to use snapshots, pretty much any strategy is going to work adequately. But he asked for faster, so I gave him faster.