Guide de sauvegarde et restauration de données : le manuel essentiel

Un client m'appelle un mardi matin, la voix blanche. Son serveur de fichiers ne répond plus. RAID en délégation, deux disques morts sur quatre. Il me demande : « On a des sauvegardes, hein ? » Et là, je regarde le job de backup qui tournait depuis onze mois sans que personne n'ouvre jamais la console. Le fichier de configuration était corrompu depuis le début. On a tout perdu. Deux téraoctets de devis, de plans et de factures.

Cette histoire n'est pas rare. Elle est même la norme. Un guide de sauvegarde et restauration de données qui se contente de vous dire « faites des copies régulières » ne vous servira à rien le jour où ça casse. Ce qui compte, c'est ce qu'on vérifie, ce qu'on teste, et ce qu'on est capable de restaurer vraiment quand tout brûle.

Je vais vous montrer comment je monte une stratégie de sauvegarde aujourd'hui, ce que j'ai raté pendant des années, et pourquoi la restauration est la seule partie qui mérite votre attention.

Pourquoi vos sauvegardes ne servent à rien (et comment y remédier)

La question qu'on me pose le plus souvent n'est pas « comment sauvegarder ». C'est « pourquoi ma restauration a échoué ». Et la réponse est presque toujours la même : personne n'avait essayé avant.

Les trois erreurs qui reviennent sans cesse

Sur les interventions que j'ai menées ces dernières années, trois schémas reviennent. Pas quatre, pas cinq. Trois, et ils sont têtus.

• Le job qui tourne mais qui rate en silence. La console affiche « succès », mais la destination est saturée depuis des semaines et les derniers points de restauration datent de trois mois.
• La sauvegarde et l'original sur le même volume, voire le même serveur. En cas de chiffrement, les deux partent ensemble.
• Aucun test de restauration documenté. On restaure un fichier par curiosité une fois, on se dit que ça marche, on n'y revient plus.

Franchement, l'erreur numéro trois est la plus vicieuse. Elle donne bonne conscience. On a la sensation d'être couvert parce qu'on a fait l'effort une fois.

Ce que coûte vraiment une perte de données

Je ne vais pas vous sortir un pourcentage sorti de nulle part sur les entreprises qui ferment après un sinistre. Ce chiffre circule partout et personne ne sait d'où il vient. Ce que je peux vous dire, c'est ce que j'ai constaté : sur une PME de trente personnes, deux jours d'arrêt complet du serveur de fichiers, c'est une semaine de chiffre d'affaires partie en fumée, plus les heures supplémentaires, plus la confiance des clients qui se fissure.

Le coût réel n'est pas technique. Il est humain et commercial.

La règle 3-2-1-1-0 expliquée concrètement

Tout le monde connaît la règle 3-2-1. Trois copies, deux supports, une hors site. Elle a vingt ans et elle reste valable. Mais elle a un angle mort : elle ne dit rien sur les rançongiciels, qui chiffrent les copies accessibles depuis le réseau.

C'est pour ça qu'on est passés à 3-2-1-1-0. Je l'applique systématiquement depuis que j'ai vu un client perdre ses trois copies synchronisées en une nuit.

Chiffre	Ce qu'il impose	Pourquoi
3	Trois copies des données	L'original plus deux sauvegardes, jamais une seule
2	Deux supports différents	Deux baies identiques du même modèle tombent rarement pour les mêmes raisons, mais deux technologies distinctes encore moins
1	Une copie hors site	Un incendie, une inondation ou un vol ne connaît pas votre salle serveur
1	Une copie hors ligne ou immuable	Le point décisif contre le chiffrement
0	Zéro erreur vérifiée	Contrôle d'intégrité automatique après chaque écriture

Copie immuable et air-gap : la vraie défense

Le stockage immuable, en écriture unique et lecture multiple, empêche toute modification ou suppression pendant une durée définie. Même un compte administrateur compromis ne peut pas effacer ces objets avant l'expiration de la fenêtre de rétention. C'est mécanique, pas déclaratif.

L'air-gap va plus loin : la copie n'est physiquement pas joignable depuis le réseau. Un support débranché, une bande rangée dans un coffre, un volume monté uniquement le temps de la copie.

Avouons-le, c'est contraignant. Ça oblige à des rotations manuelles, à de la logistique. Mais c'est la seule chose que je n'ai jamais vue céder face à une attaque.

Restaurer un fichier avec Veeam Backup and Replication

Veeam reste la référence sur le marché de la sauvegarde virtualisée, et je l'utilise au quotidien. La restauration de fichier individuel y est rapide, à condition de savoir où cliquer.

La procédure pas à pas

Depuis la console, vous ouvrez la vue Home, puis Backups, et vous déroulez le job qui contient la machine concernée. Clic droit sur la sauvegarde, puis Restore guest files, et vous choisissez le système d'exploitation invité.

L'assistant monte la sauvegarde dans un volume temporaire. Vous naviguez dans l'arborescence comme dans un explorateur classique, vous sélectionnez le fichier, vous cliquez sur Restore, et vous indiquez la destination : l'emplacement d'origine, un autre chemin, ou votre poste local.

Un détail que j'ai mis du temps à comprendre : cette opération ne restaure pas le fichier directement sur le serveur par défaut. Si vous ne choisissez pas la bonne cible, vous écrasez la version actuelle. Sur un fichier partagé en cours d'utilisation, c'est la surprise garantie.

