En bref : une stratégie de sauvegarde solide pour les serveurs suit la règle 3-2-1 : trois copies, deux types de supports, une copie hors site. Pour que les sauvegardes survivent aussi à une attaque, au moins une copie doit être protégée contre la suppression par le serveur lui-même. Et seul un test de restauration réussi montre que la sauvegarde fonctionnera en cas d'urgence.
Ce que signifie la règle 3-2-1
La règle 3-2-1 est un principe simple, éprouvé depuis des années, pour la sauvegarde des données :
- 3 copies : les données d'origine et deux sauvegardes.
- 2 types de supports : par exemple disque local et stockage objet, ou stockage serveur et bande.
- 1 copie hors site : dans un autre lieu, chez un autre fournisseur ou hors ligne.
Pour les serveurs web, cela signifie concrètement : une sauvegarde sur le même disque que le site ne compte pas comme copie indépendante. Si le serveur tombe en panne ou est compromis, les deux sont perdues. Pour la direction, la question centrale n'est donc pas « Avons-nous des sauvegardes ? », mais « Pouvons-nous rétablir l'activité à partir d'une copie que l'incident n'a pas atteinte ? »
Une stratégie de sauvegarde pour serveurs qui survit à une attaque
Les attaquants savent que les sauvegardes anéantissent leur travail. Qui a accès à un serveur cherche donc souvent aussi les sauvegardes pour les supprimer ou les chiffrer. Une stratégie moderne étend donc fréquemment la règle 3-2-1 en 3-2-1-1-0 : une copie supplémentaire hors ligne ou immuable, et zéro erreur lors du test de restauration.
Trois principes rendent les sauvegardes résistantes :
- Pull plutôt que push : un système de sauvegarde distinct vient chercher les données sur le serveur web. Le serveur web lui-même ne dispose d'aucun identifiant avec lequel il pourrait supprimer des sauvegardes.
- Immuabilité : stockage objet avec verrou de conservation ou instantanés qui ne peuvent pas être supprimés pendant une durée définie.
- Accès séparés : le compte de sauvegarde n'est pas le même que le compte client de l'hébergeur et dispose de son propre second facteur.
Chiffrez les sauvegardes conservées hors site et gardez la clé séparément. Une clé perdue rend la sauvegarde inutilisable, une clé stockée avec elle rend le chiffrement sans valeur.
Ce qu'il faut sauvegarder
Pour les serveurs web, on ne sauvegarde souvent que la racine web. Pour une restauration complète, des éléments importants manquent alors.
| Domaine | Exemples | Remarque |
|---|---|---|
| Fichiers de l'application | racine web, uploads, thèmes, extensions | Les uploads changent souvent |
| Bases de données | MySQL/MariaDB, PostgreSQL | sauvegarder de façon cohérente, ne pas se contenter de copier des fichiers |
| Configuration | serveur web, pools PHP-FPM, php.ini, tâches cron | nécessaire pour une reconstruction rapide |
| Certificats et clés | certificats TLS, clés d'application | stocker chiffrés et séparément |
| Documentation | accès, dépendances, déroulement de la restauration | sans elle, chaque reconstruction dure plus longtemps |
Exemple : sauvegarder la base de données et les fichiers
L'exemple suivant montre les éléments de base d'une sauvegarde quotidienne. En pratique, un outil de sauvegarde avec chiffrement, déduplication et règles de conservation assure le transfert hors site.
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"
# Sauvegarder la base de données de façon cohérente ; identifiants issus d'un fichier protégé, pas dans la commande
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
--single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"
# Fichiers de l'application et configuration
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d
# Sommes de contrôle pour un contrôle ultérieur
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
Le fichier .backup-my.cnf contient les identifiants d'un utilisateur de base de données qui n'a qu'un droit de lecture et a les droits 0600. --single-transaction assure, pour les tables InnoDB, un état cohérent sans arrêter la boutique.
Ensuite, un système distinct transfère la sauvegarde hors site. Il est important que cette étape soit surveillée : une tâche de sauvegarde qui échoue silencieusement depuis des jours ne se remarque sinon qu'en cas d'urgence. Un message quotidien sur le succès, la taille et la durée suffit, tant que quelqu'un le lit et donne suite aux écarts.
Si vous utilisez en plus les sauvegardes ou instantanés de votre hébergeur, clarifiez par écrit combien de temps ils sont conservés, si vous pouvez restaurer vous-même et si les sauvegardes subsistent en cas de compte résilié ou bloqué. Ces copies sont un bon complément, mais ne remplacent pas une sauvegarde propre et indépendante.
Conservation : pourquoi les anciens états comptent après PHP2Shell
Après une attaque, la sauvegarde la plus précieuse n'est pas la plus récente, mais la plus récente saine. Avec PHP2Shell, selon des articles de presse, une première tentative d'attaque a été observée le 17 octobre 2026, les correctifs sont parus le 21 octobre 2026. Qui ne conserve que sept jours n'a peut-être plus d'état qui se situe sûrement avant l'intrusion possible.
Un schéma éprouvé combine plusieurs périodes, par exemple des sauvegardes quotidiennes pendant quelques semaines, hebdomadaires pendant quelques mois et mensuelles pendant un an. Les périodes exactes dépendent de votre besoin de protection et des obligations de suppression liées à la protection des données.
Il est aussi important de savoir qu'une sauvegarde postérieure à une intrusion peut contenir des webshells ou des fichiers modifiés. Après un incident, ne restaurez jamais à l'aveugle, mais comparez les fichiers avec un état sain et vérifiez-les avant que le site ne revienne en ligne. Des indications sur ce à quoi il faut prêter attention figurent sous Signes de compromission. Un correctif ne supprime aucun logiciel malveillant introduit, et une sauvegarde ne le fait pas non plus d'elle-même.
Tester et documenter la restauration
Une sauvegarde sans test est une hypothèse. Seule la restauration montre si toutes les parties sont présentes, si la clé fonctionne et combien de temps l'opération dure réellement.
- Restaurez régulièrement une sauvegarde complète sur un environnement de test, base de données et configuration comprises.
- Vérifiez si le site fonctionne ensuite entièrement : connexion, commandes, formulaires, e-mails.
- Mesurez la durée et consignez les étapes qui étaient manuelles. Comparez le résultat avec le temps maximal que votre activité peut supporter sans site.
- Déposez le mode d'emploi de la restauration à un endroit accessible même si le serveur est en panne, par exemple dans le plan d'urgence informatique.
Comment PHP SOS aide-t-il concrètement ?
- Nous examinons vos sauvegardes existantes quant à leur exhaustivité, leur conservation, leur séparation du serveur et leur protection contre la suppression.
- Nous mettons en place une sauvegarde 3-2-1 avec copie immuable et testons la restauration avec vous.
- Après un incident, nous identifions le dernier état sain et le restaurons sur un système corrigé dans le cadre de la suppression de malwares.
- Dans le contrat de maintenance de sécurité, nous surveillons en permanence les sauvegardes et effectuons des tests de restauration réguliers.
Questions fréquentes
Que signifie la règle 3-2-1 pour les sauvegardes ?
Trois copies de vos données, sur deux types de supports différents, dont une dans un autre lieu. La règle fait en sorte que ni une panne matérielle, ni une attaque, ni un incendie ne touche toutes les copies en même temps.
La sauvegarde de mon hébergeur suffit-elle ?
C'est un bon complément, mais rarement suffisant. Clarifiez combien de temps l'hébergeur conserve les états, si vous pouvez restaurer vous-même et si un attaquant disposant de votre compte client pourrait supprimer les sauvegardes. Une copie propre et indépendante est recommandée.
Après un piratage, puis-je simplement restaurer la dernière sauvegarde ?
Seulement avec prudence. La dernière sauvegarde peut déjà contenir du code malveillant, et la faille par laquelle l'attaquant est entré est encore ouverte ensuite. Clarifiez et fermez d'abord la cause, puis restaurez un état vérifié sur un système corrigé.
À quelle fréquence dois-je tester la restauration ?
Régulièrement et après des modifications importantes du système. Un rythme fixe, par exemple une restauration complète par trimestre sur un environnement de test, a fait ses preuves. Il est important que le test soit documenté et que les lacunes soient corrigées.