-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thank you a lot for your reply; last time I tried to take external atomic disk only snapshot I encountered bugs (https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1004606) and gave up. In my box I have virsh 1.2.2 and despite this $ virsh blockcommit test hda --active --verbose --pivot error: command 'blockcommit' doesn't support option --active and --pivot it seems to be a solution; I didn't know there were two options; I always thought that dumping disk AND ram was the only solution to have a working backup. what do you suggest me? I would probably feel more safe dumping also the memory (my guests are ubuntu boxes and win2008) but I'm not an expert at all... This idea came into my mind after reading this benchmark (http://jrs-s.net/2013/05/17/kvm-io-benchmarking/) that suggests the use of ZFS. Summing up you suggest me to use libvirt live snapshot instead of dealing with fs snapshot? This will mean that instead of building a zfs/btrfs "raid" over my 8 drive with one subvolume for vm taking care of backing up the guest with its snapshot feature I should build a "classic" raid with a "classic" filesystem (ext4?) and delegate to libvirt the snapshotting tasks? Shouldn't I be worried that a bit rot could lead me to qcow2 degradation? Thank you Francesco Il 06/11/2014 16:02, Eric Blake ha scritto: > On 11/06/2014 03:45 PM, Francesco Morosinotto wrote: >> Hi everybody, >> >> I'm trying to implement in the non profit organization where I work a >> backup strategy for our VMs. >> >> At the moment I weekly backup the machine (on sunday nights) by stopping >> the vm, making a snapshot, exporting the xml descriptor file and syncing >> these files to a remote backup server. > > >> >> I would really like to make daily snapshot without shutting down the vms. > > Doable. Next question - do you want the snapshot to merely be disk > contents (and if so, do you want to quiesce the file system before > taking the snapshot, to avoid the need to fsck the disks before > restoring from them), or the more space-intensive full system snapshot > (where you don't need to quiesce, because reverting involves reloading > the RAM of the guest at the time the snapshot was taken)? > >> at the moment the vms qcow2 disks are stored over an ext4 partition but >> I'm planning to move them over a das with a new generation filesystem. >> >> I'm trying out zfs and btrfs looking for the best one (at the moment zfs >> seems to be more stable and somehow easy, flexible, while btrfs seems to >> have better performance on my linux box). > > btrfs has lousy behavior when coupled with qcow2 images (combining two > different layers that are both trying to do copy-on-write tends to lead > to horrible fragmentation). There is an ioctl to tell btrfs to not do > copy-on-write for files used by snapshots, so you can get performance > back, but it is not default and puts some burden on you to set up. > > I don't know enough about zfs snapshot to have an opinion. > > You may not need file system snapshot if you instead choose to go with > libvirt live snapshot. > >> >> I'm choosing one of these two FS in order to use theire instant-snapshot >> feature; >> my project will be to pause the vm, dump the memory and the xml >> descriptor file, make a snapshot of the subvolume storing the qcow2 file >> and the resuming the machine back (in I hope less than 10 seconds of >> downtime). > > Not ideal. This only takes a disk snapshot, but the state of the disk > is not consistent (you didn't quiesce), so you lose on any pending I/O > that the OS had not yet flushed to disk. Furthermore, this requires > pausing the VM manually, which is more downtime than you will have if > you use libvirt's live snapshot mechanisms. > >> >> what do you guys suggest me? >> >> Am I going to experience bad performance having qcow2 over btrfs? >> I was reading something like that but the posts were really backdated... > > As far as I know, this is still a real problem unless you manually > configure btrfs to not do copy-on-write, at least when qcow2 images are > involved. >