Welcome to the forum @c-1234
If you’re certain that the dblock is bad, you can delete it, then purge updates from those 88 files, which shouldn’t hurt much since it sounds like it’s not any old history, but just the latest changes.
Recovering by purging files
GUI Commandline is probably a good way to do this because it supplies the needed options, but potentially has others that don’t belong. The source file list for backup will definitely have to clear.
The LIST-BROKEN-FILES command
The PURGE-BROKEN-FILES command
It’s a manual delete. If you want to start gently, you can move the file or change the usual prefix. There’s not a restructure (Duplicati doesn’t know what bits went bad), but it gets replaced in the usual way on next backup, when changes in files are detected and packaged in another dblock.
If you mean test a specific dblock file to verify it’s broken, checking integrity is done by sampling.
Verifying backend files
The TEST command
Since your files are AES encrypted, you can manually test a file with AES Crypt if you like GUI, or
Usage: SharpAESCrypt e|d[o][1-4] <password> [<fromPath> [<toPath>]]
Use 'e' or 'd' to specify operation: encrypt or decrypt.
Append an 'o' to the operation for optimistic mode. This will skip some tests and leaves partial/invalid files on disk.
Append a single number (up to 4) to the operation to set the number of threads used for crypting. Default is single thread mode (1).
If you ommit the fromPath or toPath, stdin/stdout are used insted, e.g.:
SharpAESCrypt e 1234 < file.jpg > file.jpg.aes
Abnormal exit will return an errorlevel above 0 (zero):
4 - Password invalid
3 - HMAC Mismatch / altered data (also invalid password for version 0 files)
2 - Missing input stream / input file not found
1 - Any other cryptographic or IO exception
in the Duplicati installation folder if you like CLI.
EDIT:
Although it’s probably more work than a decrypt, Duplicati has a SHA-256 hash of all of its files.