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.
On Tuesday, May 12, 2020 at 10:36:24 PM UTC+8, Stephan Duehr wrote: > > 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 > > On 5/11/20 8:31 PM, Stephan Duehr wrote: > > 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 [email protected] <javascript:> <mailto: > [email protected] <javascript:>>. > >> 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 [email protected] > <javascript:> > 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 > -- 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/90140d2b-d6ea-44eb-a345-44c523ae1669o%40googlegroups.com.
