Mis à jour le 1er novembre 2026. Cet article regroupe désormais notre article « Site PHP et panne d’hébergement : plan de reprise ». Il prend l’incendie du site OVHcloud de Strasbourg, en mars 2021, comme exemple vérifiable.
Quand l’hébergeur tombe, une boutique PrestaShop, un site WordPress ou une application PHP ne revient en ligne que si trois choses existent déjà : une copie récente des données ailleurs que chez lui, un domaine que vous pouvez rediriger, et une procédure écrite que quelqu’un a déjà suivie. Tout le reste s’improvise mal sous pression.
Cet article décrit un plan de reprise centré sur la panne d’hébergement : sauvegardes, DNS, bascule vers un autre prestataire, tests et communication. La méthode générale pour fixer les objectifs et organiser les exercices est dans notre plan de reprise après sinistre pour une application PHP.
Ce que l’incendie de Strasbourg a montré
Dans la nuit du 10 mars 2021, vers 0 h 47, un incendie s’est déclaré dans une salle de SBG2, l’un des quatre centres de données d’OVHcloud à Strasbourg. Selon le message publié par OVHcloud le matin même, le feu avait détruit SBG2 à 4 h 09, et le site était inaccessible à ses équipes à partir de 5 h 30. Netcraft a estimé à environ 3,6 millions le nombre de sites web mis hors ligne, sur 464 000 noms de domaine distincts.
Pour un éditeur de site, la leçon tient moins à l’incendie qu’à l’emplacement des copies. En 2023, le tribunal de commerce de Lille a condamné OVHcloud à indemniser un client, Bati Courtage, dont les sauvegardes se trouvaient dans le même centre de données que les serveurs de production, alors que le contrat prévoyait un emplacement physique différent. Nous n’avons pas trouvé l’issue d’un éventuel appel. Le point utile reste valable : une sauvegarde chez le même prestataire, voire dans le même bâtiment, peut disparaître avec la production.
| Scénario | Ce qui protège | Ce qui ne protège pas |
|---|---|---|
| Destruction du centre de données | Copie chez un autre fournisseur, restauration déjà testée | Sauvegarde automatique du même hébergeur, même région |
| Suspension du compte d’hébergement | Copie et DNS gérés depuis des comptes distincts | Sauvegardes stockées dans l’espace client |
| Compromission du serveur | Copie hors ligne ou non modifiable depuis la production | Synchronisation en continu, qui propage le chiffrement ou la suppression |
| Erreur de manipulation | Historique de plusieurs jours | Une seule copie, écrasée chaque nuit |
Fixer RPO et RTO avant de choisir les outils
Le RPO est la quantité de données que vous acceptez de perdre, exprimée en temps ; le RTO est la durée maximale avant le retour du site. Une boutique qui encaisse des commandes en continu n’a pas les mêmes objectifs qu’un site vitrine. Ces deux valeurs fixent la fréquence des sauvegardes et le niveau de préparation de la cible de secours. Si le RPO se compte en minutes, un export quotidien ne suffit pas : il faut une réplication vers un autre site, en plus des sauvegardes, car une réplication recopie aussi les suppressions.
Appliquer la règle 3-2-1 à un site PHP
La CNIL présente comme état de l’art la règle « 3-2-1 » : trois copies des données, sur deux supports différents, dont une hors ligne. Elle recommande aussi de stocker au moins une sauvegarde sur un site géographiquement distinct, de chiffrer les sauvegardes et de tester régulièrement leur restauration. L’ANSSI formule la même règle dans son guide sur les fondamentaux de la sauvegarde.
Pour un site PHP chez un hébergeur mutualisé ou sur un VPS, cela se traduit ainsi :
| Copie | Emplacement | Accès | Rôle |
|---|---|---|---|
| 1. Production | Serveur de l’hébergeur | Équipe d’administration | Site en ligne |
| 2. Sauvegarde distante | Stockage chez un autre fournisseur, autre pays ou autre région | Compte dédié, écriture sans suppression si possible | Restauration après une panne d’hébergeur |
| 3. Copie hors ligne | Disque déconnecté ou stockage non modifiable | Une ou deux personnes | Restauration après une compromission |
Une sauvegarde complète couvre la base de données, les fichiers envoyés (img/, upload/, download/ pour PrestaShop, wp-content/uploads/ pour WordPress), le code et les modules, la configuration (app/config/parameters.php pour PrestaShop 1.7 et suivants, wp-config.php pour WordPress) et la liste des tâches planifiées.
Le script suivant, à planifier chaque nuit, exporte la base, archive les fichiers, chiffre le tout avec GnuPG, calcule les sommes de contrôle et envoie les archives chez un autre fournisseur. Les identifiants MySQL sont lus dans un fichier protégé, jamais dans la ligne de commande.
#!/usr/bin/env bash
# sauvegarde-site.sh : export chiffré envoyé chez un autre fournisseur
set -euo pipefail
umask 077
SITE="boutique"
BASE="nom_base"
RACINE="/var/www/boutique"
DEST="/var/backups/${SITE}"
DISTANT="sauvegarde@stockage.autre-fournisseur.example:/srv/backups/${SITE}/"
DESTINATAIRE_GPG="sauvegardes@exemple.fr" # clé publique seule sur le serveur
DATE="$(date +%F-%H%M)"
mkdir -p "${DEST}"
# Base : export cohérent des tables InnoDB, identifiants dans un fichier chmod 600
mysqldump --defaults-extra-file=/etc/backup/my.cnf \
--single-transaction --routines --triggers "${BASE}" \
| gzip > "${DEST}/db-${DATE}.sql.gz"
# Fichiers : code, médias et configuration, sans le cache
tar -czf "${DEST}/fichiers-${DATE}.tar.gz" \
--exclude="${SITE}/var/cache" -C "$(dirname "${RACINE}")" "$(basename "${RACINE}")"
# Chiffrement : la clé privée n'est jamais stockée sur ce serveur
for f in "${DEST}/db-${DATE}.sql.gz" "${DEST}/fichiers-${DATE}.tar.gz"; do
gpg --batch --yes --trust-model always --recipient "${DESTINATAIRE_GPG}" \
--output "${f}.gpg" --encrypt "${f}"
rm -f "${f}"
done
( cd "${DEST}" && sha256sum "db-${DATE}.sql.gz.gpg" "fichiers-${DATE}.tar.gz.gpg" > "SHA256SUMS-${DATE}" )
# Envoi avec une clé SSH dédiée ; --ignore-existing ne remplace aucun fichier distant
rsync -a --ignore-existing -e "ssh -i /root/.ssh/id_sauvegarde" "${DEST}/" "${DISTANT}"
# Rétention locale de 7 jours ; la rétention distante se règle chez le fournisseur
find "${DEST}" -type f -mtime +7 -deleteDans une crontab, le caractère % doit être échappé (\%) : appelez plutôt le script par son chemin. Pour la planification sur un hébergement mutualisé, voir la configuration d’une tâche Cron via cPanel.
Préparer le DNS avant la panne
Le DNS est souvent le point de blocage le jour de l’incident. Trois précautions se prennent à froid :
- Séparez le domaine de l’hébergement. Si le bureau d’enregistrement et les serveurs DNS sont chez l’hébergeur en panne, vous risquez de ne plus pouvoir modifier les enregistrements. Un compte distinct, protégé par une authentification à deux facteurs, évite ce piège.
- Connaissez vos TTL. Le TTL fixe la durée pendant laquelle un résolveur garde une réponse en cache. La documentation de Cloudflare le résume ainsi : plus le TTL est long, plus les modifications mettent de temps à s’appliquer. Une baisse décidée pendant la crise n’agit qu’après l’expiration de l’ancienne valeur dans les caches. Un TTL de quelques minutes sur les enregistrements A et AAAA du site, fixé à l’avance, rend la bascule prévisible.
- Inventoriez tout. Notez les enregistrements A, AAAA, CNAME, MX et TXT (SPF, DKIM, DMARC) : une bascule qui oublie les MX coupe la messagerie en même temps que le site.
La commande dig +noall +answer www.exemple.fr A affiche la réponse et le TTL restant ; lancez-la vers plusieurs résolveurs après la bascule.
Basculer vers un autre hébergeur
Une cible de secours n’a de valeur que si elle est prête : même version de PHP, mêmes extensions, même moteur de base de données, accès déjà ouverts. Pour la choisir, voir notre comparatif des hébergeurs web. La procédure tient en neuf étapes, que la personne de permanence doit pouvoir suivre sans improviser :
- Déclarer l’incident : heure, symptôme, périmètre, canal de crise, personne qui décide.
- Préserver les journaux s’ils restent accessibles, surtout en cas de compromission (voir notre procédure pour une boutique piratée).
- Afficher une page de maintenance hébergée ailleurs, pour ne pas prendre de commandes sur un état incertain.
- Choisir la sauvegarde de référence : la plus récente dont la somme de contrôle est valide. Notez sa date.
- Restaurer dans l’ordre : base, configuration, fichiers, PHP et serveur web, certificat TLS, tâches planifiées, services tiers (paiement, e-mail transactionnel), cache démarré à vide.
- Tester la cible sans toucher au DNS public, avec
curl -I --resolve www.exemple.fr:443:192.0.2.10 https://www.exemple.fr/(192.0.2.10 est une adresse réservée à la documentation, à remplacer). - Basculer le DNS, en gardant la procédure de retour arrière.
- Réconcilier les données survenues après la sauvegarde, à partir du tableau de bord du prestataire de paiement : un paiement peut avoir été encaissé sans commande correspondante.
- Lever la maintenance et surveiller au moins un cycle complet des tâches planifiées, depuis l’extérieur de l’infrastructure.
Tester la restauration
Une sauvegarde jamais restaurée n’est qu’une hypothèse. Restaurez dans une base créée pour l’occasion, jamais sur la production :
cd /srv/restauration
sha256sum -c SHA256SUMS-2026-11-01-0300
gpg --decrypt db-2026-11-01-0300.sql.gz.gpg | gunzip \
| mysql --defaults-extra-file=/etc/restore/my.cnf base_de_test
mysql --defaults-extra-file=/etc/restore/my.cnf -N -e \
"SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'base_de_test';"Le déchiffrement se fait sur le poste qui détient la clé privée, pas sur le serveur de production. Écrivez les critères de réussite à l’avance : nombre de tables identique, connexion à l’administration, parcours fiche produit, panier et formulaire sans transaction réelle, quelques médias ouverts au hasard, durée totale comparée au RTO. Refaites l’exercice après chaque changement d’hébergeur, de version de PHP ou de structure du site.
Communiquer pendant l’incident
Hébergez la page d’état et l’adresse de contact hors de l’infrastructure principale, sinon elles tombent avec le site. Préparez trois messages :
- ouverture : ce que vous constatez, ce que vous ignorez, où suivre la suite, sans heure de retour que vous ne maîtrisez pas ;
- mises à jour à cadence annoncée, même sans nouveauté ;
- clôture : ce qui a été restauré, ce que les clients doivent vérifier (une commande passée pendant l’incident, par exemple) et le contact du support.
Une panne peut aussi relever du RGPD. Pour la CNIL, une violation de données personnelles est une perte de disponibilité, d’intégrité ou de confidentialité de ces données, accidentelle ou illicite. Une perte définitive de commandes ou de comptes clients entre dans ce cadre : une notification initiale à la CNIL est attendue dans les 72 heures, et les personnes doivent être informées en cas de risque élevé. Faites le point avec votre délégué à la protection des données sans attendre le retour à la normale.
Après l’incident
Rédigez un compte rendu court : chronologie, durée réelle comparée au RTO, données perdues, étapes bloquantes. Mettez à jour la procédure et l’inventaire, puis planifiez le prochain exercice. La reprise ne remplace pas la prévention : mises à jour, accès limités et surveillance restent la première ligne, comme l’explique notre article sur la protection d’un serveur web. Pour lire les journaux après le retour en ligne, voir le diagnostic d’une erreur 500 avec Nginx.
Questions fréquentes
La sauvegarde automatique de mon hébergeur suffit-elle ?
Non, pas à elle seule. Elle protège contre une erreur de manipulation, mais pas contre la suspension du compte ni contre un sinistre qui touche le prestataire. L’affaire jugée à Lille en 2023 montre qu’une sauvegarde prévue par contrat peut se trouver au même endroit que la production. Gardez une copie chez un autre fournisseur.
Faut-il un second hébergeur actif en permanence ?
Pas forcément. Un compte ouvert chez un autre prestataire, à la bonne version de PHP, et une restauration déjà testée suffisent souvent pour un site dont le RTO se compte en heures. Un second site actif se justifie quand le RTO se compte en minutes.
Combien de temps prend un changement de DNS ?
Au moins la durée du TTL en vigueur avant le changement, car les résolveurs gardent l’ancienne réponse jusqu’à son expiration. Un TTL court réglé à l’avance rend le délai prévisible, sans garantie absolue, les caches locaux pouvant tarder davantage.
Que faire des commandes passées pendant l’incident ?
Ne les ressaisissez pas à l’aveugle. Croisez le tableau de bord du prestataire de paiement et les e-mails de confirmation, puis contactez les clients dont la situation reste incertaine.
Sources
- OVHcloud, « Incendie sur notre site de Strasbourg », message du 10 mars 2021 : https://community.ovhcloud.com/t/incendie-sur-notre-site-de-strasbourg/22111
- Netcraft, « 3.6 million websites taken offline after fire at OVH datacenters », mars 2021 : https://www.netcraft.com/blog/ovh-fire
- IT-Connect, « Incendie OVHcloud : une entreprise indemnisée à hauteur de 100 000 euros », 15 février 2023 : https://www.it-connect.fr/incendie-ovhcloud-une-entreprise-indemnisee-a-auteur-de-100-000-euros/
- CNIL, « Sécurité : Sauvegarder » : https://cnil.fr/fr/securite-sauvegarder
- ANSSI, « Sauvegarde des systèmes d’information – Les fondamentaux » : https://messervices.cyber.gouv.fr/documents-guides/anssi-fondamentaux-sauvegarde_systemes_dinformation_v1-0.pdf
- Cloudflare, documentation DNS, « Time to Live (TTL) », mise à jour du 16 avril 2026 : https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/
- CNIL, « Notifier une violation de données personnelles » : https://www.cnil.fr/fr/notifier-une-violation-de-donnees-personnelles
