>>>>> 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 block is only repeated as whole block on the next disk the
> >>> problem could be fixed
> >>> by modify the database so the short block will not be read or by
> >>> truncating at short block on
> >>> the DISK016 (?)
> >> You can find the filename for fileindex 932145 by running bscan -r -vv and
> >> then do a restore for that filename.
>
> > By the way the restore (with bconsole?) will be work without getting a
> > problem? I will
> > try to do it.
>
> 27-Mar 21:27 backup-sd JobId 47756: Ready to read from volume "DISK016" on
> File device "DiskStorage2" (/media/baculadisk2).
> 27-Mar 21:27 backup-sd JobId 47756: Forward spacing Volume "DISK016" to
> addr=971937834340
> 27-Mar 21:28 backup-sd JobId 47756: Error: block.c:682 [SE0208] Volume data
> error at 0:0! Short block of 57010 bytes on device "DiskStorage2"
> (/media/baculadisk2) discarded.
> 27-Mar 21:28 backup-sd JobId 47756: Error: read_records.c:160 block.c:682
> [SE0208] Volume data error at 0:0! Short block of 57010 bytes on device
> "DiskStorage2" (/media/baculadisk2) discarded.
> 27-Mar 21:28 backup-sd JobId 47756: End of Volume "DISK016" at
> addr=972406571008 on device "DiskStorage2" (/media/baculadisk2).
> 27-Mar 21:28 backup-sd JobId 47756: Ready to read from volume "DISK017" on
> File device "DiskStorage2" (/media/baculadisk2).
> 27-Mar 21:28 backup-sd JobId 47756: Forward spacing Volume "DISK017" to
> addr=213
> 27-Mar 21:28 backup-sd JobId 47756: End of Volume "DISK017" at addr=645332 on
> device "DiskStorage2" (/media/baculadisk2).
> 27-Mar 21:28 backup-sd JobId 47756: Elapsed time=00:00:15, Transfer
> rate=134.3 K Bytes/second
> 27-Mar 21:28 backup-dir JobId 47756: Bacula backup-dir 9.4.2 (04Feb19):
> Build OS: x86_64-pc-linux-gnu debian buster/sid
> JobId: 47756
> Job: RestoreFiles.2020-03-27_21.27.41_46
> Restore Client: nihilnihil-fd
> Where: /tmp/restore
> Replace: Always
> Start time: 27-Mar-2020 21:27:44
> End time: 27-Mar-2020 21:28:07
> Elapsed time: 23 secs
> Files Expected: 1
> Files Restored: 1
> Bytes Restored: 2,122,031 (2.122 MB)
> Rate: 92.3 KB/s
> FD Errors: 0
> FD termination status: OK
> SD termination status: OK
> Termination: Restore OK -- with errors 27-Mar 21:28 backup-dir
> JobId 47756: Begin pruning Jobs older than 99 years .
> 27-Mar 21:28 backup-dir JobId 47756: No Jobs found to prune.
> 27-Mar 21:28 backup-dir JobId 47756: Begin pruning Files.
> 27-Mar 21:28 backup-dir JobId 47756: No Files found to prune.
> 27-Mar 21:28 backup-dir JobId 47756: End auto prune.
>
> Looks like restoring has been worked although only with the shot block notice
> error message.
>
> Now use a newer backup from tape to restore the same file and compare them
> with sha256sum.
> Content and meta data are looks like correct after restore.
Good, so the short block was written to the next volume as expected.
> So my problem is only, because of failed migration because of short block
> notice, the
> migrated database entries will not transfered after the migration back from
> disk to tape
> has been proceed.
>
> Is there a way so I can finish the migration maybe by a workaround?
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 of
%d bytes on device %s discarded.\n"),
dev->file, dev->block_num, block->read_len, dev->print_name());
Jmsg(jcr, M_ERROR, 0, "%s", dev->errmsg);
I suggest you also report this as a bug to https://bugs.bacula.org/.
__Martin
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
