Quick answer: Restore in the reverse order of backup: copy the files back, import the database dump, fix permissions, then test the site before switching DNS or traffic to it. Practising this on a scratch server before you need it is what makes a real recovery calm instead of chaotic.
Overview
A restore has four phases — retrieve, files, database, verify. The commands below assume the common LAMP/LEMP layout and a backup made with rsync + a SQL dump, as in our Storage VPS backup guide.
Before you start
- Access to your backup target and the credentials for the server you are restoring to.
- The most recent consistent pair: file snapshot + database dump from the same run.
- A decision: restore in place, or to a fresh server and switch over (safer for compromised machines — see if your server is compromised).
Step-by-step guide
- Pull the files back:
rsync -az [email protected]:/srv/backups/example/wp-content/ /var/www/example.com/wp-content/ - Import the database:
gunzip < example-2026-07-15.sql.gz | mysql example_db - Fix ownership and permissions:
chown -R www-data:www-data /var/www/example.com - Restart services and clear caches:
systemctl restart php8.3-fpm nginx - Verify on the server first:
curl -I http://localhost, then in a browser via the server IP or a hosts-file entry, and only then point DNS/traffic at it.
Common issues
- White page after restore: usually permissions or a missing PHP extension — check the error log first.
- Old content shows: you restored an older snapshot than intended, or a cache layer (opcode/page cache/CDN) is serving stale copies.
- Database/file mismatch: a dump from Tuesday with files from Friday breaks plugins — always restore the matching pair.
When to contact support
If the restore is blocked by the platform — server unreachable, disk errors, KVM needed — open a ticket. Application-level restoration on unmanaged plans is customer territory, but support can get the machine itself healthy.
Frequently asked questions
In what order do I restore a website?
Files first, then the database dump, then permissions and service restarts, and finally verification on the server itself before you point DNS or live traffic at the restored site.
Why does the site show errors right after a restore?
Most restore-day errors are file ownership, a missing PHP extension, or stale caches. Check the web server error log first — it names the real problem in one line.
Should I restore onto the same server after a hack?
No — rebuild on a fresh server or freshly reinstalled OS and restore data onto it. Restoring on top of a compromised system preserves whatever backdoors the attacker left.
Related articles
- How to test backup integrity
- How to create a disaster recovery plan
- How to back up WordPress to remote storage
- What to do if your server is compromised
Need a hand? Contact Cloud2Y support →
