If a drive change isn’t a change, what about a folder change or a rename?
Originally I thought this was files changed-in-place, but apparently it’s not.
Duplicati already knows the hashes of all the files, and also the file paths.
Another approach would be to use a script and SQL to look over the data.
The question I posed above holds – what’s a “difference” and what’s not?
If the focus is only about duplicates, that’s an even easier analysis in SQL.
OTOH it sounds like you already got a tool that works with current content.
I don’t understand the question well, especially with the questions after that.
I think Duplicati does file restores separately. It won’t restore one then copy.
Restore just got rewritten though, and there are other optimizations coming.
Restore time will vary because restore won’t restore a file it doesn’t have to.
Blog post: Cut restore times by 3.8x - A deep dive into our new restore flow
describes the old (legacy) and new (default) restores. Look at results for the
No restore - The target directory contains all of the files in their expected state. Metadata is skipped, so this test should not be fetching from remote storage.
for the new flow design, and for the old flow which I have more experience with:
Scan the existing target files for existing blocks, as they don’t need to be restored.
This always confused people when no work was needed, so they were told:
Restore completed without errors but no files were restored