>>>>> 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 the tape has now been finshed without problems:
Great! > 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? Yes, the workaround is a bad solution because it might hide real errors. > 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. 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. __Martin _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
