Restoring onto the same machine restores files into a system that is already configured. Onto a fresh machine, the backup arrives into nothing - and everything that was set up by hand over two years is missing at once. That gap is the real work.

What is in the backup

  • The web root
  • The database
  • Uploads and generated files

What is usually not

  • The PHP version and its extensions.
  • The Nginx or Apache site configuration.
  • The certificate, or the ability to issue one before DNS moves.
  • Cron jobs and systemd units.
  • Environment variables and secrets, which are correctly excluded from backups and therefore have to come from somewhere else.
  • Mail configuration, and the reverse DNS on the new IP.

The order that works

  1. Build the machine first — same PHP version and the same extensions - php -m on the old one is the list.
  2. Restore files and database — then set ownership: sudo chown -R sara:www-data /var/www/site.
  3. Recreate the database user and grants — they live in the mysql schema, not in your dump. See users and grants.
  4. Put the config back — web server, cron, units, and the environment file from your password manager.
  5. Test on the new IP before DNS moves — with a hosts-file entry on your own machine.
  6. Issue the certificate, then move DNS — see migrating with no downtime.
# test the new server while DNS still points at the old one
# /etc/hosts on your laptop
203.0.113.99  yourdomain.com www.yourdomain.com
Do not move DNS until the site answers correctly on the new IP by that hosts entry. Moving first turns a difficult afternoon into a public outage.
Write down what you had to do by hand. That list IS the missing part of your backup, and next time it is a script rather than an afternoon of remembering.