ovirt restore error when backup are import from remote archive.

[levindecaro]

when a backup volume copy over to another bareos server, after bscan volume import , restore will fail on extracting "effective_size" step. Current workaround is hardcoding effective_size with a large enough value to treat ovirt to finish it until EOF.

bareos-fd (150): filed/python-fd.cc:1109-52 python-fd: Traceback (most recent call last):

  File "/usr/lib64/bareos/plugins/BareosFdWrapper.py", line 66, in create_file

    return bareos_fd_plugin_object.create_file(context, restorepkt)

  File "/usr/lib64/bareos/plugins/BareosFdPluginOvirt.py", line 311, in create_file

    self.ovirt.start_upload(context, disk)

  File "/usr/lib64/bareos/plugins/BareosFdPluginOvirt.py", line 1711, in start_upload

    effective_size = self.disk_metadata_by_id[old_id]["effective_size"]

KeyError: ('844be452-028f-421d-947c-35fa3051c894',)

[levindecaro]

I managed to know the root cause of this issue.

It is because ObjectType "25" from original backupset wasn't import by bscan to target bareos, they appeared "0" in RestoreObject table -> ObjectType col for all /VMS/XXXXX.metadata , therefore, when the ovirt plugin trying to retrieve the effective_size from disk_metadata from RestoreObject table, it will return null.

The current workaround is manually patch the ObjectType to 25 for those VMS RestoreObject after bscan.

Another issue encountered from PluginName tinyblob column type can't fit all plugin data into the column, and ultimately trimmed the VM name during ovirt restore.

The current workaround is modify the PluginName col to longblob.

[Stephan Duehr]

Hi,

indeed bscan does not recover RestoreObject data correctly. I've also verified that this is not an oVirt plugin specfic problem, any
plugin that uses restore objects would be affected.

Regards,

Stephan

On 5/2/20 12:23 PM, levindecaro wrote:
> I managed to know the root cause of this issue.
>
> It is because ObjectType "25" from original backupset wasn't import by bscan to target bareos, they appeared "0" in RestoreObject table -> ObjectType col for all /VMS/XXXXX.metadata , therefore, when the ovirt plugin trying to retrieve the effective_size from disk_metadata from RestoreObject table, it will return null.
>

> *The current workaround is manually patch the ObjectType to 25 for those VMS RestoreObject after bscan.*

>
> Another issue encountered from PluginName tinyblob column type can't fit all plugin data into the column, and ultimately trimmed the VM name during ovirt restore.
>

> *The current workaround is modify the PluginName col to longblob.*

>
>
>
>
>
>
>
> On Friday, May 1, 2020 at 2:11:06 AM UTC+8, levindecaro wrote:
>
> when a backup volume copy over to another bareos server, after bscan volume import , restore will fail on extracting "effective_size" step. Current workaround is hardcoding effective_size with a large enough value to treat ovirt to finish it until EOF.
>
>
>
> bareos-fd (150): filed/python-fd.cc:1109-52 python-fd: Traceback (most recent call last):
>   File "/usr/lib64/bareos/plugins/BareosFdWrapper.py", line 66, in create_file
>     return bareos_fd_plugin_object.create_file(context, restorepkt)
>   File "/usr/lib64/bareos/plugins/BareosFdPluginOvirt.py", line 311, in create_file
>     self.ovirt.start_upload(context, disk)
>   File "/usr/lib64/bareos/plugins/BareosFdPluginOvirt.py", line 1711, in start_upload
>     effective_size = self.disk_metadata_by_id[old_id]["effective_size"]
> KeyError: ('844be452-028f-421d-947c-35fa3051c894',)
>

> --
> You received this message because you are subscribed to the Google Groups "bareos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users...@googlegroups.com <mailto:bareos-users...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/867d4e5f-cdf0-4cf0-8c3e-101e6b540f5b%40googlegroups.com <https://groups.google.com/d/msgid/bareos-users/867d4e5f-cdf0-4cf0-8c3e-101e6b540f5b%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Stephan Dühr stepha...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221-630693-90
http://www.bareos.com

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: S. Dühr, M. Außendorf, J. Steffens, Philipp Storz

[Wai Ho Levin Ng]

Hi Stephen,

Thanks for your explanation, do u have idea how to solve it in proper way?

Regards
Levin

> On 12 May 2020, at 02:31, Stephan Duehr <stepha...@bareos.com> wrote:
>
> Hi,

> To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/e21b4021-78e9-4a45-bbc1-c6c8ded55509%40bareos.com.

[Stephan Duehr]

I've create the PR https://github.com/bareos/bareos/pull/516 which will fix this issue.

Regarding MySQL: Changing the PluginName column to longblob should be no problem, as for PostgreSQL this column is TEXT,
so I don't expect any length problem. Please also consider migration to PostgreSQL, see
https://docs.bareos.org/Appendix/Howtos.html#section-migrationmysqltopostgresql

Regards,

Stephan

[levindecaro]

Thanks Stephan, another question I don't know if you can answer too, regarding on  the ovirt plugin limitation "Error '%s' already have snapshosts. This is not supported\n", do you know what rationale that aren't support snapshot existent. 

>> To unsubscribe from this group and stop receiving emails from it, send an email to bareos...@googlegroups.com <mailto:bareos-users+unsub...@googlegroups.com>.