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.
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).
To summarize: snapshot, backup the snapshot files, done; VM is live the whole time.
Why would you want to change the UUID??? It's a reference to the VM, not a disk reference or anything like that.
For the snapshot command you'll probably want to use the VM name anyway (unless you name multiple VM's the same thing...).
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.
>
> 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.
>
> Thanks for the response.
>
> ciao,
>
> der.hans
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)
