deed 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
in 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
> v
]
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
> volu
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):
Hi, I just configured a backup job with latest ovirt-plugin followed the
guide from
https://docs.bareos.org/TasksAndConcepts/Plugins.html#ovirt-plugin ,
however it seems doesn't allow to include multiple VM for a single job.
Anyone here have successfully run a backup job with multiple VM
a 4G
> file even though the maximum disk size is 30G you'd have a 4G file. But
> it wouldn't be a sparse file.
>
> If it were a sparse file, the filesystem would report a file size of 30G
> but with only 4G of actual contents.
>
>
> I hope I'm not making this overly confus
Hi,
I'm using bareos 18.2, to backup bunch of ova files exported from RHEV, the ova
file size is the actual used size of the image after export(thin image).
However bareos still allocate the real size of image during backup or restore.
The sparse=yes options seems cannot handle ova files.
