[kwlug-disc] Was cronjob / btrfs scrup [Was: Re: What is all this about systemd?]

[B.S.]

 > Not a true snapshot, since you start
 > where you started, but faster for my purposes. Also, less backup (4GB
 > disk images add up quick).

Agreed, but this is for BMR (Bare Metal Restore), in essence. For which 
one would only need one of. (Assumed.) Granted, for historical or 
archival purposes, the regular in-vm mondoarchive/rsync would apply.

So, in this case, it would be a one per night local machine copy (to 
external eSata drive, thus local speed and no net traffic). Since it 
would run overnight, presumably a reduction in live speed at the time 
would be bearable.

 > I did snapshots for both VirtualBox

Fair enough, but from what I could quickly see, the original disk files 
remain on the original disk, and a difference file gets started (and 
held open), in the same location.

Thus copying just the original file (which is now not held open) gets 
you the vm as it was, not as it is. And the accompanying parameter files 
are a moving target. It didn't seem one could get a current copy, as at 
least one file would be held open. And since it would take less than a 
blip to copy the disk file [vs the parameter file(s)] the copied set of 
files making up the vm would be internally inconsistent on the backup copy.

It seemed that vbox snapshots are fine for vm 'surviving' functionality 
on hardware that works throughout. It didn't seem fine if you yank the 
original disk away - the only way to accomplish that was via an 
underlying fs snapshot facility.

You understand differently?


On 14-10-28 01:24 PM, Khalid Baheyeldin wrote:
> On Tue, Oct 28, 2014 at 1:13 PM, B.S. <bs27975 at yahoo.ca> wrote:
>> I've recently started wondering about how to back up a vm, live. i.e.
>> Assuming one leaves a vm up 24/7, and wanting an instant restore (vs backing
>> up the vm from within the vm, be it rsync and/or mondoarchive). In essence,
>> if the machine or disk goes down, light up the backup copy of the vm and get
>> on with figuring out what happened to the original.
>
> I did snapshots for both VirtualBox and KVM (via libvirt, which will
> be the core of the presentation Monday).
>
> VirtualBox snapshots worked fine. KVM snapshots work fine too, but are
> slow. It was faster to backup the raw disk and then copy it to the
> working disk with the VM down. Not a true snapshot, since you start
> where you started, but faster for my purposes. Also, less backup (4GB
> disk images add up quick).
>
>>
>> If the 'backup' lands on an external (eSata) disk, then presumably I just
>> move the disk to another machine upon original machine failure and turn on
>> the vm there.
>
> Yes, provided you are using KVM/libvirt and export the XML and import
> it to the other machine. Also, any network customizations, ...etc.
>
>>
>>  From my initial poking, vbox can't do this [but can if the vm is taken down
>> first]. Seems that an extra-vm facility is needed, such as a btrfs or lvm
>> snapshot.
>
> Can't comment on the btrfs/lvm part. But I found that VirtualBox
> refuses to start on a copied disk image, because it identifies them by
> a UUID, which is a pain. KVM does not have that restriction, and it
> just points to a regular Linux path for the image. It does not care if
> you swap.
>
>