On Fri, Oct 12, 2012 at 4:36 PM, Javier Guerra Giraldez <javier@xxxxxxxxxxx> wrote: > 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 Valid points. People seem to like crash-consistent image file backup though because it's convenient. It may not be backing up all application state though :(. Regarding option B, your idea is better than what I've been suggesting. By mounting the image on the host and rsyncing the mounted files you avoid syncing dirty blocks in the image file (e.g. deleted data in the guest file system). Stefan -- 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
