I’m testing Duplicati using Amazon S3 for my personal backup, and I ran into a small issue with restoring files.
This is what I did:
- I made a backup up of My Documents (let’s call this Backup A)
- I made changes to My Documents including creating new files, modifying existing files and deleting files.
- I made another backup of My Documents (let’s call this Backup B)
Here is the issue that I’m running into:
- When I restore the files back to Backup A, the new files persisted
- When I restore the files back to Backup B, the deleted files persisted (since they were restored in the previous step)
- There are no issues with modified files (as expected)
I can always delete every file in My Documents, and then let Duplicati restore the files. But this is impractical with gigabytes of data and many changes made to My Documents each month. Is there a way to ask Duplicati to deal with new and deleted files properly as I roll the backup back and forth? Am I missing a setting somewhere?
Did you set advanced option
True anywhere (for example in the Settings menu)? If so, disable or remove the setting and you will see only the files included in the selected backup set.
Hi @adam, welcome to the forum!
I maybe misunderstanding, but are you expecting files created AFTER Backup A was made to be deleted when Backup A is restored?
Yes, that’s correct! I’m wondering if there is a setting that will delete all new files when Backup A is restored.
I know Duplicati will always restore everything correctly if I clear out everything inside My Documents first. But real life is far messier, and I need a way to roll back between backups. Please do let me know if it’s possible to get Duplicati to do this.
–all-versions is set to false, and the selected backup set is showing the correct files.
The confusion is restricted to new and deleted files only, and I quickly lost track of files when I roll back between backups.
I know of no feature that causes Duplicati to delete files found in the restore folder if they do NOT exist in backup, sorry.
Because of the possibility of data loss (such as if backup A happens, then file X is created, then restore of A happens BEFORE file X is backed up) I don’t know that there are currently any plans to support such as feature.
You could put in a #features request for such a thing and if interest is high enough it might get implemented. If you do, may I suggest that a “rollback-restore” feature might work something like:
- do a backup of the restore location if “rollback-restore” is requested (this captures any potential new files that might have been created since last backup, could also make it smart enough to not back up if no new files since last backup are found)
- do restore
- delete any files NOT part of the restore
While it’s possible you might be able to simulate this with a
--run-script-before task, it would be difficult to code due to the possibility of things like if you choose to restore only a single file you probably don’t want to whole restore folder tree to be wiped first…
Actually, now that I think about it the only type of backups I recall that would do what you’re asking are either disk images or something like Subversion or other version control repository system (which really aren’t designed as backup tools).
Thank you for the clarification.
Duplicati works great as described. I think I have unrealistic expectations for what I needed to do, and I need to rethink my backup strategy now that I understand how Duplicati operates.