Losing track of systems. Is the backup server the one whose drives failed, taking out not only the source files but the Duplicati database? In what ways is it a backup server? Is there another backup going to it?
One reason I ask is because another option to try is Independent restore program in Python. How’s your Python? Does it look like this restore timestamps or just files, and how essential are the file timestamps? Duplicati backup files don’t care about their timestamps, but I don’t know whether your backup will care.
We’re getting into some rarely used things. Possibly your open file problem is only in RecoveryTool, and regular Duplicati Restore from GUI or CLI would work – if you could get installed and if other things held.
Keeping NFS in the mix adds potentially more questions. Can’t most VM system share host files with the VM in some limited way (I guess you want to be super-sure nothing you do breaks your only download)?
But the latest approach sounds like a Windows PC with access to backup files via either Samba or USB.
Is it only dblock files? Regular operations also need dlist and dindex. I think RecoveryTool does without dindex, but needs dlist. There’s also a step in directions about building an index file RecoveryTool-style. There was talk earlier of index, so I suspect there’s an index, but it wouldn’t hurt to verify what’s there…
IIRC index file is used to find blocks (identified by hash) which are then pulled out to rebuild original file. Yours looks from source like it probably got as far as making a temporary file, then choked on copy-out.
Is there any other context output before that to show where this was? The possible failure (and source code which might have made messages) is below, just guessing by seeing where a Copy might occur:
Documentation shows the following example of what I mean by context – what led up to the problem?
Sorting index file ... done!
Building lookup table for file hashes
Index file has 2047 hashes in total
Building lookup table with 2046 entries, giving increments of 1
Computing restore path
Restoring 75 files to C:\Restore
Removing common prefix C:\Users\User\ from files
Your command taken in isolation looks to me as documented, but I haven’t set up a test. First, does the output you get leading up to the error look sane for your situation based on the example shown above?
Because you’re doing a cross-platform restore (original has forward slashes, restore has backslashes), I’m wondering whether that difference could be tripping things up. Regular GUI restore can deal with it, somewhat, but IIRC it won’t let you restore to original file paths – you have to point it to a restore folder.
How the backup process works shows how paths, slashes, and maybe drive letters appear in dlist files.
EDIT: Not a perfect test, but I tried RecoveryTool on an existing Windows backup, restored to Windows, and it worked (as it has been doing for awhile AFAIK). An existing Linux backup restore to Windows did not work, so I custom-tailored one with two small files. This failed as below first, then I edited filelist.json in the dlist file to add a drive letter (leaving the slash differences alone), and it worked, but this seems a really ugly workaround, and perhaps trying a RecoveryTool restore to Linux would be a better aproach.
C:\ProgramData\Duplicati\duplicati-2.0.4.36_canary_2019-12-08>Duplicati.CommandLine.RecoveryTool.exe restore C:\RecoveryTool --targetpath="C:\RecoveryTool_targetpath"
Sorting index file ... done!
Using set 0 with timestamp 12/9/2019 12:45:53 PM
Building lookup table for file hashes
Index file has 5 hashes in total
Building lookup table with 4 entries, giving increments of 1
Computing restore path
Restoring 2 files to C:\RecoveryTool_targetpath
0: C:\RecoveryTool_targetpath (2 bytes) done!
error: System.IO.IOException: The target file "C:\RecoveryTool_targetpath" is a directory, not a file.
at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)
at Duplicati.CommandLine.RecoveryTool.Restore.Run(List`1 args, Dictionary`2 options, IFilter filter)
1: C:\RecoveryTool_targetpath (2 bytes) done!
error: System.IO.IOException: The target file "C:\RecoveryTool_targetpath" is a directory, not a file.
at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)
at Duplicati.CommandLine.RecoveryTool.Restore.Run(List`1 args, Dictionary`2 options, IFilter filter)
C:\ProgramData\Duplicati\duplicati-2.0.4.36_canary_2019-12-08>Duplicati.CommandLine.RecoveryTool.exe restore C:\RecoveryTool --targetpath="C:\RecoveryTool_targetpath"
Sorting index file ... done!
Using set 0 with timestamp 12/9/2019 12:45:53 PM
Building lookup table for file hashes
Index file has 5 hashes in total
Building lookup table with 4 entries, giving increments of 1
Computing restore path
Restoring 2 files to C:\RecoveryTool_targetpath
0: C:\RecoveryTool_targetpath\C/backup source/A.txt (2 bytes) done!
1: C:\RecoveryTool_targetpath\C/backup source/B.txt (2 bytes) done!
C:\ProgramData\Duplicati\duplicati-2.0.4.36_canary_2019-12-08>
Notepad-edit filelist.json with drive letter added in front of the original Linux forward-slashed pathname:
[{"type":"File","path":"C:/backup source/A.txt","hash":"BvlhuAK8Ru4WhVXwZtKPTw6a/fP4gXTB7m+d4AT8MKA=","size":2,"time":"20191209T174422Z","metahash":"GSk37v/IInH+jzfV2NXAPguQlbs7VN0GFhtH10EoqFw=","metasize":193},{"type":"File","path":"C:/backup source/B.txt","hash":"wM3nf6j++X1HbBCq09LVT8wvM2FA0HNlHC3Mzx43n9Y=","size":2,"time":"20191209T174436Z","metahash":"F52HR7pEdAbPn9p6rK/6SHkzB69QBf/WTmek90qzvV0=","metasize":193}]
EDIT 2: Drive letter used as dummy doesn’t matter. It turns into a folder (without a colon) in targetpath. This info is more for any developer who wants to dig in. I still hope that this workaround is not required.
If any other users or developers have other ideas, feel free to join in on the action with your thoughts…