5:59 p.m.
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!
6:08 p.m.
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....
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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
6:15 p.m.
On Thu, Jan 18, 2018 at 5:08 PM, Dan Yasny <dyasny(a)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-ag...
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(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
6:30 p.m.
On Thu, Jan 18, 2018 at 10:15 AM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
On Thu, Jan 18, 2018 at 5:08 PM, Dan Yasny <dyasny(a)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
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).
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.
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.
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.
> I've documented an initial attempt at backing up machine images with
> backy2 at https://dyasny.blogspot.ca/2017/06/exploring-backup-optio
> ns-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(a)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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
6:25 p.m.
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(a)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(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
6:43 p.m.
On Jan 18, 2018 5:29 PM, "Jayme" <jaymef(a)gmail.com> wrote:
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.
Gluster has a geo-replication based backup which is very cool and
integrated to oVirt UI.
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.
It certainly does. See the DR work (and youtube video).
Y.
On Thu, Jan 18, 2018 at 11:08 AM, Dan Yasny <dyasny(a)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-optio
ns-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(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
8:46 a.m.
This message is in MIME format. Since your mail reader does not
understand
this format, some or all of this message may not be legible.
--B_3599164006_104503654
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
On Jan 18, 2018 5:29 PM, "Jayme" <jaymef(a)gmail.com> wrote:
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 mainten=
ance.
It sounds to me like GlusterFS with secondary replicated gluster
volume w=
ould
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
poss=
ible
with a secondary backup method using rsync or something along those
lines=
.
-Gluster has a geo-replication based backup which is very cool and
integrated to oVirt UI.
=20
It seems to me that there is not a great backup solution for oVirt yet wh=
ich 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 solution=
s.
-It certainly does. See the DR work (and youtube video).
-Y.=20
** I have yet to see a working script that does a VM backup from oVirt 4.2
to NFS storage?? I have spent days testing and trying all the scripts I can
find, most are old and all seem to fail in different ways. I have even code=
d
my own script using bash/curl/RestAPI and hit a dead end there as well with
not finding any docs on how to backup an inactive disk from a attached
snapshot. You=B9d think oVirt would have something better for a DR solution o=
r
at least make it so you dont have to become an oVirt Dev Contributor to be
able to backup your Vms? **
I would love to see a clear example of how to do VM backups from the comman=
d
line in a script so I can move on to rolling out oVirt 4.2 ;)
Zip
=20
On Thu, Jan 18, 2018 at 11:08 AM, Dan Yasny <dyasny(a)gmail.com> wrote:
> If you are using NFS, you might find it easier and more efficient to use=
a
> solution outside oVirt.
>=20
> I've documented an initial attempt at backing up machine images with bac=
ky2
.html
>=20
> 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 pre=
tty
> robust, deduplicated backup, in some ways similar to the typical
VM back=
ups
> you get from Veeam and Altaro on other platforms (sans the GUI of
course=
).
>=20
>=20
>=20
> On Thu, Jan 18, 2018 at 9:59 AM, Jayme <jaymef(a)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 o=
f
>> that planning of course is backup/disaster recovery options.
>>=20
>> I've been playing around with a few options to backup oVirt, I'm sure m=
ost
>> of you are aware of them. The github webfix it python
scripts, and sta=
rting
>> to look at bacchus as well although have not set it up or
tested bacchu=
s
>> yet.=20
>>=20
>> 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 mo=
st
>> likely uses the same method of snapshot/clone/export as well
(due to wh=
at
>> was available in oVirt at the time these scripts were
written).
>>=20
>> My concerns with using something like these are:
>>=20
>> 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
>>=20
>> From what I've read in oVirt documentation the Export domain is depreci=
ated.
>> I assume that this means that instead of a export domain you
could inst=
ead
>> create a regular data domain for backups that can be detached
and attac=
hed
>> to another environment, is that the correct assumption?
>>=20
>> 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?
>>=20
>> Essentially all I want is a simple solution to backup my VMs to separat=
e
NFS
>> storage. If for some reason my main storage crashes I then
have the op=
tion
>> to connect that backup NFS storage to a secondary stand alone
oVirt ins=
tance
>> 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.
>>=20
>> 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 heari=
ng
>> about how some of you may be implementing these features.
>>=20
>> 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 opti=
on
>> from the start rather than having to change it all around in
the near
>> future.=20
>>=20
>> Thanks!
>>=20
>> _______________________________________________
>> Users mailing list
>> Users(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>=20
>=20
=20
=20
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
=20
--B_3599164006_104503654
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
<html><head></head><body style=3D"word-wrap: break-word;
-webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size:=
14px; font-family: Calibri,
sans-serif;"><div><div><div><br></div></div></d=
iv><span id=3D"OLK_SRC_BODY_SECTION"><div><div><div
dir=3D"auto"><div><div class=
=3D"gmail_extra"><div class=3D"gmail_quote">On Jan 18, 2018
5:29 PM, "Jayme" <=
;<a href=3D"mailto:jaymef@gmail.com">jaymef@gmail.com</a>>
wrote:<br type=3D"=
attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0
.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div
dir=3D"ltr"><div>I'm still deciding on s=
torage 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 qui=
te well as
a disaster recovery solution but I'd also need historical/incremental back=
ups as well, either of the VMs or at the very least some important files wit=
hin such as production DBs etc, which may be possible with a secondary backu=
p method using rsync or something
along those lines.
<br></div></div></blockquote></div></div></div><div
dir=
=3D"auto"><br></div><div dir=3D"auto">-Gluster
has a geo-replication based backu=
p which is very cool and integrated to oVirt UI. </div><div
dir=3D"auto">=
<br></div><div dir=3D"auto"><div
class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px
#ccc soli=
d;padding-left:1ex"><div
dir=3D"ltr"><div><br></div>
It seems to me that there is not a great backup solution for oVirt yet whic=
h 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 tha=
t 4.2 would change that and allow for easier
more resource efficient backing solutions.
<br></div></blockquote></=
div></div></div><div
dir=3D"auto"><br></div><div dir=3D"auto">-It
certainly does=
. See the DR work (and youtube video). </div><div
dir=3D"auto">-Y. <=
/div></div></div></div></span><div><br></div><div><br></div><div>**
I have y=
et to see a working script that does a VM backup from oVirt 4.2 to NFS stora=
ge?? I have spent days testing and trying all the scripts I can find, most a=
re old and all seem to fail in different ways. I have even coded my own scri=
pt using bash/curl/RestAPI and hit a dead end there as well with not finding=
any docs on how to backup an inactive disk from a attached snapshot. You=
217;d think oVirt would have something better for a DR solution or at least =
make it so you dont have to become an oVirt Dev Contributor to be able to ba=
ckup your Vms? **</div><div><br></div><div>I would love to
see a clear examp=
le of how to do VM backups from the command line in a script so I can move o=
n to rolling out oVirt 4.2
;)</div><div><br></div><div>Zip</div><span
id=3D"OL=
K_SRC_BODY_SECTION"><div><div><div
dir=3D"auto"><div
dir=3D"auto"><br></div><div=
dir=3D"auto"><div class=3D"gmail_extra"><div
class=3D"gmail_quote"><blockquote cl=
ass=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left=
:1ex"><div dir=3D"ltr"></div><div
class=3D"elided-text"><div class=3D"gmail_extra"=
<br><div class=3D"gmail_quote">On Thu, Jan 18,
2018 at 11:08 AM, Dan Yasny <s=
pan dir=3D"ltr">
<<a href=3D"mailto:dyasny@gmail.com"
target=3D"_blank">dyasny(a)gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">If
you are usi=
ng NFS, you might find it easier and more efficient to use a solution outsid=
e oVirt.
<div><br></div><div>I've documented an initial attempt at
backing up machin=
e images with backy2 at <a
href=3D"https://dyasny.blogspot.ca/2017/06/exp=
loring-backup-options-for-rhvovirt.html"
target=3D"_blank">https://dyasny.blog=
spot.ca/<wbr>2017/06/exploring-backup-optio<wbr>ns-for-rhvovirt.html</a></di=
v><div><br></div><div>It is harder to do with block storage and
frankly I ha=
ven't had the time to get to doing it there, but NFS is simple enough, and w=
hat you get is pretty robust, deduplicated backup, in some ways similar to t=
he 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=3D"gmail_extra"><br><div
class=3D"gmail_quote"><div><div =
class=3D"m_-8177657368668125289h5">On Thu, Jan 18, 2018 at 9:59 AM, Jayme
<spa=
n dir=3D"ltr">
<<a href=3D"mailto:jaymef@gmail.com"
target=3D"_blank">jaymef(a)gmail.com</a>&=
gt;</span> wrote:<br></div></div><blockquote
class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div
class=3D"=
m_-8177657368668125289h5"><div
dir=3D"ltr"><div><div><div>I've been running a =
non-production oVirt setup for a while and plan on building a more robust oV=
irt 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 sta=
rting to look at bacchus as well although have not set it up or tested bacch=
us 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 s=
napshot, clone, export. A lot of resource usage. I assume bacchu=
s 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 a=
re:<br></div><div><br></div><div>1. It's using old
3x api -- which is fine f=
or now but probably not with oVirt 4.3<br></div><div>2. Inefficient /
resour=
ce 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 Expor=
t domain is depreciated. I assume that this means that instead of a ex=
port 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 a=
lso read that it might be possible to skip the cloning of the VM part and ex=
port 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 tha=
t?</div><div><br></div><div>Essentially all I want is a
simple solution to b=
ackup my VMs to separate NFS storage. If for some reason my main stora=
ge crashes I then have the option to connect that backup NFS storage to a se=
condary stand alone oVirt instance and run my VMs from there
until the primary oVirt instance is repaired. What I want to a=
void 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 futur=
e.
<br></div><div><br></div><div>I know options like
active-active failover an=
d georeplication exist but that may be too complex for my needs although I w=
ould be interested in hearing about how some of you may be implementing thes=
e 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 i=
mplement 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=3D"mailto:Users@ovirt.org"
target=3D"_blank">User=
s(a)ovirt.org</a><br><a
href=3D"http://lists.ovirt.org/mailman/listinfo/users" r=
el=3D"noreferrer"
target=3D"_blank">http://lists.ovirt.org/mailman<wbr>/...
/users</a><br><br></blockquote></div><br></div></blockquote></div><br></div>=
</div><br>
______________________________<wbr>_________________<br>
Users mailing list<br><a
href=3D"mailto:Users@ovirt.org">Users@ovirt.org</a><=
br><a href=3D"http://lists.ovirt.org/mailman/listinfo/users"
rel=3D"noreferrer" =
target=3D"_blank">http://lists.ovirt.org/<wbr>mailman/...
r></blockquote></div><br></div></div></div></div></div></span></body></html>
--B_3599164006_104503654--
2499
days inactive
2500
days old
6 comments
4 participants
participants (4)
-
Dan Yasny -
Jayme -
Yaniv Kaul -
Zip