Vue diagnostic rapide
La tâche se termine ou progresse, mais la durée est devenue beaucoup plus longue qu’habituellement.
- Bande passante insuffisante
- Stockage source/destination lent
- Taux de changement élevé
- Comparer les débits historiques
- Contrôler I/O source et cible
- Contrôler le réseau
- Corriger le goulot d’étranglement identifié
- Adapter la fenêtre ou la planification
- Optimiser les exclusions uniquement selon les recommandations éditeur
Plan technicien contextualisé
Regardez si le débit a réellement chuté.
Le contrôle doit identifier l’étape exacte en échec et montrer un état sain du snapshot/writer/capacité pour le composant testé.
Si cette couche est saine, conservez l’horodatage du job et poursuivez avec repository, transport ou authentification.
Si cette couche est en défaut, conservez l’erreur exacte éditeur/VSS et réparez ce composant avant toute suppression de chaîne, snapshot ou point de restauration.
Surveillez la latence disque.
Le contrôle doit identifier l’étape exacte en échec et montrer un état sain du snapshot/writer/capacité pour le composant testé.
Si cette couche est saine, conservez l’horodatage du job et poursuivez avec repository, transport ou authentification.
Si cette couche est en défaut, conservez l’erreur exacte éditeur/VSS et réparez ce composant avant toute suppression de chaîne, snapshot ou point de restauration.
Mesurez le débit et les erreurs.
Le contrôle doit identifier l’étape exacte en échec et montrer un état sain du snapshot/writer/capacité pour le composant testé.
Si cette couche est saine, conservez l’horodatage du job et poursuivez avec repository, transport ou authentification.
Si cette couche est en défaut, conservez l’erreur exacte éditeur/VSS et réparez ce composant avant toute suppression de chaîne, snapshot ou point de restauration.
Un taux de changement inhabituel peut expliquer la durée.
Le contrôle doit identifier l’étape exacte en échec et montrer un état sain du snapshot/writer/capacité pour le composant testé.
Si cette couche est saine, conservez l’horodatage du job et poursuivez avec repository, transport ou authentification.
Si cette couche est en défaut, conservez l’erreur exacte éditeur/VSS et réparez ce composant avant toute suppression de chaîne, snapshot ou point de restauration.
Répétez le même test de validation après correction et confirmez que le symptôme initial a disparu. Validez la stabilité avant de clôturer l’incident.
Avant toute modification de configuration, relevez la valeur actuelle et prévoyez le retour arrière.
Escaladez si le débit chute brutalement sans changement de volumétrie ni réseau.
＋Afficher le guide détaillé completExplications détaillées et contenu de dépannage original.
La tâche se termine ou progresse, mais la durée est devenue beaucoup plus longue qu’habituellement.
Causes probables
- Bande passante insuffisante
- Stockage source/destination lent
- Taux de changement élevé
- Antivirus/EDR
- Déduplication ou compression coûteuse
- Fenêtre de sauvegarde trop courte
Diagnostic étape par étape
- 1
Comparer les débits historiques
Regardez si le débit a réellement chuté.
- 2
Contrôler I/O source et cible
Surveillez la latence disque.
- 3
Contrôler le réseau
Mesurez le débit et les erreurs.
- 4
Comparer le volume modifié
Un taux de changement inhabituel peut expliquer la durée.
Solutions possibles
- Corriger le goulot d’étranglement identifié
- Adapter la fenêtre ou la planification
- Optimiser les exclusions uniquement selon les recommandations éditeur
Escaladez si le débit chute brutalement sans changement de volumétrie ni réseau.