Sauvegarde et reprise après sinistre pour sites PHP : Guide pratique

Chaque site PHP repose sur une pile de composants mobiles : un serveur web, un runtime PHP, une base de données MySQL ou PostgreSQL, des fichiers de configuration, des ressources téléchargées, et souvent une centaine de petites tâches cron. N'importe lequel de ces éléments peut tomber en panne — une table corrompue, un rm -rf malencontreux, un rançongiciel — et si vous ne disposez que d'une seule sauvegarde de la base de données datant de la semaine dernière, vous êtes en difficulté. Chez DigiForge, nous avons récupéré plus de sites PHP que nous ne voulons nous en souvenir, et la différence entre une récupération de quatre heures et un cauchemar de quatre jours se résume toujours à une chose : une stratégie de sauvegarde et de reprise après sinistre correctement conçue.

Pourquoi la sauvegarde seule ne suffit pas

De nombreuses équipes confondent sauvegarde et reprise après sinistre. Une sauvegarde est une copie périodique des données. La reprise après sinistre est l'ensemble du processus de remise en ligne de votre application — restauration des données, reconfiguration des services, redirection du trafic et validation du bon fonctionnement. Comme le souligne un rapport sur la résilience informatique, « protéger vos données avec des sauvegardes ne suffit plus pour survivre » (source). Une sauvegarde sans plan de reprise testé n'est qu'une assurance que vous n'avez pas encore lue.

Dans un contexte PHP, la différence est frappante. Votre sauvegarde de base de données peut être parfaitement intacte, mais si vous ne savez pas comment pointer Apache ou Nginx vers la base de données restaurée, modifier les identifiants dans le fichier .env ou reconstruire le cache d'opcode PHP, vous restez hors ligne. Et les temps d'arrêt, comme nous le savons tous, coûtent de l'argent et de la confiance. Un plan de reprise après sinistre (DR) complet doit couvrir chaque couche de votre pile serveur, pas seulement les données.

La pile de sauvegarde et de récupération pour les sites PHP

Nous décomposons la sauvegarde d'une application PHP en cinq couches distinctes. En omettre une seule peut rendre les autres inutiles :

1. Code et contrôle de version (dépôts Git, y compris les tags et branches).
2. Exportations de base de données (MySQL, PostgreSQL ou MariaDB).
3. Configuration du serveur web (hôtes virtuels Nginx/Apache, certificats SSL, pools PHP-FPM).
4. Configuration de l'application (.env, fichiers de configuration, identifiants codés en dur).
5. Contenu téléchargé par les utilisateurs (images, PDF, tous fichiers stockés en dehors de la base de données).

Examinons chaque couche avec des recommandations pratiques.

1. Code et gestion de versions

Le code de votre application doit vivre dans un dépôt Git — sans exception. Mais un push Git n'est pas une sauvegarde. Nous avons vu des équipes dépendre d'une seule branche distante et perdre des semaines de travail lorsqu'un force push ou un dépôt corrompu frappe. Utilisez un hébergeur Git (GitHub, GitLab, Bitbucket) et configurez des miroirs automatisés vers un second emplacement. Pour les déploiements en production, étiquetez chaque version. Ainsi, si vous devez revenir à un état connu, vous ne devinez pas quel commit était en ligne.

2. Sauvegardes de base de données

Les sauvegardes de base de données sont les plus critiques et les plus négligées. Un mysqldump quotidien vers un répertoire local vaut mieux que rien, mais nous avons vu ces sauvegardes remplir un disque et s'arrêter silencieusement. Automatisez vos dumps avec un script qui fait tourner les anciennes sauvegardes, les compresse et les expédie hors site — vers S3, Backblaze ou un serveur séparé. Utilisez mysqldump --single-transaction pour les tables InnoDB afin d'éviter de verrouiller les lectures, et testez périodiquement votre restauration. Une sauvegarde qui ne peut pas être restaurée ne vaut rien.

3. Configuration du serveur et du serveur web

