Show file-specific backup history when restoring


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.

[Feature Idea] Changing Restore From should automatically navigate to the selected directory
Restore screen from B2 doesn't list multiple file versions

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 :slight_smile:

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.


Just FYI, posted my notes here: Optimizing load speed on the restore page


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.:wink:


Erm… Yeah, you might be right about that. :blush:

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 :wink:


I would love to see this functionality in Duplicati as well! :slight_smile: