BTRFS detected an checksum error on a dblock.zip.aes file. Now what?

As the title says, BTRFS detected a checksum error on one dblock.zip.aes file.

The $affected command shows a list of 88 files, all belonging to the last backup.

What are my options, considering this is a > 2 TB online Backup?

Would it be possible to remove this block / remove these files from Backup in a clean way? How can I make duplicati delete or restructure this block?

Can Duplicati check only a specific block?

Thank you in advance for any suggestions.

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.

1 Like

Thank you for your helpful message. Since I don’t have a lot of time in my hands I followed what should be the easiest way.

I deleted the .block file, after backup it, and now btrfs doesn’t complain.

The list-broken-files command went well:

> .\Duplicati.CommandLine.exe list-broken-files "ssh://server.server.org:2222//srv/dev-disk-by-label-blabla/01Backups/01DuplicatiPT/?auth-username=USER&auth-password=Password&ssh-fingerprint=ssh-ed255etete0256%2rere%3Arer%3Aeeerera%3Ad4%3A98%3A09%3Ad6%3A62%3A3e%3Aec%3Af0%3Ab1%3A96%3Adc%3A1d" --dbpath=C:\Users\USER\AppData\Local\Duplicati\SEEOQSAC.sqlite --full-result

but the purge-broken-files came back with this error:

C:\Program Files\Duplicati 2> .\Duplicati.CommandLine.exe purge-broken-files "ssh://server.server.org:2222//srv/dev-disk-by-label-blabla/01Backups/01DuplicatiPT/?auth-username=USER&auth-password=Password&ssh-fingerprint=ssh-ed255etete0256%2rere%3Arer%3Aeeerera%3Ad4%3A98%3A09%3Ad6%3A62%3A3e%3Aec%3Af0%3Ab1%3A96%3Adc%3A1d" --dbpath=C:\Users\USER\AppData\Local\Duplicati\SEEOQSAC.sqlite --full-result
> 
> Enter encryption passphrase: Password
>   Listing remote folder ...
> The operation PurgeBrokenFiles has failed with error: You have attempted to change a passphrase to an existing backup, which is not supported. Please configure a new clean backup if you want to change the passphrase. => You have attempted to change a passphrase to an existing backup, which is not supported. Please configure a new clean backup if you want to change the passphrase.
> 
> ErrorID: PassphraseChangeNotSupported
> You have attempted to change a passphrase to an existing backup, which is not supported. Please configure a new clean backup if you want to change the passphrase.

Any idea? This error seems strange here.

As you ran it true CLI, you might have added or omitted an option that your GUI job would use. Seeing that you have .zip.aes files, I would expect CLI would need at least a --passphrase.

Because none was given, you got prompted for it. Possibly you typed a different one somehow.

Thank you. It didn’t work because the password was wrong. Apparently, for the list-broken-files command the password is needed for input but not used, that’s why I thought the password was right for the purge-broken-files command.

The issue is solved. BTRFS and Duplicati are both happy.

2 Likes

I don’t know the code, but I think the list-broken-files can be done with a file listing and the information in the job database, which knows what files should be there, and which Source files contain blocks that are in the lost file. purge-broken-files has to upload new dlist files with adjusted contents to reflect the purge – so if encryption is in use, it has to actually do encryption.