Votre site PHP repose sur plus que du code et des données. Les fichiers de configuration Nginx ou Apache, les paramètres du pool PHP-FPM, les certificats SSL et les définitions de tâches cron sont tous propres à votre serveur. Nous stockons ceux-ci dans un dépôt Git séparé (ou dans le dépôt de l'application sous un répertoire deploy/) et les sauvegardons avec le reste. Des services comme Certbot renouvellent automatiquement les certificats Let's Encrypt, mais si votre serveur meurt, ces certificats disparaissent. Sauvegardez /etc/letsencrypt/ ou passez à une validation DNS qui survit à une reconstruction.

4. Configuration de l'environnement et de l'application

Les applications PHP contiennent souvent un fichier .env avec les identifiants de base de données, les clés API et les secrets. Ceux-ci ne doivent jamais être placés sous contrôle de version. Nous utilisons un gestionnaire de secrets (comme HashiCorp Vault ou envkey) en production, mais au minimum, chiffrez et stockez une copie de .env dans votre système de sauvegarde. Si vous perdez ce fichier, vous ne restaurez pas votre site — vous le reconstruisez.

5. Fichiers téléchargés par les utilisateurs et médias

Les images, PDF et autres fichiers téléchargés sont souvent stockés dans un répertoire public/uploads. Ils grossissent rapidement et peuvent alourdir les sauvegardes de base de données s'ils sont stockés sous forme de BLOB. Bonne pratique : conservez les fichiers téléchargés sur un volume séparé ou un stockage objet (S3, DigitalOcean Spaces). S'ils sont sur le système de fichiers du serveur, incluez ce répertoire dans votre sauvegarde hors site. Utilisez rsync ou rclone pour synchroniser quotidiennement vers le stockage cloud.

Automatisation et test de votre plan de reprise

Une stratégie de sauvegarde ne vaut que par sa capacité de restauration. Nous avons participé à trop de post-mortems où le client disait « Nous avons des sauvegardes », mais n'avait jamais essayé de les utiliser. La reprise après sinistre est un processus, pas un produit. Vous devez documenter — et, plus important encore, répéter — comment vous allez restaurer votre site PHP.

• Rédigez un runbook. Documentez chaque étape : où sont stockées les sauvegardes, comment restaurer la base de données, quelles commandes reconstruisent le serveur web, comment mettre à jour le DNS si votre IP change.
• Automatisez les restaurations. Utilisez des scripts ou des outils d'orchestration (Ansible, Puppet, ou même un simple script Bash) pour provisionner un nouveau serveur et restaurer votre application à partir des sauvegardes. Si vous ne pouvez pas lancer un clone en moins d'une heure, votre plan de reprise est trop lent.
• Testez trimestriellement. Restaurez l'intégralité de votre stack PHP sur un serveur frais (un nouveau VPS ou une VM locale) et vérifiez que le site fonctionne. Testez la propagation DNS, le SSL, les connexions à la base de données, les tâches cron et chaque parcours utilisateur. Corrigez tout ce qui casse.

Dans notre expérience, les échecs les plus courants lors d'un exercice de reprise sont les incohérences d'identifiants (mots de passe de base de données codés en dur qui ne correspondent pas au .env restauré), les extensions PHP manquantes et les téléchargements incomplets. Chaque échec est un cadeau — il révèle une lacune que vous pouvez corriger avant un véritable sinistre.

« Une sauvegarde sans plan de reprise testé n'est qu'un espoir. » — Principe d'ingénierie de DigiForge

Choix des emplacements et formats de stockage

L'ancienne règle 3-2-1 tient toujours : trois copies de vos données, sur deux supports différents, dont une copie hors site. Pour les sites PHP, une configuration courante est : (1) le script de sauvegarde locale du serveur de production, (2) un bucket cloud hors site, et (3) une archive de stockage froid (par exemple Glacier) pour les instantanés mensuels. Chiffrez les sauvegardes avec GPG ou un chiffrement côté client avant de les télécharger chez un tiers.

Les sauvegardes incrémentielles économisent de la bande passante et du stockage, mais elles augmentent la complexité de la restauration. Pour un site PHP à trafic moyen, un dump complet quotidien de la base de données associé aux journaux binaires horaires (si nécessaire) constitue un bon équilibre. Les sauvegardes du système de fichiers peuvent être incrémentielles via rsync — assurez-vous simplement que vos outils peuvent reconstruire un état cohérent à partir des incrémentielles.

Quand le désastre frappe : le manuel de reprise

Simulons le pire scénario : une attaque par rançongiciel chiffre votre racine web PHP et votre base de données. Voici le flux de reprise de haut niveau que nous utilisons chez DigiForge :

1. Isolez le serveur infecté — coupez tout accès externe, faites un instantané pour les besoins médico-légaux si nécessaire.
2. Provisionnez un serveur propre — un nouveau VPS avec le même OS et la même version PHP.
3. Restituez le code depuis Git — clonez la release taguée qui tournait avant l'attaque.
4. Restituez la configuration — copiez .env, les configurations du serveur web, les certificats SSL (ou réémettez-les).
5. Restituez la base de données — importez le dernier dump propre, puis rejouez les binlogs jusqu'au point d'infection (si disponibles).
6. Restituez les uploads — rsync depuis le stockage de sauvegarde vers le répertoire d'uploads du nouveau serveur.
7. Testez tout — exécutez des contrôles de santé, vérifiez les connexions à la base de données, assurez-vous que les tâches cron s'exécutent.
8. Basculez le DNS — pointez votre domaine vers l'IP du nouveau serveur (réduisez le TTL au préalable).
9. Surveillez — observez les logs et la disponibilité pendant 24 heures. Ne déclarez la reprise qu'après un feu vert soutenu.

Ce processus complet peut prendre 2 à 4 heures si vos sauvegardes sont bien organisées et que vous vous êtes entraîné. Sans pratique, il peut s'étendre sur plusieurs jours.

Cultiver une culture de la reprise

La reprise après sinistre n’est pas un projet ponctuel, mais une pratique continue. Chaque fois que vous mettez à jour votre version PHP, ajoutez une tâche cron ou modifiez une directive de serveur web, mettez à jour votre runbook et effectuez un nouveau test. Nous avons vu trop d’équipes traiter les sauvegardes comme une simple case à cocher. Une véritable stratégie de reprise après sinistre s’intègre dans votre pipeline de déploiement, votre supervision et la mémoire collective de votre équipe.

Si vous êtes responsable d’un site PHP, commencez dès aujourd’hui. Passez en revue la couverture de vos sauvegardes pour les cinq couches, automatisez ce que vous pouvez et planifiez votre premier exercice de restauration. Et si vous souhaitez un regard extérieur sur votre stratégie, contactez DigiForge. Nous avons construit et restauré suffisamment de sites PHP pour savoir ce qui fonctionne — et ce qui ne fonctionne pas.