further test today with restore Catalog all together, smooth restoration
without any workaround, i think the following implementation was lack of
handling independent restore approach.
# To prevent from errors on transfer, the exact number of bytes that
# will be sent must be used, we call it effective_size here. It was
# saved at backup time in restoreobjects, see start_backup_file(),
# and restoreobjects are restored before any file.
new_old_ids = {v: k for k, v in self.old_new_ids.items()}
old_id = new_old_ids[disk.id]
effective_size = self.disk_metadata_by_id[old_id]["effective_size"]
self.init_bytes_to_transf = self.bytes_to_transf = effective_size
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/bareos-users/32b5d254-781e-4551-8e03-28404648009d%40googlegroups.com.
