> On Wed, 1 Apr 2020 16:02:59 +0200, Pierre Bernhardt said:
>
> I think to correct the problems on existing backups a bscan -m -s should also
> fix this issues permanently so a patch of bscan is needed, too.
AFAICS (I've not tried it), bscan will not fail if it gets these errors. It
will
Am 01.04.20 um 15:19 schrieb Martin Simmons:
> Yes, I think 1 is the best solution, but it will not fix existing backups.
>
> Migration could also be changed to allow certain types of error, like restore
> does with the "Restore OK -- with errors" status.
I think to correct the problems on
> On Wed, 1 Apr 2020 11:36:22 +0200, Pierre Bernhardt said:
>
> Am 01.04.20 um 00:25 schrieb Pierre Bernhardt:
> > Am 01.04.20 um 00:11 schrieb Pierre Bernhardt:
> > So now I restarted again a migration to check the result.
>
> Here the content from the migration job:
> The migration back to
Am 01.04.20 um 00:25 schrieb Pierre Bernhardt:
> Am 01.04.20 um 00:11 schrieb Pierre Bernhardt:
> So now I restarted again a migration to check the result.
Here the content from the migration job:
The migration back to the tape has now been finshed without problems:
01-Apr 00:19 backup-dir JobId
i running bacula 9.0.6 on ubuntu 18.04. Backup of clients is ok. but get
error for catalog backup: Cannot find any appendable volumes.
And in my libbacsd-9.0.6.so:
strings libbacsd-9.0.6.so | grep short
Volume data error at %s! Very short block of %d bytes on device %s
discarded.
i created
Am 01.04.20 um 00:11 schrieb Pierre Bernhardt:
> In which installed files is block.c and read_records.c used?
> I compiled all but repaced only the bacula-sd files. Maybe the modification
> is located in another file and not in the binary?
Ok, I found the file by using grep:
Am 31.03.20 um 22:07 schrieb Pierre Bernhardt:
>> Your change to use M_INFO looks correct, but the block.c:682 message in the
>> log still says "Error:" so you are still running the original code. Did you
>> run "make" and "make install" after changing the code? Did they complete
>> without
Am 31.03.20 um 17:05 schrieb Martin Simmons:
>> On Tue, 31 Mar 2020 12:40:04 +0200, Pierre Bernhardt said:
>>
>> Am 30.03.20 um 16:12 schrieb Martin Simmons:
>> Hello,
>>
>>
>> I think the return line should be corrected by changing the false? I'm
>> virgin coding
>> c++ ;-)
>>
>>if
> On Tue, 31 Mar 2020 12:40:04 +0200, Pierre Bernhardt said:
>
> Am 30.03.20 um 16:12 schrieb Martin Simmons:
> Hello,
>
> > You could try temporarily hacking bacula-sd to report the short block as an
> > info message. In src/stored/block.c, change M_ERROR to M_INFO in these
> > lines:
> >
Am 30.03.20 um 16:12 schrieb Martin Simmons:
Hello,
> You could try temporarily hacking bacula-sd to report the short block as an
> info message. In src/stored/block.c, change M_ERROR to M_INFO in these lines:
>
> Mmsg4(dev->errmsg, _("[SE0208] Volume data error at %u:%u! Short block
>
> On Fri, 27 Mar 2020 21:48:29 +0100, Pierre Bernhardt said:
>
> Am 27.03.20 um 21:26 schrieb Pierre Bernhardt:
> > Am 27.03.20 um 18:26 schrieb Martin Simmons:
>
> >>> Any idea how I can extract the single data für fileindex 932145 from the
> >>> disks for comparing?
> >>> If the short
Am 27.03.20 um 21:26 schrieb Pierre Bernhardt:
> Am 27.03.20 um 18:26 schrieb Martin Simmons:
>>> Any idea how I can extract the single data für fileindex 932145 from the
>>> disks for comparing?
>>> If the short block is only repeated as whole block on the next disk the
>>> problem could be
Am 27.03.20 um 18:26 schrieb Martin Simmons:
Hi,
>> Any idea how I can extract the single data für fileindex 932145 from the
>> disks for comparing?
>> If the short block is only repeated as whole block on the next disk the
>> problem could be fixed
>> by modify the database so the short block
> On Thu, 26 Mar 2020 23:31:43 +0100, Pierre Bernhardt said:
>
> Am 26.03.20 um 16:48 schrieb Martin Simmons:
> > Looks like a bug to me, but a possible workaround is to limit the size of
> > your
> Me2. If the short block is correctly identified at writing it should be
> repeated
> or
Am 26.03.20 um 16:48 schrieb Martin Simmons:
> Looks like a bug to me, but a possible workaround is to limit the size of your
Me2. If the short block is correctly identified at writing it should be repeated
or should be finished on the new disk. In both cases the data on the disks
should
be ok.
Am 26.03.20 um 14:06 schrieb Josh Fisher:
> On 3/25/2020 3:23 PM, Pierre Bernhardt wrote:
> And what is the Autochanger / Device configurations for the disk storage in
> bacula-sd.conf?
Device {
Name = DiskStorage1
Media Type = Disk
Device Type = File
Archive Device = /media/baculadisk1
Looks like a bug to me, but a possible workaround is to limit the size of your
disk volumes (see Maximum Volume Bytes) to avoid filling the disks during the
backup. This will avoid the "short block" when you migrate.
BTW, can you post the log from jobid 47704 as well?
__Martin
> On Wed,
On 3/25/2020 3:23 PM, Pierre Bernhardt wrote:
Am 24.03.20 um 22:39 schrieb Pierre Bernhardt:
Today I tried to migrate again the job which uses two disk files.
But now I tried to put both files in one directory (I used my second
bay to mount the DISK017 file) and used a symbolic link:
-rw-rw-r--
Am 24.03.20 um 22:39 schrieb Pierre Bernhardt:
>
Today I tried to migrate again the job which uses two disk files.
But now I tried to put both files in one directory (I used my second
bay to mount the DISK017 file) and used a symbolic link:
-rw-rw-r-- 1 bacula tape 972406571008 Mar 24 17:10
19 matches
Mail list logo
