L'Expert de vos Sauvegardes et de la Protection de vos Données !La Solution adaptée à vos besoins
Que faire si…
La sauvegarde de cette nuit a échoué
Une sauvegarde en échec une nuit n’est pas un sinistre, c’est un délai : la dernière copie saine a au moins 48 heures si celle de la veille avait réussi. Plusieurs échecs de suite sont un incident de protection : on en cherche la cause le jour même, on ne se contente pas d’acquitter l’alerte.
L’essentiel
- Lisez le message d’erreur, pas seulement le voyant rouge : place, source absente, identifiants, fichiers verrouillés, débit, agent arrêté.
- Un job « réussi » peut avoir copié un dossier vide : regardez la taille copiée.
- Notez la date de la dernière réussite et dites-la au responsable du service concerné.
- Relancez après correction, puis vérifiez la nuit suivante.
- Trois échecs en un mois sur la même machine : changez le paramétrage, pas seulement le bouton « relancer ».
1. Lire l’erreur, pas seulement le voyant rouge
Les causes ordinaires, dans l’ordre où elles apparaissent :
| Cause | Signe | Correction |
|---|---|---|
| Plus de place sur la destination, ou quota atteint | Erreur d’écriture, rétention qui se raccourcit | Augmenter le volume, ou raccourcir l’historique en connaissance de cause |
| Source éteinte, hors réseau, chemin changé | Lettre de lecteur ou partage renommé ; job « réussi » sur un dossier vide | Rétablir la source, corriger le chemin, vérifier la taille copiée |
| Identifiants refusés | Mot de passe de compte de service expiré | Rétablir le compte : sinon, toutes les nuits échoueront |
| Fichiers verrouillés ou base non mise au repos | Copie partielle | Utiliser la méthode prévue pour les bases ouvertes ; une base SQL dans cet état n’est pas restaurable proprement |
| Lien trop lent ou coupé | Job interrompu en fin de fenêtre | Incrémentale plus efficace, fenêtre plus longue, ou moins de données inutiles |
| Agent arrêté sur la machine | Aucun envoi | Redémarrer le service, chercher pourquoi il s’est arrêté |
Le cas le plus trompeur est le job vert sur un dossier vide. L’ANSSI demande que la sauvegarde fasse systématiquement l’objet d’un contrôle, en surveillant notamment un volume de données ou de fichiers incohérent, des lenteurs réseau et des modifications de configuration. Une taille copiée qui chute brutalement d’une nuit à l’autre mérite autant d’attention qu’un échec.
2. Savoir à quand remonte la dernière réussite
C’est la seule date qui compte pour le RPO du jour. Si elle a plus de quelques jours, dites-le à la personne responsable du service concerné. Elle travaille sans filet, elle doit le savoir. Acquitter l’alerte dans la console sans cette phrase est le geste qui transforme un incident en perte de données deux semaines plus tard.
3. Relancer après correction
Relancez un job manuel une fois la cause traitée. Attendez qu’il se termine. Un échec de relance signifie que la cause est encore là. Le lendemain matin, vérifiez la nuit suivante : beaucoup de corrections « évidentes » ne tiennent pas le second passage.
Un job réussi prouve qu’une copie a été écrite, pas qu’elle se restaure. Pour une base SQL Server, Microsoft précise que la commande de vérification d’une sauvegarde ne contrôle pas la structure des données qu’elle contient. L’ANSSI demande que les sauvegardes soient testées régulièrement, avec une procédure de restauration écrite ; le NIST recommande lui aussi de tester les sauvegardes pour s’assurer que les fichiers se récupèrent sans erreur. Après un incident de sauvegarde, une restauration d’essai d’un fichier ou d’une base est le meilleur contrôle. Voir Comment tester qu’une sauvegarde fonctionne ?.
4. Si cela se répète
Trois échecs en un mois sur la même machine : le périmètre, le débit ou le produit sont inadaptés. On change un paramètre (exclure un dossier géant et inutile, découper le job, augmenter le stockage), on ne se contente pas de relancer à la main chaque lundi.
Checklist du matin
- Tous les jobs de la nuit sont-ils terminés, et pas seulement « non en erreur » ?
- La taille copiée est-elle cohérente avec celle des nuits précédentes ?
- La date de dernière réussite de chaque machine critique a-t-elle moins de 24 heures ?
- Les alertes ont-elles été lues par une personne nommée, et pas seulement reçues ?
- La place restante sur la destination couvre-t-elle la rétention prévue ?
Chez WeDoBack
La surveillance 24 h/24 porte sur les sauvegardes et envoie une alerte quand une sauvegarde n’aboutit pas. L’alerte est le début de cette page, pas la fin. En INTEGRAL, deux heures d’assistance par mois peuvent servir à traiter la cause. En SMART, l’assistance est facturée à l’intervention : l’échec reste visible par le client dans la console, et c’est à lui de le lire. L’assistance se joint au 09 72 50 78 28, de 9 h à 13 h et de 14 h à 17 h 30 (heure de Paris). Pour dimensionner le stockage, l’ordre de grandeur publié est le volume actuel multiplié par trois, puis un ajustement après une semaine d’usage : un volume trop juste se voit aux jobs qui échouent ou à une rétention qui se raccourcit. La clé de chiffrement, détenue par le client, n’a pas de rôle dans l’échec d’envoi : si le job échoue, la copie distante n’a simplement pas été mise à jour.
Questions fréquentes
Une nuit d’échec, est-ce grave ?
Rarement, si la nuit précédente a réussi et que la cause est corrigée dans la journée. Le risque vient de l’accumulation : chaque nuit d’échec allonge la quantité de travail qui serait perdue en cas de sinistre. Au-delà de quelques jours, c’est un incident à signaler à la direction.
Le statut « réussi » suffit-il à prouver qu’une sauvegarde est bonne ?
Non. L’ANSSI demande un contrôle systématique des sauvegardes, notamment des volumes de données incohérents, et des tests de restauration réguliers. Pour SQL Server, Microsoft précise que la vérification d’une sauvegarde ne contrôle pas la structure des données qu’elle contient : seule une restauration réelle, suivie d’un contrôle de cohérence, le prouve.
Qui doit surveiller les alertes de sauvegarde ?
Une personne nommée, avec un suppléant pour les congés. Une alerte qui arrive dans une boîte partagée que personne ne lit équivaut à une absence d’alerte. Décidez aussi qui prévient la direction quand la dernière réussite dépasse un seuil convenu à l’avance.
Pour aller plus loin
Sources
Documents consultés en octobre 2026.
- Sauvegarde des systèmes d’information – Les fondamentaux (ANSSI-BP-100, v1.1, 27 novembre 2025) — ANSSI
- Pourquoi et comment bien gérer ses sauvegardes ? — Cybermalveillance.gouv.fr
- RESTORE VERIFYONLY (Transact-SQL) — Microsoft Learn
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Offres et tarifs — WeDoBack
Besoin d’aide maintenant ?
Ne restaurez rien avant d’avoir identifié une copie saine. Nous pouvons vous guider.
Appeler le 09 72 50 78 28ou nous écrireUn incident en cours ?
Nos équipes vous aident à identifier la bonne copie et à restaurer, du lundi au vendredi de 9 h à 13 h et de 14 h à 17 h 30.