<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 18, 2018 at 10:15 AM, Yaniv Kaul <span dir="ltr"><<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Jan 18, 2018 at 5:08 PM, Dan Yasny <span dir="ltr"><<a href="mailto:dyasny@gmail.com" target="_blank">dyasny@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">If you are using NFS, you might find it easier and more efficient to use a solution outside oVirt. </div></blockquote><div><br></div></span><div>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...</div><div>In theory, it can be extended for application-consistency as well[1].</div><div>Y.</div><div><br></div><div>[1] <a href="https://github.com/guillon/qemu-plugins/blob/master/scripts/qemu-guest-agent/fsfreeze-hook.d/mysql-flush.sh.sample" target="_blank">https://github.com/<wbr>guillon/qemu-plugins/blob/<wbr>master/scripts/qemu-guest-<wbr>agent/fsfreeze-hook.d/mysql-<wbr>flush.sh.sample</a></div><span class=""><div><br></div></span></div></div></div></blockquote><div><br></div><div>Indeed, to be a proper solution it requires some work, my old blogpost was about the initial testing of an external backup solution, which can keep a consistent set of deduplicated and ordered backups, quite easily restorable to a PIT, just like you have with many of today's hyper-v and vmware solutions. What it missing is crash consistency (an API call is required to qemu-ga and other scripts), VM configuration data (OVF or DOMXML export of the VM itself, not just the disks), snapshot chain preservation (not sure it's much of a requirement in a backup solution). </div><div><br></div><div>The oVirt backup API is nice, but what it gives you in the end is a full VM image, instead of incrementals, which is a huge waste of space, unless you are using deduplicated storage, and those are too expensive to store data at rest usually.</div><div><br></div><div>What I like about backy2 is the fact that it deduplicates on the fly, without using anything too low level like ZFS, and you only store the diffs. It also works at the block level, so LVM volumes and files on NFS are treated the same. The extra features like bitrot prevention and NBD aren't without use as well. I'm sure with some work it can be made to work. </div><div><br></div><div>I've also been looking into a very different approach, e.g. live-migrating the VM memstate and disks into a backup image, with migration cancelled when sync is achieved, but that required some serious support from the KVM folks and I had no time besides a shallow dabble. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>I've documented an initial attempt at backing up machine images with backy2 at <a href="https://dyasny.blogspot.ca/2017/06/exploring-backup-options-for-rhvovirt.html" target="_blank">https://dyasny.blogspot.ca/<wbr>2017/06/exploring-backup-optio<wbr>ns-for-rhvovirt.html</a></div><div><br></div><div>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).</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-7949295936762733219gmail-h5">On Thu, Jan 18, 2018 at 9:59 AM, Jayme <span dir="ltr"><<a href="mailto:jaymef@gmail.com" target="_blank">jaymef@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="m_-7949295936762733219gmail-h5"><div dir="ltr"><div><div><div>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. <br><br></div>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. <br><br></div>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). <br></div><div><br></div><div>My concerns with using something like these are:<br></div><div><br></div><div>1. It's using old 3x api -- which is fine for now but probably not with oVirt 4.3<br></div><div>2. Inefficient / resource intensive<br></div><div>3. Using export domain which is depreciated<br></div><div><br></div><div>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? <br></div><div><br></div><div>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?</div><div><br></div><div>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. <br></div><div><br></div><div>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. <br></div><div><br></div><div>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. <br></div><div><br></div><div>Thanks!<br></div></div>
<br></div></div>______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/users</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/users</a><br>
<br></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>