RecoveryTool error

Support
1

I have backup from Debian encrypted with aes password. I try recovery files from Windows computer, but I get error

Operation Get with file duplicati-b1bd7fcdac9a1496db774129ca05a9cc2.dblock.zip.aes attempt 4 of 5 failed with message: Failed to decrypt data (invalid passphrase?): Invalid password or corrupted data

I try manual downloaded files

Duplicati.CommandLine.RecoveryTool.exe download “ssh://192.168.xx.xx/path?auth-username=xxx&auth-password=xxx” e:\aes --passphrase=“xxx” --ssh-accept-any-fingerprints

next I make index

Duplicati.CommandLine.RecoveryTool index e:\aes\zip2

and list the versions

Duplicati.CommandLine.RecoveryTool list e:\aes\zip

i can list the files

Duplicati.CommandLine.RecoveryTool list e:\aes\zip 0

and now I try revocer all files

Duplicati.CommandLine.RecoveryTool restore e:\aes 0 --targetpath=e:\aes2

And I get error file e:\aes2 is a directory not a file.

Sorting index file … done!
Building lookup table for file hashes
Index file has 99305 hashes in total
Building lookup table with 2047 entries, giving increments of 48
Computing restore path
Restoring 665 files to e:\aes2
0: e:\aes2 (33 bajtów) done!
error: System.IO.IOException: Plik docelowy “e:\aes2” jest katalogiem, a nie plikiem.
w System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)
w Duplicati.CommandLine.RecoveryTool.Restore.Run(List1 args, Dictionary2 options, IFilter filter)
1: e:\aes2 (26,82 KB) done!
error: System.IO.IOException: Plik docelowy “e:\aes2” jest katalogiem, a nie plikiem.
w System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)
w Duplicati.CommandLine.RecoveryTool.Restore.Run(List1 args, Dictionary2 options, IFilter filter)
2: e:\aes2 (6,05 MB) 0 done!

I looking for solution. Thanks.

2

Looks like the bottom of this post which seemed to discover cross-platform restores aren’t supported by RecoveryTool. There’s an ugly workaround there, but usually GUI does cross-platform to different folder.

Could you run RecoveryTool on Linux, macOS, or anything that has forward slashes and no drive letter?

Can you describe the goals? Are you trying to move files, did the Debian system die. or something else?

I don’t know what’s up with your dblock complaint. Could the Windows system show available backups? Assuming you’re doing a direct restore (are you?) that means that password could decrypt the dlist files. Possibly you have a problem with one dblock file, or is this same issue happening on a lot of other files?

3

Hello Team!

Thanks for help. You have right. I restored all files under Debian with all direcory structures.

1 Like
4

Hello Team!

I restore files with command under Debian:

/usr/lib/duplicati/Duplicati.CommandLine.RecoveryTool.exe restore /rs/net/ 0 --targetpath=/ww/zip

and I have files with 0 B size (empty files). Is possible to recovery 1:1 with all files, empty too?

553: /ww/zip/it/_PROJEKTY/podrodze/PoDrodzeApp/obj/Debug/TemporaryGeneratedFile_036C0B5B.cs (0 bajtów) error: System.Exception: Unable to locate block with hash: 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
at Duplicati.CommandLine.RecoveryTool.Restore+HashLookupHelper.ReadHash (System.String hash) [0x000d9] in <64d022f896824ca5971223be95a03946>:0
at Duplicati.CommandLine.RecoveryTool.Restore+HashLookupHelper.WriteHash (System.IO.Stream sw, System.String hash) [0x00000] in <64d022f896824ca5971223be95a03946>:0
at Duplicati.CommandLine.RecoveryTool.Restore.Run (System.Collections.Generic.List1[T] args, System.Collections.Generic.Dictionary2[TKey,TValue] options, Duplicati.Library.Utility.IFilter filter) [0x0041e] in <64d022f896824ca5971223be95a03946>:0
554: /ww/zip/it/_PROJEKTY/podrodze/PoDrodzeApp/obj/Debug/TemporaryGeneratedFile_5937a670.cs (0 bajtów) error: System.Exception: Unable to locate block with hash: 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
at Duplicati.CommandLine.RecoveryTool.Restore+HashLookupHelper.ReadHash (System.String hash) [0x000d9] in <64d022f896824ca5971223be95a03946>:0
at Duplicati.CommandLine.RecoveryTool.Restore+HashLookupHelper.WriteHash (System.IO.Stream sw, System.String hash) [0x00000] in <64d022f896824ca5971223be95a03946>:0
at Duplicati.CommandLine.RecoveryTool.Restore.Run (System.Collections.Generic.List1[T] args, System.Collections.Generic.Dictionary2[TKey,TValue] options, Duplicati.Library.Utility.IFilter filter) [0x0041e] in <64d022f896824ca5971223be95a03946>:0

5

https://cryptii.com/pipes/base64-to-hex shows that this is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

SHA-256 hash of null input?
Top tip: If you see a sha256 hash of e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 it means someone hashed an empty file
explain what you got, although the complaint is probably a bug (fixed in regular Duplicati Canary).

Can you clarify? It sounds like you had empty files and recovered them – empty just like originals.

If you think they were not empty, you can look at filelist.json file in your latest dlist file to see sizes.

Or are you saying that empty files exist in originals, but not in the restored files? Regular Duplicati includes some special code (I think) to handle this, but possibly RecoveryTool was not changed…

Empty files at one time were backed up as empty files, but then a special case was made, and the handling of the special case had some gaps. Recreate is the usual one seen, as a wasted search:

Empty source file can make Recreate download all dblock files fruitlessly with huge delay #3747

There was some talk about the issue and special casing there, and this continued into the fix plan:

Check block size on recreate #3758

Is there a reason you’re using the rarely-used Duplicati.CommandLine.RecoveryTool.exe

This tool can be used in very specific situations, where you have to restore data from a corrupted backup

The RESTORE command would be more typical if you have to restore with CLI, but most common is Restoring files from a backup through the web UI or (if DB was lost), Direct restore from backup files.

Originally you found some odd password or backup file errors though, however if RecoveryTool could decrypt and operate OK without error (is that the case?), then I don’t know why other ways can’t also.