Anticiper un disque plein et les sauvegardes qui échouent sans bruit

Deux pannes arrivent sans prévenir alors qu'elles se préparent pendant des semaines : le disque qui se remplit, et la sauvegarde qui échoue chaque nuit sans que personne ne lise le rapport. La première arrête un service un lundi matin. La seconde se découvre le jour où il faut restaurer.

#Le disque plein

#Un seuil ne suffit pas

Une alerte à 90 % prévient trop tard sur un volume qui grossit de 20 Go par jour, et trop tôt sur un volume stable rempli à 91 % depuis deux ans. La bonne question est : à ce rythme, quand sera-t-il plein ?

#Vérifier sans outil

1. Relevez l'espace libre de chaque volume fixe, à la même heure, chaque jour pendant deux semaines.
2. Calculez la croissance moyenne par jour, en écartant les jours de ménage ou d'agrandissement.
3. Divisez l'espace libre par cette croissance pour obtenir le nombre de jours restants.

Get-Volume | Where-Object DriveType -eq 'Fixed' | Select-Object DriveLetter, FileSystemLabel, @{n='Libre (Go)';e={[math]::Round($_.SizeRemaining/1GB,1)}}, @{n='Taille (Go)';e={[math]::Round($_.Size/1GB,1)}}

Les causes les plus fréquentes : des journaux d'application que rien ne purge, un dossier de sauvegarde local qui accumule, des profils utilisateurs sur un serveur de bureau à distance, et le journal de transactions d'une base SQL Server.

#Le journal de transactions

En mode de récupération FULL, le journal de transactions d'une base ne se vide qu'après une sauvegarde du journal. Sans cette sauvegarde, il grossit jusqu'à remplir le disque. La colonne log_reuse_wait_desc dit ce qui l'empêche de se vider : LOG_BACKUP veut dire qu'il attend une sauvegarde du journal.

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases
ORDER BY name;

Choisissez en connaissance de cause. Le mode FULL sert à restaurer à un instant précis et demande des sauvegardes du journal régulières. Le second mode vide le journal de lui-même : il suffit si revenir à la dernière sauvegarde de la base vous convient.

#Les sauvegardes qui échouent sans bruit

#Les causes habituelles

• le travail SQL Server Agent échoue, et l'e-mail d'échec part vers une boîte que personne ne lit ;
• le service SQL Server Agent ne redémarre pas après une mise à jour, et les travaux ne tournent plus ;
• le script de sauvegarde planifié s'arrête sur une erreur sans rien signaler ;
• une nouvelle base a été créée sans être ajoutée au plan de sauvegarde.

#Vérifier les bases SQL Server

SELECT d.name, d.recovery_model_desc,
  MAX(CASE WHEN b.type = 'D' THEN b.backup_finish_date END) AS derniere_complete,
  MAX(CASE WHEN b.type = 'L' THEN b.backup_finish_date END) AS dernier_journal
FROM sys.databases d
LEFT JOIN msdb.dbo.backupset b ON b.database_name = d.name
WHERE d.name <> 'tempdb'
GROUP BY d.name, d.recovery_model_desc
ORDER BY derniere_complete;

Une base avec NULL dans la colonne derniere_complete n'a pas de sauvegarde connue de cette instance. Un logiciel qui sauvegarde les machines virtuelles peut toutefois copier la base sans laisser de trace dans msdb : vérifiez alors dans ce logiciel.

SELECT j.name, h.run_date, h.run_time, h.message
FROM msdb.dbo.sysjobhistory h
JOIN msdb.dbo.sysjobs j ON j.job_id = h.job_id
WHERE h.run_status = 0 AND h.step_id = 0
ORDER BY h.run_date DESC, h.run_time DESC;

Le contrôle d'intégrité (DBCC CHECKDB) compte autant que la sauvegarde, puisque la sauvegarde d'une base déjà corrompue restaure une base corrompue. La date du dernier contrôle réussi se lit dans le champ dbi_dbccLastKnownGood de DBCC DBINFO WITH TABLERESULTS.

#Vérifier un script de sauvegarde

Pour un script planifié (copie de fichiers, export, sauvegarde d'un équipement), inversez la logique. Au lieu d'attendre un message d'échec, attendez un signal de réussite : le script appelle une adresse à la fin de son travail, et une alerte part si l'appel n'arrive pas dans le délai prévu. Un script qui plante, une tâche désactivée ou un serveur éteint donnent alors le même résultat : pas de signal, donc une alerte.

#Tester la restauration

Une sauvegarde ne vaut que si elle se restaure. RESTORE VERIFYONLY vérifie que le fichier est lisible, pas que la base revient. Restaurez une base sur une instance de test au moins une fois par trimestre, et notez la durée : c'est votre délai réel de reprise.

#Ce que FirstSI suit

La date de saturation suit la méthode décrite plus haut. Chaque jour, FirstSI retient le remplissage le plus élevé, trace la droite des 30 derniers jours et la prolonge jusqu'à 90 % et 100 %. Il lui faut 7 jours de mesures. Un agrandissement ou un gros ménage est reconnu comme une rupture, et le calcul repart des jours qui suivent. Voir Prévision de capacité.

Si un outil externe sauvegarde vos bases, cochez Sauvegardée par un outil externe dans le réglage de l'instance. La règle des sauvegardes passe alors en constat faible, sans incident. Voir Tâches de fond des bases.

Pour un heartbeat, le script appelle son URL de ping à la fin du travail. Avec $ErrorActionPreference = 'Stop', une erreur PowerShell arrête le script avant l'appel :

$ErrorActionPreference = 'Stop'
# … commandes de sauvegarde …
Invoke-RestMethod -Uri "https://console.exemple.fr/api/heartbeat/<identifiant>/ping" -Method Post

Un programme externe (robocopy, par exemple) ne déclenche pas d'erreur PowerShell. Testez son code de retour avant l'appel. Voir HostMonitor : disponibilité des services.

Les volumes pleins dans moins de 14 jours, ou déjà remplis à 95 %, apparaissent aussi dans la liste À traiter du tableau de bord.

#Pour aller plus loin

• DBMonitor : bases de données : performances, sessions, blocages et requêtes de contrôle métier.
• Alertes et notifications : être prévenu par e-mail, Teams ou Slack.
• Durcir ses serveurs Windows : correctifs, antivirus et persistance sur les mêmes serveurs.

Présentation : Supervision SQL Server et MariaDB, performances↗

Source : · Docs FirstSI · mis à jour le 11/10/2026