This would be really useful, so I’m hoping it’s possible. When I restore from a snapshot, I would like to be able to delete any local files which are not in the snapshot.
So restore would mean, restore this whole directory to its previous state, deleting any recent local additions.
Any suggestions?
IMO this feature wouldn’t make sense in restic. It doesn’t exist in tar, for example, nor in any other backup tool I’ve used.
Just delete everything in the restore target first if this is what you want to achieve.
This. @tesujimath What problem are you trying to solve with the suggested feature, that isn’t already solved by what @cdhowie wrote above?
I want to restore the directory (the whole of which has been backed up by restic) to a snapshot. Which clearly should delete anything which was added since the restic snapshot was created. (At least, clearly for anyone used to snapshotting filesystems like ZFS.)
The particular case I am considering is a WordPress installation. I took a restic backup prior to installing some plugin, which I then realise is garbage, so I want to revert. Which should also mean, delete any new files which got installed. Say I have 100GB in my WordPress directory. It’s ridiculous that I have to delete everything, and let restic restore it all from the snapshot. Restic is already scanning the filesystem (to work out what to restore), so should be easy for it to say, hmm, a new file not in my snapshot, perhaps the user would like to delete it?
This sounds like a new feature request, restic restore --delete. So here it is:
Okay, thanks for elaborating.
Im not dismissing your use case, but personally I think that you’re using the right tool for the wrong job, or however you want to put it 
Your WordPress installation should be version controlled using e.g. Git, and if it is, then you will simply revert to the version of your site before you installed the plugin (after uninstalling the plugin in the WP admin GUI, of course, since it’s WP we’re talking about here and you don’t want to screw up its database). You don’t need restic for that.
In short, it seems a bit wrong to me to use a backup tool like restic to version control parts of your site. Use a more proper tool
That said, I understand what you’re saying, I think.
Hmm, I don’t think I should have to undo actions in a GUI. Other users may have got in and wrecked it all. I need to be able to reset to a good state, aka snapshot.
I’m backing up the MySQL database separately (using mysqldump --tab to get separate file per table, which I am then backing up with restic). So the database is not really a problem.
Git is an interesting idea, but snapshots are (to me) more compelling. I really don’t want to keep a full version history of the whole WordPress installation forever. Pruning old snapshots is therefore a must have. Can’t get that with git.
Here’s what I’m considering as a work-around, tentatively.
My snapshot operation would be to create a parallel directory tree, with separate directories containing hard links to all the files. Which is pretty cheap. I then restic backup the original tree.
To restore, I delete the original tree, and move over the hard-linked copy (number of hard links to each file drops back to one). Then I use restic restore to rescue each modified file to its former state.
I’m not that keen on this idea, it’s a bit too home-grown (i.e. potential for bugs in the corner cases). But it’s not that complicated, and seems to give me what I want.
The WP admin GUI reference was just a note to the fact that unless you also do a proper uninstall of the plugin in WP, and then remove the plugin files, you might end up with a broken WP because it’s expecting files to be there but can’t find them.
It’s a bit worrying to hear that you think using snapshots to version control a website is better or easier than using Git. This is exactly what Git was made for. It’s the right tool for the job.
With WP you must be careful to keep the database and the files in sync, otherwise you’ll have more trouble than what’s pleasant (even though it can usually be fixed).
If at the time that you want to restore to a good state you are also prepared to lose whatever data was added to the site after your last good “snapshot”, then you will have to restore that snapshot AND restore the database.
If you don’t want to lose data that was added to the site since you installed the plugin you want to get rid of, you’ll need to use e.g. Git to undo the add plugin commit (or some other method, like the one you’re proposing), but as I said that should be done after uninstalling the plugin using the WP admin tools (just to be on the safe side).
Either way, why not just version control it using proper tool for that. Why would you not version control your site’s source code? I just don’t get it
PS: Snapshots and commits in Git are more or less the same, for the intents and purposes of this discussion.
@rawtaz You make some good points. Thanks for your patience. I’m thinking I probably will use git. After all, I’m using it for everything else in my life at this stage 
After looking into this properly, my use case does not justify the feature request. (However, perhaps I could think of others that do, especially for someone coming from ZFS land. Later.)
In case anyone else reads this and is wondering, here’s what I have landed on as the right way to manage a WordPress site now: Composer and git. Thanks to @rawtaz for the helpful discussion.
I believe you are mistaken about how restic operates. When restic tries to “work out what to restore” it is only looking at your --include and --exclude arguments; it doesn’t care what is in the source directory.
It’s going to clobber any file that shares a path with what’s in the backup, and restic restore doesn’t care whether or not it is different – it would have to hash the existing file on disk in order to determine if the content changed, at which point it would then have to restore the file from the backup. Hashing every file in the restore target is, frankly, a waste of time.
Again, this is in line with other, similar backup tools (such as tar).
Couldn’t this be achieved by a restic mount + rsync --delete from mount to target?
Yes, though I believe restic mount can suffer from some performance problems in this kind of scenario. You’d have to test to see if this runs quickly enough.
It does exist in the 7-zip format (called an “anti-item”). That said, as others have mentioned, this should do the trick, albeit slowly.