[ovirt-users] The future of backups in oVirt 4.2+

[Yaniv Kaul]

On Thu, Jan 18, 2018 at 5:08 PM, Dan Yasny <dyasny at gmail.com> wrote:

> If you are using NFS, you might find it easier and more efficient to use a
> solution outside oVirt.
>

But how do you maintain crash consistency? I suspect using oVirt helps, in
the sense that it enables fsfreeze (VSS). Otherwise, there's a good chance
of fsck...
In theory, it can be extended for application-consistency as well[1].
Y.

[1]
https://github.com/guillon/qemu-plugins/blob/master/scripts/qemu-guest-agent/fsfreeze-hook.d/mysql-flush.sh.sample


> I've documented an initial attempt at backing up machine images with
> backy2 at https://dyasny.blogspot.ca/2017/06/exploring-backup-
> options-for-rhvovirt.html
>
> It is harder to do with block storage and frankly I haven't had the time
> to get to doing it there, but NFS is simple enough, and what you get is
> pretty robust, deduplicated backup, in some ways similar to the typical VM
> backups you get from Veeam and Altaro on other platforms (sans the GUI of
> course).
>
>
>
> On Thu, Jan 18, 2018 at 9:59 AM, Jayme <jaymef at gmail.com> wrote:
>
>> I've been running a non-production oVirt setup for a while and plan on
>> building a more robust oVirt setup for eventual production use.  Part of
>> that planning of course is backup/disaster recovery options.
>>
>> I've been playing around with a few options to backup oVirt, I'm sure
>> most of you are aware of them.  The github webfix it python scripts, and
>> starting to look at bacchus as well although have not set it up or tested
>> bacchus yet.
>>
>> The webfix it python script is fairly simple to setup and seems to work
>> ok as intended, even on 4.2, but it's definitely clunky in terms of having
>> to snapshot, clone, export.  A lot of resource usage.  I assume bacchus
>> most likely uses the same method of snapshot/clone/export as well (due to
>> what was available in oVirt at the time these scripts were written).
>>
>> My concerns with using something like these are:
>>
>> 1. It's using old 3x api -- which is fine for now but probably not with
>> oVirt 4.3
>> 2. Inefficient / resource intensive
>> 3. Using export domain which is depreciated
>>
>> From what I've read in oVirt documentation the Export domain is
>> depreciated.  I assume that this means that instead of a export domain you
>> could instead create a regular data domain for backups that can be detached
>> and attached to another environment, is that the correct assumption?
>>
>> I've also read that it might be possible to skip the cloning of the VM
>> part and export snapshots directly.  Is this now possible in 4.2 or will be
>> in the future?  if it is possible to perform VM backups without cloning to
>> a new VM first is anyone aware of any scripts/software that is available
>> now which takes advantage of that?
>>
>> Essentially all I want is a simple solution to backup my VMs to separate
>> NFS storage.  If for some reason my main storage crashes I then have the
>> option to connect that backup NFS storage to a secondary stand alone oVirt
>> instance and run my VMs from there until the primary oVirt instance is
>> repaired.   What I want to avoid is implementing an older more inefficient
>> solution that might work for a while but will eventually no longer work due
>> to ovIrt updates in the future.
>>
>> I know options like active-active failover and georeplication exist but
>> that may be too complex for my needs although I would be interested in
>> hearing about how some of you may be implementing these features.
>>
>> In summary, I'd trying to figure out what the best backup option may be
>> going forward with oVirt in the future so I can implement the best option
>> from the start rather than having to change it all around in the near
>> future.
>>
>> Thanks!
>>
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20180118/52383dfc/attachment.html>