[pve-devel] [PATCH 1/4] RFC: Efficient VM backup for qemu

[Alexandre DERUMIER]

>>Anyways, we want a backup solution which does not depend on specific storage festures. 
Yes, sure, I agree with that ! (I was just a comment ;)

>>We only copy old data once before overwritten. Subsequent writes do not impact 
>>backup. 
Oh, ok, great !

>>- mirror copies new data 
>>- backup copies old data (before new data is written). 

ok,So we have a backup of the state of disk at the time of the backup start ? 
Do you keep some blocks maps in memory ? (if yes, what is the memory usage with big volume?)


>>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. 

Yes, this is space vs speed.
I have in mind some high database load, like 5000iops or more, so it need a fast backup storage in this case.
I the vm does random io, does the backup storage write blocks sequentially ?
 (if yes, maybe it can be fast with a slow random io backup storage but with high sequential throughput)

----- Mail original ----- 

De: "Dietmar Maurer" <dietmar at proxmox.com> 
À: "Alexandre DERUMIER" <aderumier at odiso.com> 
Cc: pve-devel at pve.proxmox.com 
Envoyé: Mardi 13 Novembre 2012 17:50:40 
Objet: RE: [pve-devel] [PATCH 1/4] RFC: Efficient VM backup for qemu 

> >>+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