Vue diagnostic rapide
L’espace du dépôt de sauvegarde approche de la saturation, ce qui peut provoquer des échecs de jobs ou empêcher les nouvelles chaînes.
- rétention trop longue
- croissance des données sources
- anciens backups orphelins
- Mesurer l’espace libre
- Vérifier la rétention
- Identifier les gros jeux
Plan technicien contextualisé
Comparer espace total, libre et croissance sur plusieurs jours.
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.
Contrôler le nombre réel de points de restauration.
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.
Repérer les jobs et chaînes les plus volumineux.
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.
Comparer le stockage réel avec l’inventaire du logiciel de sauvegarde.
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.
Escalader avant toute suppression manuelle dans un repository dédupliqué, immuable ou géré par un logiciel de sauvegarde.
＋Afficher le guide détaillé completExplications détaillées et contenu de dépannage original.
L’espace du dépôt de sauvegarde approche de la saturation, ce qui peut provoquer des échecs de jobs ou empêcher les nouvelles chaînes.
Causes probables
- rétention trop longue
- croissance des données sources
- anciens backups orphelins
- synthetic full ou snapshots plus volumineux que prévu
Diagnostic étape par étape
- 1
Mesurer l’espace libre
Comparer espace total, libre et croissance sur plusieurs jours.
- 2
Vérifier la rétention
Contrôler le nombre réel de points de restauration.
- 3
Identifier les gros jeux
Repérer les jobs et chaînes les plus volumineux.
- 4
Chercher les données orphelines
Comparer le stockage réel avec l’inventaire du logiciel de sauvegarde.
Solutions possibles
- adapter la rétention au RPO/RTO réel
- augmenter la capacité du repository
- supprimer uniquement les sauvegardes orphelines identifiées
- répartir les jobs sur plusieurs dépôts si nécessaire
Escalader avant toute suppression manuelle dans un repository dédupliqué, immuable ou géré par un logiciel de sauvegarde.