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:

crashplan_file_history

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.

1 Like

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.

2 Likes

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:

2 Likes

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?

1 Like

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.

1 Like

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.

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