After getting used to crashplan, I like the idea of having of a permanent history of deleted files (it has actually come in useful), so I’ve set my backup retention settings to "1D:U,2W:1D,1M:4D,4M:1W,1Y:2W,4Y:1M,U:2M. It’s just dawned on me that there may a limitation of duplicati, and I’m wanting to know the answer before I dedicate myself to using it.
For the sake of this example, assume it’s backing everything up daily, and eventually it filters down to 1 backup per 6 months, once in January and once in June.
If I create a file in February and delete it in April, will it end up completely purged from the backup?
If I modify a file in February and delete it in April, will it revert back to its original state from January?
Duplicati retention is at the backup set level. There is no mechanism in Duplicati to retain deleted items forever, short of never pruning your backups. You can mitigate this risk somewhat by keeping more versions of the backup. On my system I never get thinner than 1/month retention.
This feature in CrashPlan was nice - it’s one thing I wish was in Duplicati. The other thing I preferred in CrashPlan was how the restore dialog presented the files. You see the tree first, then files, then you pick the version of the file. In Duplicati you have to pick the backup version first. Both layouts have their advantages, I suppose, but I tend to prefer CP’s layout.
Cheers for the info, guess I’ll also up it to once per month.
I’m very aware of the CP restore tree thing being superior, the equivalent of a Duplicati backup set was literally just putting in a date. I was considering looking into recreating that in Python, just need to figure if it can actually be done using the database.