
Hi Charles,
How are you folks doing your hypervisor level backups?
Under ESXi I used GhettoVCB which basically took a snap shot, copied the disk image to another location, then deleted the snap.
Thank you for this hint, I didn't know about GhettoVCB and I'm definately going to have a look at it.
I haven't been able to find too much information on how this can be done with ovirt. I see discussions on the new backup API, but I'm not interested in spending big bucks on an enterprise backup solution for a home lab.
Only discussion I saw on using snapshots for backups said don't do it because the tools don't sync memory when the snapshots are taken.
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.

On 11/27/2013 4:24 AM, Martijn Grendelman wrote:
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 work-around for this is to SSH into the guest first, put the database into backup mode(maybe run sync a time or two to flush out as much from RAM as possible), take the snap shot, ssh back in to resume the database, backup the snap, delete the snap.

The work-around for this is to SSH into the guest first, put the database into backup mode(maybe run sync a time or two to flush out as much from RAM as possible), take the snap shot, ssh back in to resume the database, backup the snap, delete the snap.
The main problem in oVirt with this strategy would be the lack of live snapshot deletion. Having to shut down the VM to delete/merge a snapshot is not nice :(

On 11/27/2013 10:52 AM, Sander Grendelman wrote:
The main problem in oVirt with this strategy would be the lack of live snapshot deletion. Having to shut down the VM to delete/merge a snapshot is not nice :(
Ouch?! Is there an ETA as to when you'll be able to delete a live snapshot ?

On 11/30/2013 10:36 PM, Blaster wrote:
On 11/27/2013 10:52 AM, Sander Grendelman wrote:
The main problem in oVirt with this strategy would be the lack of live snapshot deletion. Having to shut down the VM to delete/merge a snapshot is not nice :(
Ouch?! Is there an ETA as to when you'll be able to delete a live snapshot ?
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
it requires some heavy lifting in changing some storage aspects which would have other benefits as well - we are very focused on resolving this one.
participants (4)
-
Blaster
-
Itamar Heim
-
Martijn Grendelman
-
Sander Grendelman