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 47775: The following 1 JobId was chosen to be migrated: 47704 01-Apr 00:19 backup-dir JobId 47775: Migration using JobId=47704 Job=nihilnihil_home.2020-03-21_20.23.31_49 01-Apr 00:19 backup-dir JobId 47775: Start Migration JobId 47775, Job=MigrateFile2Drive.2020-04-01_00.19.07_04 01-Apr 00:19 backup-dir JobId 47775: Using Device "DiskStorage2" to read. 01-Apr 00:19 backup-sd JobId 47775: Ready to read from volume "DISK016" on File device "DiskStorage2" (/media/baculadisk2). 01-Apr 00:19 backup-sd JobId 47775: Forward spacing Volume "DISK016" to addr=217 01-Apr 05:27 backup-sd JobId 47775: block.c:682 [SE0208] Volume data has error at 0:0! Short block of 57010 bytes on device "DiskStorage2" (/media/baculadisk2) discarded. 01-Apr 05:27 backup-sd JobId 47775: read_records.c:160 block.c:682 [SE0208] Volume data has error at 0:0! Short block of 57010 bytes on device "DiskStorage2" (/media/baculadisk2) discarded. 01-Apr 05:27 backup-sd JobId 47775: End of Volume "DISK016" at addr=972406571008 on device "DiskStorage2" (/media/baculadisk2). 01-Apr 05:28 backup-sd JobId 47775: Ready to read from volume "DISK017" on File device "DiskStorage2" (/media/baculadisk2). 01-Apr 05:28 backup-sd JobId 47775: Forward spacing Volume "DISK017" to addr=213 01-Apr 06:27 backup-sd JobId 47775: End of Volume "DISK017" at addr=110838477984 on device "DiskStorage2" (/media/baculadisk2). 01-Apr 06:27 backup-sd JobId 47775: Elapsed time=06:07:56, Transfer rate=49.02 M Bytes/second 01-Apr 08:30 backup-dir JobId 47775: Bacula backup-dir 9.4.2 (04Feb19): Build OS: x86_64-pc-linux-gnu debian buster/sid Prev Backup JobId: 47704 Prev Backup Job: nihilnihil_home.2020-03-21_20.23.31_49 New Backup JobId: 47776 Current JobId: 47775 Current Job: MigrateFile2Drive.2020-04-01_00.19.07_04 Backup Level: Full Client: backup-fd FileSet: "Full Set" 2017-10-09 08:53:50 Read Pool: "Migrate" (From Job resource) Read Storage: "Disk2" (From Pool resource) Write Pool: "Monthly" (From Job Pool's NextPool resource) Write Storage: "FibreCAT TX48 S2" (From Job Pool's NextPool resource) Catalog: "MyCatalog" (From Client resource) Start time: 01-Apr-2020 00:19:11 End time: 01-Apr-2020 08:25:40 Elapsed time: 8 hours 6 mins 29 secs Priority: 21 SD Files Written: 1,030,385 SD Bytes Written: 1,082,331,572,757 (1.082 TB) Rate: 37080.1 KB/s Volume name(s): LTO40025|LTO40026 Volume Session Id: 1 Volume Session Time: 1585692943 Last Volume Bytes: 270,297,861,120 (270.2 GB) SD Errors: 0 SD termination status: OK Termination: Migration OK Here from migration-backup job: 01-Apr 00:19 backup-dir JobId 47776: Recycled current volume "LTO40025" 01-Apr 00:19 backup-dir JobId 47776: Using Device "HPUltrium4-2" to write. 01-Apr 00:19 backup-sd JobId 47776: Recycled volume "LTO40025" on Tape device "HP Ultrium 4-2" (/dev/tape/by-id/scsi-HU19145705-nst), all previous data lost. 01-Apr 04:30 backup-sd JobId 47776: [SI0202] End of Volume "LTO40025" at 812:15489 on device "HP Ultrium 4-2" (/dev/tape/by-id/scsi-HU19145705-nst). Write of 64512 bytes got -1. 01-Apr 04:30 backup-sd JobId 47776: Re-read of last block succeeded. 01-Apr 04:30 backup-sd JobId 47776: End of medium on Volume "LTO40025" Bytes=812,947,258,368 Blocks=12,601,488 at 01-Apr-2020 04:30. 01-Apr 04:30 backup-sd JobId 47776: 3307 Issuing autochanger "unload Volume LTO40025, Slot 17, Drive 1" command. 01-Apr 04:32 backup-dir JobId 47776: Recycled volume "LTO40026" 01-Apr 04:32 backup-sd JobId 47776: 3304 Issuing autochanger "load Volume LTO40026, Slot 9, Drive 1" command. 01-Apr 04:34 backup-sd JobId 47776: 3305 Autochanger "load Volume LTO40026, Slot 9, Drive 1", status is OK. 01-Apr 04:34 backup-sd JobId 47776: Recycled volume "LTO40026" on Tape device "HP Ultrium 4-2" (/dev/tape/by-id/scsi-HU19145705-nst), all previous data lost. 01-Apr 04:34 backup-sd JobId 47776: New volume "LTO40026" mounted on device "HP Ultrium 4-2" (/dev/tape/by-id/scsi-HU19145705-nst) at 01-Apr-2020 04:34. 01-Apr 06:30 backup-sd JobId 47776: Elapsed time=06:07:02, Transfer rate=49.14 M Bytes/second 01-Apr 06:30 backup-sd JobId 47776: Sending spooled attrs to the Director. Despooling 300,838,146 bytes ... I've compared the file which was stored in the short block: The restored file from the migration to tape has the same sha1sum as the one which I restored from the two disks and the original file. So my problem is solved for the moment and I can continue to migrate. I've bought now a bigger disk for this migration so I should not get the same problem again because all single jobs will fit on this disk. I will open a bug report with all details from this discussion. By the way, do you have an idea how it should be fixed? I think, this workaround is not the correct solution, isn't it? In my opinion at the time the job has to been written and splitted to the disks there two solutions possible: At the end the unexpected file write has been identified and before the next disk has to been ask for: 1. The short block should be truncated and not written to the database or 2. The short block should be ignored to write to the database. or 3. The short block should be marked as invalid in the database and should be ignored. After this step the block should be rewritten on the next volume. 1. looks like me for the cleanest solution because in read this block is not there 2. looks like me a little bit problematic because if eg. bscan is used it must also fix/ignore this block. 3. this is a good solution if there exists already mechanism in all tools and bacule to ignore such parts in backup volume data. Thanks for help, Pierre _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
