<div dir="ltr">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</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 2, 2017 at 8:31 AM, Pavel Gashev <span dir="ltr"><<a href="mailto:Pax@acronis.com" target="_blank">Pax@acronis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maor,<br>
<br>
Could you please clarify, what would be the process of making backup of a running VM to an existing backup storage domain?<br>
<br>
I’m asking because it looks like the process is going to be quite the same:<br>
1. Clone VM from a snapshot<br>
2. Move the cloned VM to a backup storage domain<br>
<br>
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.<br>
<br>
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.<br>
<span class="im HOEnZb"><br>
<br>
On 01/10/2017, 15:32, "<a href="mailto:users-bounces@ovirt.org">users-bounces@ovirt.org</a> on behalf of Maor Lipchuk" <<a href="mailto:users-bounces@ovirt.org">users-bounces@ovirt.org</a> on behalf of <a href="mailto:mlipchuk@redhat.com">mlipchuk@redhat.com</a>> wrote:<br>
<br>
On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer <<a href="mailto:nsoffer@redhat.com">nsoffer@redhat.com</a>> wrote:<br>
><br>
</span><span class="im HOEnZb"> > Attaching and detaching data domain was not designed for backing up vms.<br>
> How would you use it for backup?<br>
><br>
> How do you ensure that a backup clone of a vm is not started by mistake,<br>
> changing the backup contents?<br>
<br>
That is a good question.<br>
We recently introduced a new feature called "backup storage domain"<br>
which you can mark the storage domain as backup storage domain.<br>
That can guarantee that no VMs will run with disks/leases reside on<br>
the storage domain.<br>
The feature should already exist in oVirt 4.2 (despite a bug that<br>
should be handled with this patch <a href="https://gerrit.ovirt.org/#/c/81290/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>81290/</a>)<br>
You can find more information on this here:<br>
<a href="https://github.com/shubham0d/ovirt-site/blob/41dcb0f1791d90d1ae0ac43cd34a399cfedf54d8/source/develop/release-management/features/storage/backup-storage-domain.html.md" rel="noreferrer" target="_blank">https://github.com/shubham0d/<wbr>ovirt-site/blob/<wbr>41dcb0f1791d90d1ae0ac43cd34a39<wbr>9cfedf54d8/source/develop/<wbr>release-management/features/<wbr>storage/backup-storage-domain.<wbr>html.md</a><br>
<br>
Basically the OVF that is being saved in the export domain should be<br>
similar to the same one that is being saved in the OVF_STORE disk in<br>
the storage domain.<br>
If the user manages replication on that storage domain it can be<br>
re-used for backup purposes by importing it to a setup.<br>
Actually it is much more efficient to use a data storage domain than<br>
to use the copy operation to/from the export storage domain.<br>
<br>
><br>
> Nir<br>
</span><div class="HOEnZb"><div class="h5"> ______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
<br>
<br>
</div></div></blockquote></div><br></div>