[ovirt-users] deprecating export domain?

[shubham dubey]

Yes, I just gave an example case. If you want to use vms with a backup,
then you can just copy that vm or disk into another domain and make it as
backup domain as you do it in export domain.
In simple language, main aim of creating backup domain is just to use all
the features available in export domain without creating a dedicated export
domain.
Hope you understand now:)



On 2 Oct 2017 8:55 pm, "Pavel Gashev" <Pax at acronis.com> wrote:

> Shubham,
>
>
>
> I don’t really understand the process you described. If I need to backup
> the whole datacenter, you say I have to turn off all VMs, and make them
> non-runnable. It doesn’t look like a backing up. It looks like an
> archiving. But what if I need to keep my VMs running?
>
>
>
>
>
> *From: *shubham dubey <sdubey504 at gmail.com>
> *Date: *Monday, 2 October 2017 at 15:55
> *To: *Charles Kozler <ckozleriii at gmail.com>
> *Cc: *Pavel Gashev <Pax at acronis.com>, users <users at ovirt.org>, Maor
> Lipchuk <mlipchuk at redhat.com>
> *Subject: *Re: [ovirt-users] deprecating export domain?
>
>
>
> Hi,
>
> The backup storage domain is quite like export storage domain but with
> easy usability.
>
> Since you can change any data domain into backup domain any time, you not
> need to create a dedicated
>
> export storage domain for backup or disaster recovery purpose. Altough its
> working is same as export sd.
>
> The process of backup can be as simple as this:
>
> 1) turn off all the vms in your storage domain
>
> 2) select backup flag to convert that into backup domain.
>
> Once the domain is used for backup, you cannot make any changes to its
> vms, disk etc as mentioned by maor.
>
> And yes, you can convert export sd to data domain using cli script but it
> is not required anymore.
>
> If in future export storage domain get deprecated, you not need to be
> worry about that much since you can convert all your
>
> export sd into data domain anytime and start using backup feature instead.
>
> Regards,
>
> Shubham
>
>
>
>
>
> On Mon, Oct 2, 2017 at 6:04 PM, Charles Kozler <ckozleriii at gmail.com>
> wrote:
>
> Thank you for clearing this up for me everyone. My concern that something
> like the export domain wasnt going to exist and it was just going to be
> deprecated with no alternative. Glad to hear all the news of the SD
>
>
>
> On Mon, Oct 2, 2017 at 8:31 AM, Pavel Gashev <Pax at acronis.com> wrote:
>
> Maor,
>
> Could you please clarify, what would be the process of making backup of a
> running VM to an existing backup storage domain?
>
> I’m asking because it looks like the process is going to be quite the same:
> 1. Clone VM from a snapshot
> 2. Move the cloned VM to a backup storage domain
>
> An ability of choosing destination storage for cloned VMs would increase
> backup efficiency. On the other hand, an ability of exporting VM from a
> snapshot would increase the efficiency in the same way even without
> creating new entity.
>
> Indeed, Backup SDs would increase efficiency of disaster recovery. But the
> same would be achieved by converting Export SDs to Data SDs using a small
> CLI utility.
>
>
> On 01/10/2017, 15:32, "users-bounces at ovirt.org on behalf of Maor Lipchuk"
> <users-bounces at ovirt.org on behalf of mlipchuk at redhat.com> wrote:
>
>     On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer <nsoffer at redhat.com> wrote:
>     >
>     > Attaching and detaching data domain was not designed for backing up
> vms.
>     > How would you use it for backup?
>     >
>     > How do you ensure that a backup clone of a vm is not started by
> mistake,
>     > changing the backup contents?
>
>     That is a good question.
>     We recently introduced a new feature called "backup storage domain"
>     which you can mark the storage domain as backup storage domain.
>     That can guarantee that no VMs will run with disks/leases reside on
>     the storage domain.
>     The feature should already exist in oVirt 4.2 (despite a bug that
>     should be handled with this patch https://gerrit.ovirt.org/#/c/81290/)
>     You can find more information on this here:
>       https://github.com/shubham0d/ovirt-site/blob/
> 41dcb0f1791d90d1ae0ac43cd34a399cfedf54d8/source/develop/
> release-management/features/storage/backup-storage-domain.html.md
>
>     Basically the OVF that is being saved in the export domain should be
>     similar to the same one that is being saved in the OVF_STORE disk in
>     the storage domain.
>     If the user manages replication on that storage domain it can be
>     re-used for backup purposes by importing it to a setup.
>     Actually it is much more efficient to use a data storage domain than
>     to use the copy operation to/from the export storage domain.
>
>     >
>     > Nir
>
>     _______________________________________________
>     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/20171002/ccaed6af/attachment.html>