Restauration Veeam Backup : les options avancées

Au-delà du fichier isolé, Veeam propose plusieurs niveaux. La restauration de volume entier, pour repartir sur une base propre. La restauration applicative, qui remet une base de données en cohérence sans passer par le système de fichiers. Et la restauration instantanée, qui démarre une machine directement depuis le dépôt de sauvegarde en quelques minutes, sans attendre la copie complète.

Cette dernière option m'a sauvé sur un serveur de messagerie. RTO annoncé par l'éditeur : quelques minutes. RTO réel chez mon client : onze minutes, parce que la baie de production était saturée. Toujours mesurer.

Restauration Veeam Agent : le cas des postes de travail

Pour les serveurs physiques et les postes nomades, on quitte le monde de l'hyperviseur. Veeam Agent fonctionne au niveau du système d'exploitation, avec sa propre interface.

L'agent propose deux modes. Le volume-level backup capture des volumes entiers, idéal pour une restauration bare-metal. Le file-level backup ne prend que les fichiers choisis, plus léger mais inutilisable pour reconstruire une machine à zéro.

J'ai vu trop d'entreprises cocher le second par souci de place, puis découvrir qu'elles ne pouvaient pas redémarrer un serveur tombé. Si votre objectif est de reconstruire une machine, prenez le volume.

Installation Veeam Backup & Replication : ce qu'on oublie

L'installation elle-même tient en une heure sur un serveur propre : le programme d'installation, la base de données de configuration, la console. Le piège n'est pas là.

Le piège, c'est la sauvegarde de la configuration elle-même. Veeam permet d'exporter sa base de configuration dans un fichier chiffré. Sans ce fichier, reconstruire l'infrastructure après une perte du serveur de sauvegarde, c'est tout refaire à la main : jobs, dépôts, identifiants, planification.

Je programme cet export toutes les semaines, et je le stocke ailleurs. Deux fois, ça m'a évité de repartir de zéro.

Types de sauvegarde et de restauration : ce qu'il faut vraiment distinguer

La confusion entre les deux notions est courante. Sauvegarder, c'est produire une copie à un instant donné. Restaurer, c'est remettre cette copie en service. Ce ne sont pas les mêmes compétences, ni les mêmes personnes, ni les mêmes délais.

Côté sauvegarde, on distingue la complète, l'incrémentale et la différentielle. La complète copie tout, chaque fois. L'incrémentale ne prend que ce qui a changé depuis la dernière, quelle qu'elle soit. La différentielle prend tout ce qui a changé depuis la dernière complète.

Côté restauration, on parle de restauration complète, de restauration sélective d'un élément, et de restauration à un instant précis dans le temps. Cette dernière, la plus puissante, permet de revenir juste avant une corruption ou une suppression accidentelle.

Le choix dépend de deux chiffres que vous devez fixer avant de configurer quoi que ce soit : le RPO (perte de données acceptable) et le RTO (temps d'indisponibilité toléré). Un cabinet médical et une boutique en ligne n'ont pas les mêmes.

Tester pour de vrai : la seule partie qui compte

Voilà mon avis tranché : une politique de sauvegarde sans exercice de restauration régulier est un mensonge administratif. Elle rassure la direction, elle coche une case d'audit, et elle ne protège rien.

Ce que je fais tourner chez mes clients : une restauration partielle chaque mois, une restauration complète d'une machine de test chaque trimestre, et une simulation de sinistre une fois par an. Cette dernière consiste à éteindre un serveur, à ne pas y toucher, et à reconstruire entièrement à partir des copies.

La première fois que j'ai organisé cet exercice, on a mis six heures à comprendre pourquoi la machine restaurée ne redémarrait pas. Un pilote manquant dans la sauvegarde. Six heures, découvertes en conditions réelles, un jour de semaine ordinaire. Je préfère ça à six heures découvertes pendant un vrai sinistre.

Combien de temps faut-il conserver ses sauvegardes ?

Ça dépend entièrement de vos obligations légales et de votre secteur. Certaines activités imposent des durées de conservation longues, d'autres non. Fixez la rétention à partir de ce que la loi et votre assureur exigent, pas à partir de la place disponible sur la baie. C'est une erreur que je vois trop souvent : on dimensionne la rétention selon le disque, pas selon le risque.

Faut-il sauvegarder les données déjà dans le cloud ?

Oui, et c'est un angle mort fréquent. Un service en ligne peut subir une suppression accidentelle, une synchronisation malheureuse ou une compromission de compte. La responsabilité du fournisseur s'arrête souvent à la disponibilité de son infrastructure, pas à vos données. Ce qui est chez lui n'est pas protégé par vous.

Ce que je retiens après toutes ces années

Le jour où ça casse, personne ne vous demandera combien de téraoctets vous sauvegardiez. On vous demandera combien de temps pour redémarrer, et si les données sont complètes.

Alors posez-vous une seule question, ce soir, avant de fermer votre session : si le serveur ne redémarre pas demain matin, quelle est la dernière version de vos fichiers que vous êtes capable de remonter, et en combien de temps ? Si vous ne connaissez pas la réponse avec certitude, vous ne savez pas si vous êtes protégé. Vous l'espérez.

C'est une différence énorme. Et elle ne se voit qu'un seul jour.