Il y a deux types de restauration. Celle qu'on fait dix fois par an — un fichier effacé, une version précédente — et celle qu'on fait une fois tous les trois ans, sous pression, avec un dirigeant qui demande toutes les dix minutes quand ça revient.
La seconde ne s'improvise pas. Voici ce qu'il faut avoir vérifié avant.
Le scénario, dans l'ordre réel
Un serveur ne démarre plus. Avant même de penser restauration, trois questions se posent, et l'ordre compte :
- Le matériel est-il exploitable ? Si le disque est mort, la cible sera un autre disque, ou une machine virtuelle.
- Faut-il repartir à l'identique, ou ailleurs ? Remonter sur le même matériel est le plus simple ; remonter dans une VM est souvent le plus rapide quand le matériel est indisponible.
- Quel est le point de retour acceptable ? La dernière sauvegarde de la nuit, ou une antérieure si l'incident a une origine logicielle.
C'est à la troisième question qu'on découvre si la rétention a été pensée.
Ce qui bloque en pratique
L'amorçage
Restaurer les fichiers d'un système ne suffit pas à le faire démarrer. Il faut la partition système, la partition EFI ou le secteur d'amorçage selon le mode, et une table de partitions cohérente.
C'est là que les sauvegardes « fichiers seulement » montrent leur limite : elles contiennent les données, pas la machine. Un serveur remonté à partir d'une sauvegarde de fichiers demande une réinstallation complète du système avant de pouvoir récupérer quoi que ce soit — comptez une journée, pas une heure.
Les partitions logiques
Un disque partitionné en MBR avec une partition étendue contient une chaîne de blocs EBR : chaque partition logique pointe vers la suivante. Restaurer les partitions une à une sans recalculer cette chaîne produit un disque que le système ne sait pas lire.
C'est le genre de détail qui ne se voit que le jour où on en a besoin. Un outil de restauration doit le traiter tout seul.
Les disques 4Kn
Les disques à secteurs de 4096 octets se généralisent sur les serveurs récents. Restaurer une image prise sur un disque 512 octets vers un disque 4Kn — ou l'inverse — n'est pas une simple copie. Si votre outil n'en dit rien, testez avant d'en avoir besoin.
Le redimensionnement
Le disque de remplacement fait rarement exactement la même taille. Plus grand, il faut étendre ; plus petit, il faut vérifier que les données rentrent. Un plan de restauration sérieux refuse un redimensionnement impossible en l'expliquant, plutôt que de le tenter et de laisser un volume corrompu.
Le cas où le matériel n'est pas disponible
C'est la situation la plus courante en PME : le serveur est mort un vendredi, le remplacement arrive mardi, et l'activité ne peut pas attendre.
La réponse est le P2V — restaurer une machine physique vers une machine virtuelle. Si vous avez un hôte ESXi avec des ressources libres, le serveur reprend dessus le temps que le matériel arrive, puis repart vers le physique ensuite.
Ce qu'il faut vérifier avant d'y compter :
- L'outil sait-il créer la VM cible, ou faut-il la préparer à la main ?
- Le mapping disque par disque entre la source et la cible est-il explicite ?
- La VM est-elle arrêtée et redémarrée automatiquement pendant l'opération ?
- Peut-on piloter tout cela à distance, ou faut-il être devant l'hyperviseur ?
L'environnement de démarrage
Quand la machine ne démarre plus, l'agent de sauvegarde installé sur son système ne démarre pas davantage. Il faut donc un environnement de secours : sous Windows, WinPE.
Deux questions à poser à votre outil :
- L'agent fonctionne-t-il sous WinPE, ou faut-il un média de restauration séparé à construire et à maintenir ?
- Le même support de sauvegarde sert-il, ou faut-il avoir préparé une image spécifique ?
La réponse détermine si la restauration commence dans les dix minutes ou dans les trois heures.
La checklist, à faire une fois par client
À dérouler au calme, pas le jour du sinistre.
| Point | Vérifié |
|---|---|
| La sauvegarde système inclut la table des partitions | ☐ |
| Une restauration complète a été testée, et chronométrée | ☐ |
| Le délai mesuré est compatible avec ce que le client attend | ☐ |
| La clé de récupération est conservée ailleurs que sur la machine sauvegardée | ☐ |
| Le média ou l'environnement de démarrage est disponible et à jour | ☐ |
| Une cible de repli virtuelle existe, avec des ressources libres | ☐ |
| La procédure est écrite, et lisible par quelqu'un d'autre que son auteur | ☐ |
La dernière ligne est celle qu'on saute. Elle est pourtant décisive : le jour du sinistre, celui qui a installé la sauvegarde est en vacances.
Le test qui vaut tous les audits
Prenez un poste de test. Effacez-le. Restaurez-le entièrement, depuis la sauvegarde, sans consulter la documentation de l'éditeur. Chronométrez.
Vous apprendrez en une demi-journée ce qu'aucune fiche produit ne dit : la vitesse réelle, les étapes qui coincent, et la qualité du support quand vous appelez parce que quelque chose ne se passe pas comme prévu.
BeBackup couvre le fichier, la partition, le disque entier, le P2V vers ESXi et le démarrage sous WinPE, depuis la même sauvegarde et la même console. Voir la page restauration ou demander une démo.