>>>>> 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 Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users