La plupart des sauvegardes contiennent les fichiers et la base, et la plupart des restaurations échouent ensuite sur quelque chose qui n'y a jamais figuré. Une sauvegarde est complète quand sa restauration sur un serveur nu donne un site qui marche, sans rien taper de mémoire.

Les deux évidences

  • Les fichiers du site, envois compris — qui se trouvent souvent sur un autre disque et sont donc oubliés.
  • La base, exportée par un dump plutôt que copiée pendant qu'elle tourne.
mysqldump --single-transaction --quick --routines --triggers --events dbname | gzip > db.sql.gz

--single-transaction prend un instantané cohérent sans verrouiller le site. --routines, --triggers et --events incluent les parties qu'un dump ordinaire laisse silencieusement de côté.

Les quatre qu'on oublie

  • La messagerie. Sur le même serveur et jamais dans la sauvegarde du site. Perdre cinq ans de courrier est pire que perdre le site.
  • Les tâches cron. Ce ne sont pas des fichiers de votre site. crontab -l, et gardez le résultat.
  • La configuration du serveur. Le bloc Nginx, le pool PHP, le certificat. Les reconstituer de mémoire est la partie la plus lente de toute restauration.
  • Le DNS. Un export de la zone. Refaire trente enregistrements à la main pendant que le site est à terre est exactement aussi pénible que cela en a l'air.
crontab -l > cron.txt
cp -a /etc/nginx/sites-available/mysite .
cp -a /etc/php/8.3/fpm/pool.d/mysite.conf .

Et les identifiants

Une sauvegarde chiffrée dont la clé ne se trouvait que sur le serveur mort n'est pas une sauvegarde. Gardez la clé ailleurs, et notez où.

Le test qui le prouve

Restaurez sur un serveur vide sans ouvrir le moindre autre document. Tout ce que vous devez chercher ailleurs est précisément ce qui manque à la sauvegarde.

Les sauvegardes automatiques d'EGPHP couvrent les fichiers, les bases et la messagerie, et EGPNL restaure chacune d'elles séparément. Cette page est la liste de contrôle pour tout ce que vous sauvegardez vous-même.