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+unsubscr...@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.
