Restoring is destructive — it replaces what's there now with what used to be there. Done thoughtlessly, a restore can wipe newer work or drag credentials and settings backwards. Run through this checklist first.
The checklist
- Pick the right day. Restoring "the backup from yesterday" may undo edits from last week if the backup is older than you think. Identify the exact breakage time and restore to just before it.
- Understand what gets overwritten. A home-directory restore replaces all site files. A database restore replaces that database entirely. Anything created since the backup date is lost — confirm a newer version isn't the one you want to keep.
- Backup the current state too. If you restore and it's wrong, you'll want to go back. Take a current manual backup first.
- Watch out for passwords. A database restore brings back the credentials recorded at that time. If you changed passwords, your CMS/pages may use the old ones. Have an admin path planned in case to test identity differences.
- Check URLs and integrations. If the site is a test copy or was recently moved, post-restore URLs may differ. Recheck settings and third-party connections afterwards.
Database restores need matching users
If a database was deleted and recreated with different naming, restore it to the exact database name and user your site's config file expects — otherwise you'll restore the data and then hit a database connection error anyway.
After the restore completes
- Test the site and confirm the specific problem is gone.
- Clear any caches — see Website Showing an Old Version if it still looks stale.
- If it didn't fix things, check you restored the component that actually broke (files vs database vs both) and contact support with a clear description.