Automatiser ses sauvegardes sur un serveur dédié, ça donne vite l’impression d’avoir réglé le problème une bonne fois pour toutes.
- Le cron tourne, les fichiers partent vers le stockage distant, et on passe à autre chose
- Sauf que la plupart des échecs ne viennent pas du paramétrage initial
- Ils arrivent des semaines plus tard
- Personne n’a regardé les journaux, personne n’a tenté une restauration, et le job tourne dans le vide depuis un mois
- Brien Posey, dans un article du MagIT paru fin septembre 2024, recense douze erreurs courantes sur les sauvegardes de machines virtuelles
La fausse tranquillité des jobs planifiés
Un script de sauvegarde qui se lance toutes les nuits produit des logs. Encore faut-il les ouvrir. Beaucoup d’administrateurs découvrent un échec silencieux parce qu’ils se fient à un simple « le fichier est là », sans vérifier ni sa taille, ni sa date, ni son intégrité. Or une sauvegarde peut échouer à mi-chemin, produire un fichier tronqué et ne déclencher aucune alerte visible. Le serveur, lui, continue de tourner normalement, ce qui renforce l’illusion que tout va bien.
Le MagIT recommande d’ailleurs, pour les machines virtuelles, de privilégier les sauvegardes au niveau de l’hôte plutôt que d’installer un agent dans chaque système invité. La raison est simple : un agent installé dans la VM dépend de la santé de cette VM.
Si elle plante, l’agent plante avec elle et la sauvegarde suivante ne part jamais. À l’échelle d’un serveur dédié, le principe reste valable : plus votre chaîne de sauvegarde dépend de services internes fragiles, plus vous multipliez les points de défaillance. C’est mécanique.
Le piège des fenêtres de sauvegarde trop espacées
Et puis il y a les données transactionnelles. L’article de Data-IT, signé Mhamed Akkari et daté du 7 juillet 2025, rappelle qu’elles doivent être sauvegardées quotidiennement, voire plusieurs fois par jour. Une base de données qui encaisse des commandes toute la journée ne peut pas attendre une fenêtre nocturne unique.
Si le serveur tombe en fin d’après-midi, une sauvegarde réalisée à 3 h du matin signifie des heures de transactions perdues. Le rythme de sauvegarde doit coller au rythme des écritures, pas à une habitude confortable.
Ces journaux qui parlent mais que personne n’écoute
Un serveur dédié qui héberge SQL Server écrit énormément d’informations dans ses journaux, et la plupart restent lettre morte. Microsoft Learn documente pourtant des traces précises, comme un message de restauration qui indique le nombre de pages traitées et le débit obtenu. Ce genre d’entrée, quand on sait la lire, confirme qu’une restauration a réellement abouti et pas seulement qu’elle a été lancée. La nuance change tout.
Les événements étendus sont encore moins consultés, alors qu’ils donnent une visibilité en temps réel sur ce qui se passe pendant une sauvegarde. Depuis SQL Server 2016, l’événement backup_restore_progress_trace aide à suivre la progression d’une sauvegarde ou d’une restauration, étape par étape.
C’est justement là que se cachent les signaux faibles : un job qui ralentit soudainement, une sauvegarde qui prend trois fois plus de temps sans raison, des erreurs intermittentes sur un volume de stockage. Autant d’indices qui précèdent les pannes franches.
Microsoft Learn cite l’exemple d’un journal qui contient une ligne du type « RESTORE DATABASE successfully processed 315 pages in 0.372 seconds ». Ce message ne dit pas seulement que ça a marché : il dit à quelle vitesse, sur combien de pages, et si le débit est cohérent avec vos habitudes. Comparer ces chiffres d’une semaine à l’autre aide à repérer une dérive avant qu’elle ne devienne un incident. Franchement, qui le fait sur ses serveurs ?
Une sauvegarde non testée n’est pas une sauvegarde
Le scénario classique, c’est l’administrateur qui découvre une corruption le jour où il doit restaurer. Le fichier de sauvegarde est là, il pèse le bon poids, mais il ne s’ouvre pas. La seule façon de savoir si une sauvegarde automatisée est restaurable, c’est de la restaurer. Pas de l’ouvrir, pas de vérifier sa somme de contrôle : de la dérouler dans un environnement isolé et de s’assurer que les données sont cohérentes.
Une méthode simple consiste à programmer une restauration de test sur une machine jetable, à intervalle régulier. Certaines équipes le font chaque semaine, d’autres chaque mois, mais le principe reste le même : la sauvegarde n’est validée que lorsqu’elle a prouvé qu’elle pouvait revenir. Tant que ce test n’est pas automatisé lui aussi, il finit par sauter. Il demande du temps et ne produit aucun résultat visible tant que tout va bien.
Il faut aussi se méfier des sauvegardes qui réussissent trop facilement. Un fichier qui se génère en quelques secondes alors que la base fait plusieurs centaines de gigaoctets, ça pue. Soit le job ne capture qu’une partie des données, soit il écrit dans le vide. Les temps anormaux, dans un sens comme dans l’autre, sont des indicateurs à surveiller de près. Un serveur dédié ne pardonne pas longtemps ce genre d’approximation.
Ce que les erreurs de restauration vous apprennent
Quand une sauvegarde est corrompue, la première réaction est souvent de se jeter sur la sauvegarde précédente. C’est logique, mais ça ne règle rien. Une corruption détectée sur le fichier du jour doit lancer une vérification des fichiers antérieurs, parce que le problème remonte parfois à plusieurs jours, voire plusieurs semaines. Si vous ne gardez que sept jours d’historique, une corruption apparue il y a dix jours vous laisse sans filet. L’historique trop court devient alors un facteur aggravant.
Les causes possibles sont nombreuses, et toutes ne viennent pas du script lui-même : un disque qui commence à renvoyer des erreurs de lecture, une connexion réseau instable vers le stockage distant, un cache matériel défaillant, un espace disque qui s’est rempli pendant l’écriture. Les journaux système contiennent généralement la trace de l’incident, mais encore faut-il les croiser avec les journaux de l’outil de sauvegarde. C’est dans ce croisement que se trouve l’explication, rarement dans un seul fichier.
Brien Posey insiste sur un point que beaucoup de monde oublie : les erreurs de sauvegarde ne sont pas toujours des échecs francs. Elles se présentent souvent comme des ralentissements, des fichiers plus petits que d’habitude, des jobs qui se terminent avec un code de sortie bizarre mais une notification verte. Une surveillance qui ne se déclenche que sur un échec complet passe à côté de la majorité des problèmes. Le diable est dans les détails, et les détails sont dans les journaux.
Du coup, que faire concrètement si votre sauvegarde est corrompue ? D’abord, arrêter de lancer de nouvelles sauvegardes qui écraseraient les anciennes. Ensuite, isoler le fichier suspect et tenter une restauration partielle sur un espace de test. Enfin, remonter la chaîne : d’où vient le fichier, par quel chemin est-il passé, quels journaux couvrent la période où il a été créé. La réponse est presque toujours dans cette remontée, pas dans le remplacement du script.
Construire une routine de vérification qui tient dans la durée
Un serveur dédié se gère dans la durée, et la routine de vérification doit être pensée pour survivre aux périodes chargées. Si elle repose sur la bonne volonté d’une seule personne, elle mourra au premier gros projet.
L’idéal est d’automatiser la surveillance elle-même : des alertes sur les temps de sauvegarde, sur les tailles de fichiers, sur les codes de sortie inhabituels. Les journaux d’événements étendus SQL Server peuvent être collectés et agrégés, puis comparés à des seuils définis une fois pour toutes.
La restauration de test, elle, doit être intégrée au calendrier comme une tâche parmi d’autres. Le lundi matin, le script de test tourne pendant que vous lisez vos mails, et vous n’avez qu’à consulter son rapport. Si le rapport n’existe pas, c’est que le test n’a pas tourné et ça doit déclencher une alerte aussi forte qu’une sauvegarde manquante. Une surveillance qui ne surveille pas sa propre exécution ne sert à rien.
Les ressources ne manquent pas pour approfondir le sujet, à commencer par l’article de Data-IT sur les erreurs de sauvegarde informatique ou la documentation Microsoft sur les erreurs SQL Server. Pour une veille plus générale sur l’administration système et les bonnes pratiques, florianriviere.fr propose des retours d’expérience utiles. Mais retenez surtout une chose : la technique de sauvegarde est au point depuis longtemps, c’est la régularité du contrôle qui fait défaut.
À quoi ressemblerait votre prochaine panne si vous deviez restaurer les données d’hier avec le script que vous n’avez pas relu depuis trois mois ? Prenez dix minutes pour consulter les journaux de la nuit dernière, vérifier la taille du dernier fichier et lancer une restauration de test sur une machine isolée. C’est le seul moyen de savoir si votre filet de sécurité tient encore. Consultez les ressources citées pour approfondir chaque point.
