Un client m'appelle à 7h12 un lundi. Le serveur de fichiers est chiffré. Le DSI est en vacances. Et la personne qui a fait la dernière sauvegarde ? Partie en septembre, deux ans plus tôt. « On a bien un NAS quelque part, non ? » Personne ne savait où. Voilà à quoi ressemble la réalité d'une restauration de données quand on a passé trois ans à repousser le sujet.
Ce guide de sauvegarde et restauration de données n'est pas une liste de bonnes intentions. C'est ce que j'ai vu tenir debout, et ce que j'ai vu s'effondrer — souvent au pire moment.
Points clés à retenir
- Une sauvegarde non testée ne vaut rien. Le test de restauration est le seul indicateur honnête.
- La règle 3-2-1-1-0 (trois copies, deux supports, une hors site, une immuable, zéro erreur vérifiée) reste la base en 2026.
- Le RPO détermine la fréquence ; le RTO détermine votre tolérance à l'attente. Ce sont deux chiffres différents.
- Une politique de sauvegarde informatique PDF rangée dans un dossier partagé n'a jamais sauvé une entreprise.
- L'ANSSI publie un guide de durcissement qui sert de référence en France pour protéger les dépôts de sauvegarde.
- Le coût d'un jour d'arrêt dépasse presque toujours le coût annuel d'une solution correcte.
Sauvegarde et restauration : deux métiers différents qu'on confond tout le temps
La sauvegarde, c'est le geste mécanique : copier, chiffrer, envoyer ailleurs. La restauration, c'est l'épreuve. Et très peu d'équipes entraînées à la première sont capables de réussir la seconde.
J'ai vu des infrastructures impeccables côté production — documentation propre, monitoring sérieux, alertes qui tombent quand un job échoue — et un désastre complet le jour où il a fallu remonter une base de 400 Go. Pas parce que les sauvegardes étaient absentes. Parce que personne n'avait jamais chronométré une restauration réelle.
RTO et RPO : les deux chiffres à écrire au tableau
Le RPO (Recovery Point Objective) répond à : combien de données puis-je perdre ? Si vous sauvegardez toutes les 24 heures, vous acceptez de perdre jusqu'à une journée de travail. En pratique, la plupart des PME que je côtoie tolèrent 4 heures. Certaines, en réalité, n'en tolèrent aucune.
Le RTO (Recovery Time Objective) répond à : combien de temps puis-je rester à l'arrêt ? Deux heures, huit heures, trois jours ? La réponse honnête est souvent bien plus courte que ce que les dirigeants imaginent. Une chose est de dire « on peut tenir deux jours ». Une autre est de regarder l'activité s'arrêter pendant deux jours.
Ces deux valeurs dictent tout le reste : la fréquence, le support, le budget. Les fixer après avoir choisi l'outil, c'est construire la maison avant les fondations.
Les causes de perte de données ne changent pas
Chaque année, les mêmes causes reviennent, dans le même ordre d'importance : l'erreur humaine arrive en tête, souvent devant la panne matérielle et la cyberattaque. Un fichier écrasé, une suppression de masse, un script lancé sur le mauvais serveur. Ce n'est pas spectaculaire. C'est quotidien.
Et franchement, c'est ce qui rend le sujet ingrat. Personne ne se félicite d'avoir sauvegardé. On ne remarque le dispositif que le jour où il manque.
La règle 3-2-1-1-0, et pourquoi elle tient encore
Trois copies des données. Deux supports différents. Une copie hors site. Une copie immuable. Zéro erreur après vérification.
Les deux derniers chiffres sont ceux qu'on oublie, et ce sont eux qui font la différence depuis que les rançongiciels ciblent spécifiquement les dépôts de sauvegarde. Une copie immuable, c'est une copie qu'on ne peut ni modifier ni supprimer pendant une durée définie — même avec des droits administrateur, même avec le compte de service qui écrit les sauvegardes. Sur ce point précis, le guide de durcissement de l'ANSSI est devenu la référence en France, et je conseille de le lire avant de signer un contrat avec un éditeur. Il est gratuit et il évite des erreurs coûteuses.
Complète, incrémentale, différentielle : le compromis éternel
| Type | Ce qu'elle contient | Avantage | Le piège |
|---|---|---|---|
| Complète | Tout, à chaque fois | Restauration simple et rapide | Volume et durée explosifs |
| Incrémentale | Uniquement ce qui a changé depuis la dernière, quelle qu'elle soit | Rapide, léger | Chaîne fragile : un maillon manquant casse tout |
| Différentielle | Tout ce qui a changé depuis la dernière complète | Compromis correct | Grossit jusqu'à la prochaine complète |
| Synthétique | Une complète reconstruite à partir des incréments | Combine les deux mondes | Dépend fortement de l'outil |
Mon avis, tranché : sur un volume qui bouge peu, la différentielle est plus sûre à gérer. Sur un volume actif, l'incrémentale avec complète synthétique gagne. Mais ce choix se fait après avoir mesuré la fenêtre de sauvegarde réelle, pas avant.
Restaurer un fichier avec Veeam Backup and Replication
Veeam reste l'outil que je vois le plus souvent en environnement virtualisé, et la restauration granulaire est précisément ce qui le rend intéressant au quotidien.
La manipulation de base, pour récupérer un seul fichier sans remonter la machine entière :
- Ouvrez la console et allez dans Home, puis Backups, et sélectionnez la sauvegarde concernée.
- Clic droit, puis Restore guest files et choisissez le système d'exploitation invité. Pour Windows, l'assistant ouvre une session de restauration sans rien écrire sur la VM de production.
- Parcourez l'arborescence jusqu'au fichier. C'est l'étape qui prend le plus de temps, parce qu'on cherche souvent la mauvaise version.
- Sélectionnez la date de restauration souhaitée dans la liste des points de restauration disponibles, puis lancez la copie vers un emplacement temporaire.
- Copiez le fichier vers sa destination finale — et surtout, écrasez uniquement après avoir vérifié le contenu.
La restauration Veeam backup complète d'une VM suit la même logique en passant par Entire VM restore, avec l'option de remonter vers un hôte différent. C'est là que le RTO se joue vraiment : selon la taille du disque et la bande passante disponible, on parle de minutes ou de plusieurs heures.
Deux choses que j'ai apprises à la dure avec cet outil. D'abord, un point de restauration listé n'est pas forcément un point de restauration exploitable — il faut l'ouvrir pour le savoir. Ensuite, vérifiez toujours que le dépôt immuable est bien configuré avant de vous reposer dessus ; sinon vous avez une copie, pas une protection.
Rédiger une politique de sauvegarde qui sert à quelque chose
Une politique de sauvegarde informatique n'est pas un document de conformité. C'est un mode d'emploi pour le jour où la personne qui a tout configuré n'est pas là.
J'ai rédigé ce type de document pour une structure d'une quarantaine de personnes. La première version faisait onze pages. Elle a été lue par personne. La deuxième en faisait deux, avec les fréquences, les responsables et la procédure de restauration d'urgence en une page. Celle-là a servi, réellement, six mois plus tard.
Ce qu'une politique doit contenir, au minimum :
- Les systèmes couverts, et surtout ceux qui ne le sont pas — la liste des exclusions évite bien des malentendus.
- La fréquence et la rétention par type de données, avec la durée de conservation justifiée par un besoin, pas par habitude.
- Qui déclenche une restauration, qui valide, et comment on prévient les utilisateurs.
- La planification des tests de restauration, avec une date dans le calendrier et un responsable nommé.
- L'emplacement des dépôts, y compris hors site, et les accès associés.
Ce dernier point est celui qui manque le plus souvent. Un plan de sauvegarde informatique sans localisation des copies ni liste des personnes habilitées à les restaurer est un document décoratif.
Tester une restauration : le seul indicateur qui compte
Vous voulez connaître la vraie qualité de votre dispositif ? Chronométrez une restauration complète sur un environnement isolé, et notez le temps réel. Pas le temps annoncé par l'éditeur. Le vôtre.
Le rythme que j'applique aujourd'hui : un test de restauration de fichier tous les mois, une restauration applicative complète par trimestre, et une simulation de sinistre total une fois par an. Cette dernière prend une demi-journée et elle est pénible. Elle a aussi révélé, la première fois, que notre procédure de récupération des clés de chiffrement tenait sur un post-it.
À quoi ressemble un plan de sauvegarde informatique solide
Un plan efficace tient sur une page et répond à quatre questions. Que sauvegarde-t-on ? À quelle fréquence ? Où vont les copies ? Qui teste, et quand ? Si vous ne savez pas répondre à ces quatre questions en moins de deux minutes, votre plan existe sur le papier et nulle part ailleurs.
Pourquoi le guide de l'ANSSI sur le durcissement compte
Le principe de base est simple : le compte qui écrit les sauvegardes ne doit pas pouvoir les supprimer. Cela paraît évident. Dans beaucoup d'installations que j'ai auditées, c'était faux. Le guide de l'ANSSI formalise ces exigences et donne un cadre utilisable, notamment pour les segments réseau et les comptes de service. Il n'est pas parfait pour toutes les tailles d'organisation, mais il pose les bonnes questions.
Un dernier point sur les coûts, parce qu'on me le demande à chaque fois. Le budget d'une sauvegarde correcte se situe rarement là où on l'imagine : ce n'est pas le stockage qui pèse, c'est le temps humain passé à la configurer et à la tester. Et ce temps, personne ne le facture… jusqu'au jour où il manque.
Alors, la vraie question n'est pas de savoir si votre sauvegarde tourne cette nuit. C'est de savoir qui, dans votre organisation, saurait la restaurer demain matin — et combien de temps cela lui prendrait. Si la réponse vous échappe, vous venez de trouver votre prochaine tâche.
