Above syntax issue was in RecoveryTool, but then we head to GUI:
seems to conflict with below. I’m not sure which one is discussed…
which now sounds more like Duplicati.CommandLine.RecoveryTool.exe. Here’s a sample index.txt file:
It looks like it should be portable, except maybe for line endings. Windows uses CRLF, Linux just LF, however there are editors and utilities to fix that if need be. It’s a map of block hash to containing file.
So if you want to try RecoveryTool on Linux, you can probably use or adapt (line ends) prior index.txt.
was the previous RecoveryTool problem, and hope was that it would be avoided by running on Linux.
I don’t think there are more downloads needed (everything is already local via SMB), just extractions.
The downloading part sounds more like GUI restore behavior, but I’m not certain what step you’re on.
“Building partial temporary database” does downloads of dlist and dindex files, and has to locate the needed blocks to their containing dblock file very much like index.txt does, but in an SQLite database.
Ordinarily the index files say where all blocks are, but a missing block can force a full dblock search. Regular recreate shows this slow spot at the 90% to 100% range on progress bar. and you can also observe the action in About --> Show log --> Live --> Information to see what files you’re processing.
The “processing blocklist volume” mentioned earlier is dblock files. Search was also described here.
Having to download all dblock files is not normal. If needed, it adds a lot to the time to create the DB.
If the slow spot is before the 70% mark or so on progress bar, time is probably from inserting blocks.
Default block size is 100 KB, so if that’s what you have, full recreate of 700 GB has 7 million inserts.
Partial (as in direct restore from backup files) should be faster, but might still need full dblock search.
There’s also some overhead on downloading, decrypting, and unzipping the files to extract contents.
If the hope was that moving to Linux would make the DB better than Windows does, I don’t see how.
There is no index to steal, but there is a partial temporary database (not really any way to reuse that).
In terms of downloads, if you’re in DB creation, then see above. If you’re in actual restore that follows, downloads should only be the dblock files that are needed for whatever is being restored. By default, there’s even an attempt to look at original source file paths to see if any blocks are available there, so theoretically one could do a “restore” without downloads. I’m pretty sure these dblock files download immediately before blocks are pulled out and put in the file being rebuilt in the restore area. It will look somewhat strange as it’s reassembled a block at a time. If you don’t see it, you’re not restoring yet…
If you can say whether you’re asking about RecoveryTool, GUI direct restore, both, or something else, perhaps I can answer a little better, however I’m not familiar with every last detail of the processing…
Please clarify what steps you’ve done. I see “got to the end”, but also hear talk of stuck-in-the-middle.
I’m also kind of curious why GUI is (maybe) being tried. I thought next try was RecoveryTool on Linux.