Hi Charles, Thank you for this hint, I didn't know about GhettoVCB and I'm definately going to have a look at it. The problem with snapshot-based backups is, that they are usually only crash-consistent, meaning that they contain the state of a system's disks as they would be if you pulled the power plug on a server. If you restore a system from this type of backup, you would see file system recovery happening at the first boot, and you risk data loss from -for example- database servers. The process that GhettoVCB uses according to your description above is the same. Your backups are only crash-consistent. If you need application-level consistency, you need a mechanism to inform applications that a backup is going to take place (or rather: a snapshot will be taken) and that they should place themselves in a consistent state. For example: sync data to disk, flush transaction logs, stuff like that. Microsoft Windows has VSS for that. For Linux, there is no such thing (that I know of). Common practice for "quiescing" database servers and such on Linux is making consistent SQL dumps in a pre-backup job. I my case, for most guests a crash-consistent backup, containing a recent MySQL or PostgreSQL dump is sufficient. I use LVM snapshots (not oVirt snapshots) for backups, and I use Rsync to transfer the data. I have been experimenting with Virtsync [1], but I'm having a bit of trouble with that, so for the moment, it's just Rsync. Efficiently backing up sparse images with Rsync can be a bit of a challenge (that's why Virtsync was created in the first place, IIRC), but using '--sparse' on the inital backup and '--inplace' on subsequent backups seems to do the trick. [1] http://www.virtsync.com/ I hope this helps. Cheers, Martijn.