Am 12.10.2012 16:36, schrieb Javier Guerra Giraldez:
On Fri, Oct 12, 2012 at 9:25 AM, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote:
I would leave them raw as long as they are sparse (zero regions do not
take up space). If you need to copy them you can either convert to
qcow2 or use tools that preserve sparseness (BTW compression tools are
good at this).
note that free blocks previously used by deleted files won't be
sparse, won't be zero and won't be much reduced by compression.
i'd say the usual advice stays:
A: if you run any non-trivial application on that VM, then use a real
network backup tool 'from the inside' of the VM
B: if real point-in-time application-cache-storage consistency is not
important, then you can:
- make a read-write LVM snapshot
- mount that and fsck. (it will appear as not-cleanly unmounted)
- backup the files. (i like rsync, especially if you have an
uncompressed previous backup)
- umount and destroy the snapshot
- optionally compress the backup
but seriously consider option A before. especially important if you
run any DB on that VM
I already thought about such situations. So DB systems are a real
problem. I know that some data can be better backup directly but for
example a VM for a Web- or Mailserver I want to backup completely to get
this services get to work again very fast if there are problems. So it's
a complex problem I think and not every machine can be backuped as another.
I think that I must start by the hardware and software configuration of
the backup node.
Best Regards
--
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
