Most backups hold the files and the database, and most restores then fail on something that was never in them. A backup is complete when a restore onto a bare server produces a working site with nothing typed from memory.
The obvious two
- The site files, including uploads - which are often on a different disk and therefore missed.
- The database, dumped rather than copied while running.
mysqldump --single-transaction --quick --routines --triggers --events dbname | gzip > db.sql.gz--single-transaction takes a consistent snapshot without locking the site. --routines, --triggers and --events include the parts a plain dump silently leaves out.
The four that get forgotten
- Mail. On the same server and never in the site backup. Losing five years of mail is worse than losing the site.
- Cron jobs. Not files in your site.
crontab -l, saved. - Server configuration. The Nginx block, the PHP pool, the certificate. Rebuilding those from memory is the slowest part of any restore.
- DNS. An export of the zone. Rebuilding thirty records by hand while the site is down is exactly as bad as it sounds.
crontab -l > cron.txt\ncp -a /etc/nginx/sites-available/mysite .\ncp -a /etc/php/8.3/fpm/pool.d/mysite.conf .And the credentials
An encrypted backup whose key was only on the server that died is not a backup. Keep the key somewhere else, and write down where.
The test that proves it
Restore onto an empty server without opening any other document. Whatever you have to look up elsewhere is what is missing from the backup.
EGPHP daily backups cover files, databases and mail, and EGPNL restores any of them on its own. This page is the checklist for anything you back up yourself.