One nice feature in CrashPlan is the ability to see the backup history of the individual files. For example, see the following image:
Here, the user can click on the arrow next to a file and see that fileās backup history. By seeing an individual fileās backup history, it can be easier to find a particular version of a file when restoring.
Yes, it is a long-overdue feature request:
The information is present in the local database, the tricky part is building a UI that shows it.
Sorry, I didnāt see the existing GitHub issue. Thanks!
Help to speed up the implementation of this request I added 50 $ to the bounty request:
Does the backed support this? Is it just a UI implementation?
There isnāt a web API option exposed for searching files across all backups currently.
The restore page relies on this REST method: duplicati/Backup.cs at master Ā· duplicati/duplicati Ā· GitHub
But it has some performance issues. Specifically it takes 3-5 seconds to look through the database for matches for one backup set, potentially growing much slower if modified to look at all idās.
I think it would be best to bet on writing a new method, and SQL query, to support this use case. But to be honest I think the entire restore functionality could use a rewrite 
Edit: I took some time out a few weeks back to go through that hole restore process and make some SQL queries to test what kind of performance I could get. I have the notes on it, including queries, but I didnāt get around to clean it up and posting it on the forum. Maybe those queries would be interesting if someone is looking into this feature?
Yeah, thatās true. The Restore system does lack some important features. I will also see if I can do anything to help. You should definitely post any of your findings on the forum so others can also provide feedback on how this should be tackled. I think allowing to easily restore specific versions is very important and was a feature that I really appreciated in other backup solutions that I have used in the past.
Agreed, I like that feature as well.
Though a nice stopgap might be a simple checkbox to restore all versions (timestamped) of the file being restored - that way very little needs to be changed on the GUI side.
Funny things will happen while restoring a 500GB vhdx file that has been changed in every daily backup.
Ermā¦ Yeah, you might be right about that. 
That makes me wonderā¦ if a source file of size X was on a āversioningā OS (btrfs, xfs?) and had 10 versions, it would take Y space (likely much less than 10ĆX).
If all those versions were restored to the same OS they wouldnāt be seen as versions of the same file so would end up taking 10ĆX space, wouldnāt they.
I guess so, unless the file system supports deduplication.
However, for Windows the dedup process is a scheduled operation, so the restored files will take up 10xX space before the files are optimized. So I guess itās not a very good idea to restore a bunch of versions of a large file, even on dedup-enabled volumes.
The versions on zfs or btrfs will only be smaller for that file. If you copy it to a new location you use 2 times the space.
Now with deduplication it would be a different story, but not a lot of people can afford that much RAM today
I would love to see this functionality in Duplicati as well!