Сommand LIST-BROKEN-FILES gives an empty list of files. I don’t know how to restore the archive so that command TEST does not produce errors. Help me please Вackup was made every day, no errors occurred. And today such an error suddenly appeared, before that, verification always went fine
Do you test all the files this way every day? This looks like testall samples with –full-remote-verification which is quite a lot. If you’re trying to make sure that a backup will restore, there are likely better methods, such as occasionally doing an actual restore with –no-local-blocks, or direct restore onto another system.
Verify a specific dblock.zip.aes file seems to say it shouldn’t happen, but it’s harmless extra copies. Doing a restore could test that if you can figure out the files affected by that dblock. The AFFECTED command is possibly just the right tool, and Disaster Recovery shows a lab example of an intentional dblock corruption.
How to recover backup with damaged dblock file? is where I looked over one of my cases of this, and saw sort of how it happened, and thought it was just extra copies. Might not apply in all cases, but it did in mine.
What happened to me was that a compact put these blocks in a new dblock file, deleted some empty dblock files, then put these blocks into the next dblock file too.
So you could also check your backup job logs just before this error, and see whether it shows a compact. Checking the date on duplicati-b9c81549160244373adc1dc08f9c3291e.dblock.zip can also show when it was created. Files don’t generally change once made, but backups, compacts, etc. can create new ones.
Вackup was made every day, no errors occurred. And today such an error suddenly appeared, before that, verification always went fine