Undoing a replacement, and finishing one
Quick answer
Select a replaced row and press Roll Back: an overwritten file is restored from its backup, and a created attachment is deleted and its field put back to what it pointed at before.
Rollback is per row, not per batch. Replacing forty files and discovering that one of them was the wrong document means rolling back that one.
What rollback restores
For an overwrite, the backup is copied back over the live file and the attachment metadata is regenerated. The URL never changed, so nothing else on your site needs touching.
For a new attachment, the attachment the plugin created is deleted and the field is set back to its previous value. The plugin recorded both the attachment it created and the value it replaced before it changed anything, which is what makes this possible at all.
Why a row might not offer rollback
Deleting backups is permanent, and a row whose backup has been deleted has nothing to restore from. The table tells you which rows can still be rolled back, so check before you clean up.
Verifying and cleaning up
Once you have looked at the live site and you are happy:
- Mark Verified records that a person checked it. It changes nothing on your site; it is a note to you and to whoever looks at this batch next month.
- Delete Backups permanently removes the backup files for the rows you select. This is the step that frees the disk space, and it is also the step that ends the ability to roll those rows back.
There is no rush to do either. Backups sitting in the backups folder cost disk space and nothing else.
Where backups live
Under your uploads folder by default, in a directory the plugin protects with the usual guard files — and then checks, by fetching a canary file over HTTP, whether that protection actually works on your server. If it cannot prove the folder is private it says so rather than staying quiet, because backups are copies of your live documents. If you would rather they were nowhere near the web root, a constant in wp-config.php moves them.