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

[Jayme]

I'm still deciding on storage solutions and have not made up my mind yet.
GlusterFS may be an option but I'm not sure about performance and
maintenance.  It sounds to me like GlusterFS with secondary replicated
gluster volume would work quite well as a disaster recovery solution but
I'd also need historical/incremental backups as well, either of the VMs or
at the very least some important files within such as production DBs etc,
which may be possible with a secondary backup method using rsync or
something along those lines.

It seems to me that there is not a great backup solution for oVirt yet
which I find hard to believe.  I don't understand why backing up oVirt VMs
has to be so complicated, compared to other products.  I was hoping that
4.2 would change that and allow for easier more resource efficient backing
solutions.

On Thu, Jan 18, 2018 at 11:08 AM, 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.
>
> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20180118/e0017f77/attachment.html>