On 05/16/2011 12:38 AM, Jagane Sundar wrote:
Hello Dor,
One important advantage of live snapshot over live backup is support of
multiple (consecutive) live snapshots while there can be only a single
live backup at one time.
This is why I tend to think that although live backup carry some benefit
(no merge required), the live snapshot + live merge are more robust
mechanism.
The two things that concern me regarding the
live snapshot/live merge approach are:
1. Performance considerations of having
multiple active snapshots?
My description above was in accurate and I only hinted that multiple
snapshots are possible but they are done consecutively -
Live snapshot takes practically almost no time - just the time to get
the guest virtagent to freeze the guest FS and to create the snapshot
(for qcow2 is immediate).
So if you like to have multiple snapshot, let's say 5 minute after you
issued the first snapshot, there is no problem.
The new writes will go to the snapshot while the former base is marked
as read only.
Eventually you like to (live) merge the snapshots together. This can be
done in any point in time.
2. Robustness of this solution in the face of
errors in the disk, etc. If any one of the snapshot
files were to get corrupted, the whole VM is
adversely impacted.
Since the base images and any snapshot which is not a leaf is marked as
read only there is no such risk.
The primary goal of Livebackup architecture was to have zero
performance impact on the running VM.
Livebackup impacts performance of the VM only when the
backup client connects to qemu to transfer the modified
blocks over, which should be, say 15 minutes a day, for a
daily backup schedule VM.
In case there were lots of changing for example additional 50GB changes
it will take more time and there will be a performance hit.
One useful thing to do is to evaluate the important use cases
for this technology, and then decide which approach makes
most sense. As an example, let me state this use case:
- A IaaS cloud, where VMs are always on, running off of a local
disk, and need to be backed up once a day or so.
Can you list some of the other use cases that live snapshot and
live merge were designed to solve. Perhaps we can put up a
single wiki page that describes all of these proposals.
Both solutions can serve for the same scenario:
With live snapshot the backup is done the following:
1. Take a live snapshot (s1) of image s0.
2. Newer writes goes to the snapshot s1 while s0 is read only.
3. Backup software processes s0 image.
There are multiple ways for doing that -
1. Use qemu-img and get the dirty blocks from former backup.
- Currently qemu-img does not support it.
- Nevertheless, such mechanism will work for lvm, btrfs, NetApp
2. Mount the s0 image to another guest that runs traditional backup
software at the file system level and let it do the backup.
4. Live merge s1->s0
We'll use live copy for that so each write is duplicated (like your
live backup solution).
5. Delete s1
As you can see, both approaches are very similar, while live snapshot is
more general and not tied to backup specifically.
Thanks,
Jagane
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
