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