> >>+Another approch to backup VM images is to create a new qcow2 image > >>+which use the old image as base. During backup, writes are redirected > >>+to the new image, so the old image represents a 'snapshot'. After > >>+backup, data need to be copied back from new image into the old one > >>+(commit). So a simple write during backup triggers the following > >>+steps: > >>+ > >>+1.) write new data to new image (VM write) > >>+2.) read data from old image (backup) > >>+3.) write data from old image into tar file (backup) > >>+ > >>+4.) read data from new image (commit) > >>+5.) write data to old image (commit) > >>+ > >>+This is in fact the same overhead as before. Other tools like qemu > >>+livebackup produces similar overhead (2 reads, 3 writes). > >>+ > > This is not true with all storages snapshots.
I talk about "create a new qcow2 image which use the old image as base". like described in: http://wiki.qemu.org/Features/Snapshots2 > rbd,sheepdog,nexenta by example ("internal snapshots), you don't need to > do step 4) 5) (merging the snapshot in base image). Sure, but I do not talk about that at all. > deleting the snapshot only delete references(so it's fast). I also thought that it is fast, but it is slow in reality (see qcow2 snapshots on large files). Anyways, we want a backup solution which does not depend on specific storage festures. > > >> > >>+The be more efficient, we simply need to avoid unnecessary steps. The > >>+following steps are always required: > >>+ > >>+1.) read old data before it gets overwritten > >>+2.) write that data into the backup archive > >>+3.) write new data (VM write) > >>+ > >>+As you can see, this involves only one read, an two writes. > >>+ > >>+To make that work, our backup archive need to be able to store image > >>+data 'out of order'. It is important to notice that this will not work > >>+with traditional archive formats like tar. > >>+ > >>+During backup we simply intercept writes, then read existing data and > >>+store that directly into the archive. After that we can continue the > >>+write. > >>+ > > So this is some kind of mirroring ? is this very different from new qemu 1.3 > live disk mirroring ? - mirror copies new data - backup copies old data (before new data is written). > Any impact with high write vm load ? (backup never finish because of too > many writes ?) We only copy old data once before overwritten. Subsequent writes do not impact backup. We are up to 3 times faster than LVM snapshots ;-) > One disavantage of this: > > what happen if you backup storage is slow (or slower than your vm storage > ?) > Can't it impact write speed during the backup? This can slow down writes. But I guess this is not that bad (currently, we run out of snapshot space if storage is slow) > (with snapshot, we can backup slowly, new writes are only going to vm > storage). if you backup slowly, you need much space for snapshots. Anyways, in future, we can try to merge the snapshot and backup frameworks (it is designed for that - although I currently do not think we need it) - Dietmar _______________________________________________ pve-devel mailing list [email protected] http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
