On Wed, Dec 6, 2017 at 6:02 PM Jason Lelievre <jlelie...@folksvfx.com> wrote:
> Hello, > > What is the best way to set up a daily live snapshot for all VM, and have > the possibility to recover, for example, a specific VM to a specific day? > Each snapshot you create make reads and writes slower, as qemu has to lookup data through the entire chain. When we take a snapshot, we create a new file (or block device) and make the new file the active layer of the chain. For example, assuming you have a base image in raw format: image-1.raw (top) After taking a snapshot, you have: image-1.raw <- image-2.qcow2 (top) Now when qemu need to read data from the image, it will try to get the data from the top layer (image-2), if it does not exists it will try the backing file (image-1). Same when writing data, if qemu need to write small amount of data, it may need to get entire sector from a another layer in the chain and copy it to the top layer. So after a month of backups, will have 30 layer in the chain. I don't know how much slower it will be, I never measured this. For backups, I think you like to have something like a daily backup for the last week, a weekly backup for the last month, and so on. For daily backup of the last week you can take a snapshot every day, and delete the 7th snapshot every day. Then backup the snapshot bellow the active layer. You can download the snapshot using the SDK, see the download_snapshot example (requires 4.2). All this can be done while the vm is running. On your backup, you will have a snapshot per day. You can keep all snapshot or merge old snapshot using qemu-img commit. It is also should be possible to reconstruct an image on storage from your backup by uploading the the snapshots back to storage - but it is tricky to get right. I think the best option for users is to get some 3rd party solution based on the oVirt SDK. Adding qemu-block mailing list, they can probably add more info on how much you pay for large chain of images, and have more ideas about backing up qcow2 chains. I use a Hyperconverged Infrastructure with 3 nodes, gluster storage. > Maybe a solution based on gluster or the layers below (e.g. lvm snapshots) will be easier to use and more efficient. You can ask in the gluster mailing list. Adding Sahina to help with the gluster side. Nir > > > > Thank you, > _______________________________________________ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
