Les sauvegardes de A à Z
Tout le monde sauvegarde. Presque personne ne restaure. Ce mémo prend le problème par l'autre bout : ce que vous devez pouvoir remonter, en combien de temps, et comment le prouver avant d'en avoir besoin.
Avant d'appliquer ce mémo
Les manipulations décrites ici peuvent entraîner une perte de données ou l'indisponibilité d'un service. Avant d'en appliquer une seule : faites une sauvegarde complète et vérifiez qu'elle se restaure, travaillez d'abord sur un environnement sans enjeu, et n'exécutez aucune commande dont vous ne comprenez pas l'effet.
Ce mémo est un contenu pédagogique de portée générale. Il ne tient pas compte de votre situation, n'a pas valeur de conseil professionnel, et son application relève de votre seule responsabilité. Avertissement et limites d'usage
1. Contre quoi on se protège Cinq sinistres, pas un seul
La plupart des dispositifs de sauvegarde ne couvrent qu'un seul risque, le plus rare, et laissent les quatre autres à découvert. Commencer par nommer les scénarios évite de construire une protection asymétrique.
| Le sinistre | Ce que ça donne concrètement | Ce qui protège vraiment |
|---|---|---|
| Panne matérielle | Le disque du serveur lâche, la machine ne redémarre pas. | N'importe quelle copie ailleurs. C'est le cas le plus simple, et le seul que couvre l'hébergeur. |
| Erreur humaine | Une suppression de trop, un import qui écrase, une mise à jour ratée. | Un historique. Une copie unique écrasée chaque nuit ne sert à rien si l'erreur date de mardi. |
| Rançongiciel | Les fichiers sont chiffrés, y compris les sauvegardes accessibles depuis la machine. | Une copie hors de portée du serveur. Voir la section 11. |
| Corruption silencieuse | Un bug abîme les données pendant des semaines sans que personne le voie. | Une rétention longue, seule à couvrir un dégât découvert tardivement. |
| Perte d'accès | Litige, compte suspendu, prestataire injoignable, carte bancaire expirée. | Une copie chez vous, indépendante du fournisseur. |
2. La règle 3-2-1 Trois chiffres, et ce qu'on y ajoute depuis
L'original et deux sauvegardes.
Pour que la même panne ne les emporte pas ensemble.
Ailleurs que là où vivent les données.
+ Ce que la pratique a ajouté
Deux chiffres complètent la règle depuis que les rançongiciels s'attaquent aux sauvegardes elles-mêmes :
- 1 copie inaltérable ou hors ligne, que rien de connecté ne peut effacer ni chiffrer
- 0 erreur au contrôle : une sauvegarde dont l'intégrité n'a pas été vérifiée ne compte pas dans le décompte
Le second point est le plus souvent ignoré, et c'est celui qui décide de tout. Une sauvegarde n'existe qu'à partir du moment où quelqu'un a prouvé qu'elle se relit.
3. Quoi sauvegarder Et ce qui ne sert à rien
1 Indispensable
- La base de données, dans un export cohérent, pas une copie des fichiers de la base pendant qu'elle tourne
- Les fichiers déposés par les visiteurs et l'administrateur : images, documents, pièces jointes. Ils n'existent nulle part ailleurs
- Les fichiers de configuration propres au serveur, à commencer par celui qui porte les identifiants
- Les certificats et clés que vous avez générés vous-même
- La zone DNS, exportée une fois et à chaque modification. Elle ne pèse rien et se reconstitue très mal de mémoire
- Le contenu éditorial s'il vit en base : c'est le travail de plusieurs années
2 Inutile, et coûteux
- Le code source, s'il est déjà versionné et poussé sur une forge. Il est sauvegardé par nature
- Les dépendances installées, qui se réinstallent à partir d'un fichier de description
- Le cache et les fichiers temporaires, qui se régénèrent seuls
- Les journaux anciens, sauf obligation légale de conservation
Sauvegarder l'inutile n'est pas neutre : ça rallonge la durée des sauvegardes, gonfle la facture de stockage, et surtout ça rallonge la restauration au moment où chaque minute compte.
Un export de base cohérent, et l'archive des fichiers
# Export SQL compressé, daté mysqldump --single-transaction --quick --routines \ -u UTILISATEUR -p BASE | gzip > base-$(date +%F).sql.gz # Les fichiers déposés, sans le cache ni les dépendances tar czf fichiers-$(date +%F).tar.gz \ --exclude='*/cache/*' \ --exclude='*/node_modules/*' \ storage/uploads public/medias
4. Complète, différentielle, incrémentale Le compromis place contre simplicité
| Forme | Ce qu'elle copie | Place | Restauration |
|---|---|---|---|
| Complète | Tout, à chaque fois. | Élevée | La plus simple Un seul fichier à remonter |
| Différentielle | Ce qui a changé depuis la dernière complète. | Moyenne | Deux fichiers : la complète, puis la dernière différentielle |
| Incrémentale | Ce qui a changé depuis la précédente sauvegarde, quelle qu'elle soit. | Faible | La plus fragile Toute la chaîne, et un maillon manquant casse tout |
Ce que ça donne en pratique
Pour un site dont les données pèsent quelques gigaoctets, la sauvegarde complète quotidienne reste le meilleur choix : le stockage coûte moins cher que la complexité, et la restauration ne dépend d'aucune chaîne. Les formes incrémentales prennent leur sens quand le volume rend la complète impossible dans la nuit.
Un schéma qui tient sans y penser : une complète par jour conservée une semaine, une par semaine conservée un mois, une par mois conservée un an. Trois niveaux, trois horizons, et une capacité de retour arrière qui couvre l'erreur découverte tard.
5. Où stocker les copies Quatre emplacements, quatre rôles
Sur le serveur lui-même
Utile pour restaurer vite une erreur récente, sans rien télécharger. Ne compte pour rien en cas de panne, de compromission ou de perte d'accès : la copie disparaît avec la machine.
Rôle : confort, jamais protection.
Chez un stockage tiers
Un espace objet ou un service de sauvegarde, chez un fournisseur différent de l'hébergeur. C'est la copie hors site du 3-2-1, celle qui travaille vraiment.
Rôle : la sauvegarde principale.
Chez vous
Un disque externe, synchronisé périodiquement. Lent à mettre à jour, mais totalement indépendant de tout fournisseur, de toute facture et de tout litige.
Rôle : la copie de dernier recours.
Hors ligne ou inaltérable
Un disque débranché, ou un stockage qui interdit techniquement la suppression avant une date. C'est la seule copie qu'un rançongiciel ne peut pas atteindre.
Rôle : survivre à une attaque.
6. La sauvegarde de l'hébergeur Ce qu'elle couvre, ce qu'elle ne couvre pas
! Les quatre questions à poser avant de compter dessus
- Quelle profondeur ? Sept jours ne rattrapent pas une corruption découverte au bout d'un mois.
- Qui déclenche la restauration ? Si elle passe par un ticket au support, votre délai de reprise dépend de leur charge de travail, pas de vous.
- Restauration partielle possible ? Remonter un seul fichier ou une seule table, ou tout écraser d'un bloc ?
- Est-ce facturé ? Certaines offres incluent la sauvegarde et facturent la restauration, au moment précis où vous n'êtes pas en position de discuter.
7. Automatiser sans y penser Et surtout, être prévenu quand ça rate
Une sauvegarde manuelle est une sauvegarde qui s'arrête le jour où vous êtes occupé. L'automatisation n'est pas un luxe ici, c'est la condition de la régularité.
1 Les quatre étapes d'un script qui tient
- Produire l'export de base et l'archive des fichiers, datés
- Envoyer la copie vers le stockage distant
- Faire tourner : supprimer ce qui dépasse la rétention prévue
- Rendre compte : écrire un journal, et alerter en cas d'échec
La quatrième étape est celle qu'on oublie, et c'est la seule qui distingue une sauvegarde d'une illusion de sauvegarde.
La trame d'un script quotidien, à adapter
#!/bin/bash set -euo pipefail # s'arrêter à la première erreur JOUR=$(date +%F) DEST=/sauvegardes mysqldump --single-transaction --quick -u "$DBUSER" \ -p"$DBPASS" "$DBNAME" | gzip > "$DEST/base-$JOUR.sql.gz" tar czf "$DEST/fichiers-$JOUR.tar.gz" storage/uploads public/medias # Copie distante, puis rotation locale au-delà de 7 jours rclone copy "$DEST" distant:sauvegardes/monsite find "$DEST" -name '*.gz' -mtime +7 -delete # Trace lisible : c'est elle qu'on surveille echo "$JOUR ok $(du -sh $DEST | cut -f1)" >> "$DEST/journal.txt"
8. Chiffrer les copies Et le piège de la clé
Une sauvegarde contient tout ce que contient votre site, souvent en clair : coordonnées de clients, messages, commandes. Déposée chez un tiers, elle devient une base de données complète sur un serveur que vous ne maîtrisez pas. Le chiffrement avant envoi règle la question.
Ce qu'il faut chiffrer
Tout ce qui quitte votre infrastructure. La copie locale sur le serveur peut rester en clair, elle est déjà protégée par les droits d'accès ; la copie distante, non.
Le piège, et il est mortel
Une sauvegarde chiffrée dont la clé était stockée sur le serveur perdu est un fichier définitivement illisible. Le chiffrement transforme alors votre protection en destruction.
La clé se conserve ailleurs : gestionnaire de mots de passe, coffre, support hors ligne. Et elle se teste, comme le reste.
9. Tester la restauration La seule section qui prouve quelque chose
Une sauvegarde non restaurée n'est pas une sauvegarde, c'est une intention.
Tant que vous n'avez pas remonté une copie et vérifié que le site fonctionne, vous ne savez rien de vos fichiers. Vous savez seulement qu'ils existent et qu'ils pèsent quelque chose.
1 Le test complet, une fois par an
- Prendre la sauvegarde la plus récente, sans la choisir
- La restaurer sur un environnement séparé, jamais sur la production
- Ouvrir le site : page d'accueil, une page profonde, une image déposée
- Vérifier une donnée récente : la dernière commande, le dernier message reçu
- Chronométrer l'opération du début à la fin
- Noter ce qui a manqué, ce qui a coincé, ce qui n'était pas documenté
Ce chronomètre est votre délai de reprise réel. Tant que vous ne l'avez pas mesuré, toute promesse faite à un client sur ce sujet est une supposition.
Le contrôle mensuel, en trois minutes
- La dernière sauvegarde date-t-elle bien d'hier ?
- Sa taille est-elle cohérente avec les précédentes ? Une chute brutale signale un export tronqué
- L'archive s'ouvre-t-elle, et l'export SQL contient-il bien la fin du fichier ?
10. Combien de données puis-je perdre ? Deux questions qui décident de tout
Derrière deux sigles employés dans tous les contrats se cachent deux questions très concrètes, à poser avant de choisir une fréquence de sauvegarde.
Combien de temps de travail puis-je perdre ?
C'est ce que le métier appelle le RPO. Si vous sauvegardez chaque nuit et que le sinistre survient à 17 h, vous perdez la journée. La réponse dicte la fréquence, pas l'inverse.
Un site vitrine peut perdre une journée sans conséquence. Une boutique qui enregistre des commandes toute la journée, non.
Combien de temps puis-je rester à l'arrêt ?
C'est le RTO, et c'est le chronomètre de la section 9. Il dicte le format : une sauvegarde parfaite qui demande huit heures de restauration ne convient pas à un site qui doit revenir en deux heures.
11. Le cas du rançongiciel Pourquoi une sauvegarde en ligne ne suffit plus
! Ce qui a changé
Les attaques modernes ne chiffrent pas immédiatement. Elles s'installent, observent, et cherchent d'abord les sauvegardes : partages réseau, disques montés, identifiants de stockage distant trouvés dans les scripts. Elles les détruisent, puis chiffrent la production. La demande de rançon n'arrive qu'une fois le retour arrière rendu impossible.
Conséquence directe : toute sauvegarde atteignable depuis le serveur, avec des droits de suppression, doit être considérée comme perdue dans ce scénario.
Les trois parades, par ordre d'efficacité
- Une copie hors ligne, sur un support débranché. Imbattable, et démodée à tort
- Un stockage inaltérable, qui interdit techniquement la suppression avant une échéance
- Des droits en écriture seule pour le compte de sauvegarde, sans droit d'effacement
Ajoutez une rétention longue : une intrusion reste souvent en place plusieurs semaines, et les sauvegardes récentes peuvent déjà contenir le programme malveillant.
12. Le plan minimal, en une heure Ce qu'on met en place aujourd'hui
15 min : Une sauvegarde manuelle complète
Export de la base et archive des fichiers déposés, téléchargés sur votre machine. Vous avez déjà une copie hors site, ce qui n'était pas le cas il y a un quart d'heure.
20 min : Le script et sa tâche planifiée
La trame de la section 7, une exécution par nuit, sept jours de rétention locale et une copie distante.
10 min : Les droits et l'alerte
Compte de dépôt sans droit de suppression, et alerte si rien n'est arrivé depuis vingt-quatre heures.
15 min : La première restauration
Remonter ce que vous venez de sauvegarder, sur un environnement de test. C'est le seul moment où vous saurez que le dispositif fonctionne. Chronométrez, et notez.
Les cinq règles qui résument ce mémo
- La sauvegarde de l'hébergeur est un filet, pas votre dispositif.
- Base et fichiers déposés se sauvegardent ensemble, ou pas du tout.
- Le compte de sauvegarde écrit, il n'efface jamais.
- L'échec doit être bruyant, le succès silencieux.
- Une sauvegarde non restaurée n'est pas une sauvegarde.
Mémo publié par NET&PRO à titre pédagogique. Information générale, sans garantie d'exactitude, d'exhaustivité ni d'actualité, et sans valeur de conseil personnalisé. Avertissement et limites d'usage
Dans le glossaire
Les mots croisés au fil de ce mémo, définis en une phrase. Ils sont soulignés dans le texte : un clic y mène directement.
Mémos liés
Mettre un site en ligne de A à Z
Nom de domaine, hébergement, transfert du code, HTTPS, droits, sauvegardes : la mise en ligne expliquée pas à pas.
Lire le mémoLa Cybersécurité de A à Z
De Zero Trust à l'IA offensive : menaces 2026, fondamentaux, attaques modernes, cas Mythos, IA défensive et offensive, outils.
Lire le mémoNom de domaine et DNS de A à Z
Ce que vous possédez vraiment quand vous achetez un domaine, comment se lit une zone, ce que fait chaque type d'enregistrement, pourquoi la propagation n'existe pas.
Lire le mémoLe faire vous-même
Une sauvegarde se met en place en une soirée. Ce qui demande de la discipline, c'est de la tester, et c'est justement ce qui distingue une sauvegarde d'un fichier oublié.
- Le temps réel : deux heures pour installer et programmer, puis une heure par trimestre pour éprouver la restauration.
- Les outils gratuits : l'extension de sauvegarde de votre CMS et un espace de stockage à quelques euros par mois. La règle des trois copies ne coûte presque rien.
- Le piège : garder la sauvegarde sur le serveur qu'elle protège. Un piratage ou une erreur d'hébergeur emporte alors les deux d'un coup.
Si vous préférez me le confier
Sur ce sujet, voici ce que je fais pour mes clients. Les formules disent ce qui est compris, ce qui ne l'est pas, et ce que ça coûte au bout de trois ans.