Restoring after something went wrong.
BEFORE RESTORING
Take a copy of the current state. It may contain content added since the backup, and restoring overwrites it permanently.
Note what has changed since the backup date, so you can reconcile.
RESTORING FILES
Extract the archive to the correct location, overwriting when prompted.
Check ownership and permissions afterwards. Wrong ownership after a restore is a common cause of the application failing.
RESTORING THE DATABASE
Drop the existing tables, then import the dump. Importing over existing data produces conflicts and partial results.
Confirm the configuration file still holds the correct credentials.
MATCHING DATES
Restore files and database from the same backup date. Mixing dates leaves the application inconsistent in ways that are difficult to diagnose.
AFTERWARDS
Clear all caches Test the site and the administrator login Check scheduled tasks Check email sending Verify content is as expected
IF THE RESTORE WAS DUE TO A COMPROMISE
Update everything and change all credentials before going live again, or you are restoring the vulnerability too.
