When some new files get created after the backups, these files do not get removed when I call restic restore. I am expecting that, with restore, the system will go back to the previous states where these “new” files weren’t there.
For example, if a backup of folder contains
testing/test1.txt
and testing/test2.txt got created later on. Running restic restore would not delete testing/test2.txt.
My guess is that, by default, restic does not tackle newly created files after backups. I understand that this behavior could be desirable in some ways but think that we could have a way (like a flag) to specify that we should delete files that do not exist in a folder from the backup.
This sounds like a fundamentally different operation. restore is commonly understood to mean “extract the backup” and not “make the destination exactly match the backup” (which sounds more like a sync operation). For comparison, we don’t expect tar -x to delete files in the destination that aren’t in the archive, though it may overwrite files that are in both.
In particular, this means you can restore select files on top of a running system without restic deciding to destroy everything else that happens to be there. Deleting everything else would seem to me to violate the principle of least astonishment – I never expect restoring a backup to delete stuff.
My suggestion would be to modify your restore procedure. You could:
- Delete all files in the target directory, then restore, or
- Restore into a new directory, then replace the old directory with it. (Probably the saner option, to make sure that the restore did what you want.) Or,
-
restic mount the repository somewhere, then rsync --delete or rclone sync the appropriate backup directory to the target directory.
I agree with you. Think we need to find some turnarounds like the suggestions you gave. Thank you very much for these input.