backing up VirtualBox

[der.hans]

Am 01. Jul, 2009 schwätzte Joseph Sinclair so:

moin moin,

> der.hans wrote:
>> Am 19. Jun, 2009 schw???tzte Joseph Sinclair so:
>>
>> Sorry for the delayed response. Been barely keeping up with mtg plans.
>>
>>> I assume you're using VDI disk images for the Virtual Machines.  If
>>> you're using write-through disks it gets a LOT harder.
>>>
>>> With VDI disks:
>>>
>>> VBoxManage snapshot <VMachine name or UUID> take backup-$(date
>>> +%Y%M%DT%H%m%s) --description "backup for $(date +'%Y-%M-%DT%H:%m:%s
>>> %z')"
>>>
>>> Then backup the newly created snapshot VDI file (along with any
>>> previous snapshots as well, of course; rsync is a great tool here).
>>> Restoration requires ALL snapshots from first to last, so don't
>>> discard any VDI files.
>>
>> Yeah, I think backups, snapshotting and cloning sucks with VirtualBox.
>>
>> I'm thinking we'll have to make snapshots and clone them in order to
>> create another snapshot in order to get to it.
>>
>> Is there a way to change the UUID in the snapshot vmi? I suppose I could
>> just try to change it with sed...  :)
>>
>
> I have to disagree here, Backup and snapshotting with VirtualBox is, IMO, exceptional.

Snapshotting works, but using the snapshots is a pain.

You can only use the oldest snapshot. Or, you can merge all the snapshots,
but then you no longer have the snapshots.

> I think you misunderstood.  You just call one command to create the snapshot while the machine is running, then
> backup the files (minus the newest, of course, that very small file would be in use), all without interrupting the live VM.
> Since snapshots are incremental, with rsync you're just backing up the changes in the system state since the prior
> backup (the same thing you'd do with a live system, only easier).

Yeah, guess it wouldn't be using as much space as I was thinking.

> To summarize: snapshot, backup the snapshot files, done; VM is live the whole time.

Yup. That part I knew :). It's the restoral that I'm still not happy with.

> Why would you want to change the UUID???  It's a reference to the VM, not a disk reference or anything like that.

So I can restore a particular snapshot. If I have the base image and
copies of the snapshots I should be able to merge snapshots in a restore
area.  Unfortunately VirtualBox won't let that happen due to the UUID
already being in use. It also won't allow changing the UUID in the
snapshots, only in the base image.

In the end I should be able to create a different VirtualBox instance for
the restorals or just do it all inside a VM :), but it's annoying.

> For the snapshot command you'll probably want to use the VM name anyway (unless you name multiple VM's the same thing...).

Due to trying to restore specific snapshots VirtualBox is demanding that
they have the same names. I would prefer to not use the same name, but not
being able to rename snapshots prevents that.

> Snapshots don't create new VMI's, only VDI's.  The VM definition doesn't change, there's just a new snapshot file in the VDI directory.
>
>>
>>> The most recent VDI is always the current running state, and you need
>>> to leave that one off the list, since it's generally not safe to use
>>> for backup and restore.
>>>
>>> This will correctly snapshot the state of a *running* VM and allow you
>>> to backup it's VDI file(s) for later restoration if needed.
>>> You can restore the VM by simply restoring the VDI file(s) for that
>>> machine, and starting it up.
>>
>> But them I'm doing full image backups :(.
>
> no, incremental.  Snapshots are always increments from the prior (that's why you need them all to run).  You backup whole files (easy) and you get incremental daily backups (nice to have) for "free".
> If you want to do a monthly "full" backup, you can merge the snapshots once a month (takes about 5 minutes, but the VM has to be turned off while that's being done) and then backup the newly merged VDI file.

Part of the point of snapshots is so you can do work like that on the side
without affecting the currently running instance :).

I'm wanting to play with a variety of snapshots ( forward and back ). The
only way to do that right now is to take a snapshot, clone the base file,
merge the snapshot, create a new snapshot, clone the base file, and ѕo on.
That requires me to have multiple full copies of the image rather than
being able to just clone a particular point in time by cloning the
snapshot.

>> Looks like we'll be putting all our data on NFS anyway, so I really just
>> need to backup /etc/ and maybe /var/.
>>
>> Some initial testing with etckeeper is looking good, so a git repo on the
>> nfs partition and a script to make sure /etc/ stays cleans will probably
>> take care of the former and anything in /var/ that I really care about.
>
> Any distributed VCS (Mercurial, git, DARCS) works fine for these, etckeeper is a nice unified interface for etc, and you can use direct git/Mercurial/DARCS commands for /var.

I've liked etckeeper thus far, especially since it plays nice with apt.
Still haven't used it much, though.

ciao,

der.hans
-- 
#  http://www.LuftHans.com/        http://www.LuftHans.com/Classes/
#  Practice socially conscious hedonism. Do whatever you want,
#  as long as it doesn't hurt anyone else. - der.hans