Chemin de résolution de la capacité utilisateur ou GSAN Avamar

Summary: Cet article sur le chemin de résolution concerne la gestion et le dépannage des problèmes de capacité GSAN (ou capacité utilisateur) sur Avamar.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

Pour les concepts de base et la compréhension de la capacité du système d’exploitation, voir Avamar : formation générale sur la capacité - chemin de résolution (en anglais)

Il est souvent plus facile à envisager la capacité GSAN en tant qu’espace et utilisation pour les sauvegardes client.

Comme le résume cet article de formation, une compréhension raisonnable des sujets suivants est nécessaire pour poursuivre la lecture de cet article :
  • Connaissances de base sur la déduplication
  • Connaissances de base sur le point de contrôle, la validation des points de contrôle (hfscheck), et le nettoyage, ainsi que l’importance de chacun.
  • La différence entre la capacité GSAN (ou utilisateur) et la capacité du système d’exploitation
  • Taux de modification
  • État stable
 
Les impacts d’une capacité GSAN élevée peut inclure :
  • Un échec de la sauvegarde ou de la réplication lorsque l’état d’accès à la grille est passé en « mode admin »
    • Une tâche de sauvegarde client peut échouer avec un message similaire à :  »avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
  • La désactivation automatique du planificateur de sauvegarde (jusqu’à ce qu’une personne l’ait validée)
 
Lorsque les seuils suivants sont dépassés, un avertissement ou une erreur d’événement est généré dans l’interface utilisateur d’administration Avamar :
  • 80 % : avertissement de capacité
  • 95 % : la limite du contrôle d’intégrité est atteinte (cela peut parfois désactiver le planificateur de sauvegarde, au moins jusqu’à ce qu’il soit validé manuellement)
  • 100 % : la limite en lecture seule du serveur est atteinte (la grille passe en mode admin)

Cause

Résumé rapide : le serveur Avamar et la capacité GSAN « dédupliquent » les données de sauvegarde, ce qui signifie que lorsque certains octets ou fragments de données sont similaires, ils ne sont stockés qu’une seule fois. Toute donnée peut être dédupliquée par rapport à toute autre donnée provenant du même client ou de clients différents sauvegardés sur la même grille Avamar. Étant donné la petite taille de ces fragments de données, Avamar peut identifier de nombreux doublons et économiser une grande quantité de capacité en évitant de stocker les mêmes données à plusieurs reprises.
Le cycle de vie de la capacité des données de sauvegarde client :
  1. Grâce à la déduplication, Avamar n’a besoin de sauvegarder et stocker que les changements mineurs et les différences entre chaque tâche de sauvegarde client. Lorsque de nouvelles sauvegardes (ou des réplications entrantes) sont exécutées, de nouvelles données peuvent être ajoutées, ce qui augmente la capacité ou le taux d’utilisation Avamar. 
  2. Après un certain temps, les sauvegardes expirent selon leur date de rétention et d’expiration configurées et ne sont plus disponibles pour la restauration sur la grille Avamar. 
  3. Lors de l’exécution de la tâche de maintenance Avamar appelée Nettoyage (Garbage Collection, GC), elle identifie toutes les parties ou fragments de données uniques qui ne sont plus nécessaires en raison de l’expiration de ces sauvegardes. Le nettoyage vérifie qu’aucune autre sauvegarde actuelle ne partage les mêmes données (en raison de la déduplication), puis supprime ou libère les fragments de données qui ne sont plus nécessaires pour réduire la capacité ou l’utilisation du serveur Avamar.
 

Lorsque la quantité de données entrantes quotidiennes ajoutée est à peu près identique à la quantité de données quotidiennes nettoyées, on parle d’« état stable ». C’est l’objectif de toute grille Avamar installée.

Avant l’installation et la configuration d’une nouvelle grille Avamar, des calculs généraux de dimensionnement avant l’installation sont réalisés afin de déterminer la capacité nécessaire pour stocker les données de sauvegarde. Ces calculs prennent en compte les exigences de rétention des clients, et la quantité de données à sauvegarder. Ainsi que l’estimation moyenne de déduplication de ces données, etc.

Parfois, la capacité n’atteint pas un état stable. Cela peut être dû à :
  1. un nettoyage qui ne s’exécute pas régulièrement,
  2. des performances de nettoyage insuffisantes ou une durée d’exécution trop courte,
  3. des estimations de déduplication initiales avant l’installation de la grille Avamar inexactes,
  4. les données autres que celles calculées avant l’installation de la grille Avamar sont sauvegardées sur ce serveur Avamar.
  5. Autres raisons

Resolution

Assurez-vous que chaque étape de dépannage ci-dessous est appropriée pour votre environnement :

Remarque : les étapes sont classées dans l’ordre le plus approprié pour isoler le problème et identifier la résolution correcte.
Ne sautez aucune étape.
 
 

Étape 1. Collecte de données :

Assurez-vous qu’il n’existe aucun autre problème non lié à la capacité sur la grille Avamar. Dans le cas contraire, il peut être nécessaire de s’y atteler AVANT de procéder au dépannage de la capacité.

Cela inclut les erreurs matérielles, les problèmes d’intégrité des données (y compris les nœuds hors ligne), les bandes hors ligne, les échecs de validation des points de contrôle ou les tâches de maintenance défaillantes. Si l’un de ces problèmes est présent, le dépannage de la capacité doit être interrompu jusqu’à la résolution complète de ces incidents. Une fois les autres problèmes résolus, la capacité peut être réexaminée.

Il est recommandé d’exécuter un contrôle d’intégrité (Avamar : exécution du script de contrôle d’intégrité proactive_check.pl sur un serveur Avamar Server (en anglais), à minima, la commande status.dpn permet d’obtenir un aperçu rapide et de vérifier la plupart de ces mêmes éléments. Voir Avamar : compréhension de la sortie générée par la commande « status.dpn » (en anglais)

Pour plus d’informations, voir l’article suivant : Avamar : comment appliquer correctement l’approche de la « hiérarchie de dépannage Avamar » (en anglais).

Si une assistance est nécessaire pour résoudre des problèmes non liés à la capacité, créez une demande de service auprès de l’équipe de support Dell Technologies Avamar.

 

Étape 2. Collecte des informations de capacité : 

Voir l’article suivant pour obtenir toutes les informations nécessaires au dépannage des problèmes de capacité Avamar : Avamar : comment collecter les informations nécessaires pour résoudre les problèmes de capacité

À minima, la commande status.dpn ou les valeurs affichées dans l’interface utilisateur d’administration Avamar indiquent la capacité GSAN .

Remarque : la capacité indiquée par la commande status.dpn et l’interface utilisateur diffèrent selon la conception prévue.
 
 

Étape 3. Vérification de la saturation du système d’exploitation :

La commande suivante permet d’afficher la valeur actuelle de la capacité du système d’exploitation pour chaque partition de disque. Si l’une des valeurs a atteint ou dépassé 85 %, comme dans le deuxième exemple de sortie, elle est considérée comme une capacité du système d’exploitation élevée :

avmaint nodelist | egrep 'nodetag|fs-percent-full'
 

Exemple de résultats :

nodetag="0.2"
        fs-percent-full="56.6"
        fs-percent-full="54.7"
        fs-percent-full="54.4"
        fs-percent-full="54.6"
        fs-percent-full="54.7"
        fs-percent-full="54.7"
      nodetag="0.1"
        fs-percent-full="56.2"
        fs-percent-full="54.6"
        fs-percent-full="54.6"
        fs-percent-full="54.8"
        fs-percent-full="54.8"
        fs-percent-full="54.5"
      nodetag="0.0"
        fs-percent-full="56.2"
        fs-percent-full="54.7"
        fs-percent-full="54.8"
        fs-percent-full="54.7"
        fs-percent-full="54.6"
        fs-percent-full="54.6"
  
nodetag="0.2"
        fs-percent-full="94.5"
        fs-percent-full="94.4"
        fs-percent-full="94.2"
        fs-percent-full="94.1"
        fs-percent-full="94.0"
        fs-percent-full="94.0"
      nodetag="0.1"
        fs-percent-full="94.5"
        fs-percent-full="94.3"
        fs-percent-full="94.1"
        fs-percent-full="93.6"
        fs-percent-full="94.0"
        fs-percent-full="93.9"
      nodetag="0.0"
        fs-percent-full="94.4"
        fs-percent-full="94.4"
        fs-percent-full="94.0"
        fs-percent-full="94.1"
        fs-percent-full="92.7"
        fs-percent-full="92.5"
 
Attention : la capacité élevée du système d’exploitation peut ne pas sembler être la principale préoccupation, mais cela empêche le dépannage de la capacité GSAN car le nettoyage ne peut pas s’exécuter si la capacité dépasse 89 %. Ces points sont abordés plus en détail, et des étapes de dépannage sont fournies dans l’article suivant : Avamar : capacité du système d’exploitation (chemin de résolution) (en anglais)
 

Ce n’est que si la capacité du système d’exploitation est inférieure à 85 % que le système doit poursuivre le dépannage de la capacité GSAN . 

 

Étape 4. Problèmes non liés à la capacité, qui peuvent parfois être considérés à tort comme des problèmes de capacité :

Il est possible que des sauvegardes client échouent non pas pour des raisons de « capacité », mais pour des raisons de « quota ». Ces situations peuvent parfois être interprétées à tort comme des problèmes de capacité.

Cela peut être confirmé à l’aide de la commande status.dpn ou d’autres informations collectées affichant une capacité plus faible.

Il est également possible que des sauvegardes client aient échoué ou ne se soient pas exécutées pour d’autres raisons liées à la capacité Non-GSAN . Les informations collectées doivent le confirmer ou peuvent également être consultées dans l’interface utilisateur d’administration Avamar.

Si la capacité GSAN n’est pas élevée, voir les articles suivants :
 

Si la capacité GSAN est élevée, et ces autres capacités sont également élevées, le dépannage peut être effectué dans n’importe quel ordre (sauf pour la capacité du système d’exploitation qui doit toujours être traitée en premier).

Remarque : il est possible que la capacité GSAN , la capacité des métadonnées et la capacité DD peuvent être élevées. Dans ces situations, elles peuvent être traitées dans n’importe quel ordre, contrairement à la capacité du système d’exploitation qui doit toujours être traitée en premier.
 
 
 

Étape 5. Équilibrage des bandes et équilibrage des disques du système d’exploitation :

Sur Avamar, les « bandes » sont les fichiers de conteneur dans lesquels les données de sauvegarde sont stockées sur les nœuds de données (à l’exception d’une grille Avamar à nœud unique).

On s’attend à ce que les bandes soient « équilibrées » ou réparties uniformément sur les différents disques et nœuds de la grille, mais parfois, elles peuvent être déséquilibrées.

Par conception, sur Avamar, la plus grande partition de nœud ou de disque constitue le facteur limitant la capacité Avamar.

Ceci est intentionnel pour qu’aucun des disques ou nœuds ne crée plus de bandes qu’il ne peut gérer (ou autoriser), donc avoir des bandes équilibrées est important pour la Capacité.

Par exemple, lors de l’ajout de nœuds de données supplémentaires pour l’extension de la grille Avamar, l’équilibrage doit être exécuté pour distribuer uniformément les bandes sur les nouveaux nœuds afin de réduire le pourcentage de capacité Avamar global.

Remarque : bien que l’équilibre parfait des bandes soit recherché et souvent observé, des problèmes peuvent survenir et un équilibre « pas totalement » parfait, mais néanmoins proche est observé. L’équipe d’ingénierie d’Avamar a confirmé qu’une différence et une tolérance de 4 % entre les bandes se situent dans les limites attendues.
 
 

Un autre type d’équilibrage à prendre en compte est l’équilibrage des disques du système d’exploitation. Celui-ci concerne uniquement les partitions de données d’un même nœud, et non les partitions sur plusieurs nœuds. 

Si sur le même nœud de données, une partition est beaucoup plus grande ou plus petite qu’une autre partition du MÊME nœud, une limite peut être dépassée appelée « freespaceunbalance ». Bien que cela relève généralement du système d’exploitation et non de la capacité GSAN , cela peut être signalé comme un problème de capacité GSAN .

 

Étape 6. Vérification que le nettoyage se termine correctement : 

Exécutez la commande suivante pour obtenir des informations sur le nettoyage :

dumpmaintlogs --types=gc --days=30 | grep "4201\|2402"
 

Dans l’idéal, le résultat indique que le nettoyage s’est terminé correctement au cours des 30 derniers jours :

2025/10/07-12:00:35.24911 {0.1} <4201> completed garbage collection
2025/10/08-12:00:34.61185 {0.1} <4201> completed garbage collection
2025/10/09-12:00:35.14874 {0.1} <4201> completed garbage collection
2025/10/10-12:00:34.67986 {0.1} <4201> completed garbage collection
2025/10/11-12:00:34.73284 {0.1} <4201> completed garbage collection
2025/10/12-12:00:33.23205 {0.1} <4201> completed garbage collection
2025/10/13-12:00:33.41448 {0.1} <4201> completed garbage collection
2025/10/14-12:00:35.70726 {0.1} <4201> completed garbage collection
2025/10/15-12:00:35.08316 {0.1} <4201> completed garbage collection
2025/10/16-12:00:34.82681 {0.1} <4201> completed garbage collection
2025/10/17-12:00:35.29262 {0.1} <4201> completed garbage collection
2025/10/18-12:00:35.24618 {0.1} <4201> completed garbage collection
2025/10/19-12:00:34.56531 {0.1} <4201> completed garbage collection
2025/10/20-19:06:45.15574 {0.1} <4201> completed garbage collection
2025/10/21-12:00:34.21062 {0.1} <4201> completed garbage collection
2025/10/22-12:00:35.29770 {0.1} <4201> completed garbage collection
2025/10/23-12:00:36.13041 {0.1} <4201> completed garbage collection
2025/10/24-12:00:35.52502 {0.1} <4201> completed garbage collection
2025/10/25-12:00:35.93730 {0.1} <4201> completed garbage collection
2025/10/26-12:00:35.55037 {0.1} <4201> completed garbage collection
2025/10/27-12:00:36.12049 {0.1} <4201> completed garbage collection
2025/10/28-12:00:35.75633 {0.1} <4201> completed garbage collection
2025/10/29-12:00:34.85499 {0.1} <4201> completed garbage collection
2025/10/30-12:00:34.96325 {0.2} <4201> completed garbage collection
2025/10/31-12:00:35.39840 {0.0} <4201> completed garbage collection
2025/11/01-12:00:35.11248 {0.0} <4201> completed garbage collection
2025/11/02-13:00:34.39202 {0.0} <4201> completed garbage collection
2025/11/03-13:00:34.70587 {0.0} <4201> completed garbage collection
2025/11/04-13:00:34.18799 {0.0} <4201> completed garbage collection
2025/11/05-13:00:34.44950 {0.0} <4201> completed garbage collection
 

Les messages d’échec du nettoyage peuvent inclure, sans s’y limiter, les éléments suivants :

2025/11/04-13:00:01.62234 {0.1} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR
2025/11/01-12:35:06.62868 {0.2} <4202> failed garbage collection with error MSG_ERR_BACKUPSINPROGRESS
2025/10/13-12:20:07.35498 {0.7} <4202> failed garbage collection with error MSG_ERR_TRYAGAINLATER
2025/10/27-12:07:44.35485 {0.0} <4202> failed garbage collection with error MSG_ERR_DISKFULL
2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_MISC
2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_TIMEOUT
2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_GARBAGECOLLECT
 

Si le nettoyage a échoué, traitez d’abord ce problème en utilisant l’article suivant comme référence : Avamar : dépannage des échecs du nettoyage (chemin de résolution)
(Si des problèmes ont déjà été résolus, passez à l’étape suivante.)

 

Étape 7. Le nettoyage s’exécute-t-il suffisamment longtemps ?

Avertissement : ne pas confondre avec « MSG_ERR_TIMEOUT » dans les résultats de nettoyage. Cette erreur correspond à un autre problème, traité dans le chemin de résolution des erreurs de nettoyage. Ici, le délai d’expiration signifie que le nettoyage a atteint son temps d’exécution maximal, mais se termine silencieusement et proprement, sans aucune erreur. Les informations de cette étape permettent de confirmer si cela se produit.
 
 

a. Exécutez la commande suivante pour vérifier la durée maximale autorisée pour le nettoyage :

dumpmaintlogs --types=gc --days=30 | grep gcflags
 

Exemple de résultat :

2025/10/07-12:00:20.05509 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/08-12:00:20.09141 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/09-12:00:20.42307 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/10-12:00:20.47775 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
...
2025/11/02-13:00:19.76100 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/03-13:00:19.92093 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/04-13:00:19.42781 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/05-13:00:19.74984 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
 

Notez la valeur maxtime , qui dans cet exemple est de 14 400 (secondes).
(Une valeur de 0 signifie illimité)

b. Exécutez la commande suivante pour déterminer la durée d’exécution du nettoyage et le nombre de « validations » effectuées :
(les validations concernent les couches des données de sauvegarde stockées. Par exemple, imaginez une capacité GSAN comme les couches d’un oignon. Les couches extérieures doivent être décollées ou retirées avant que les couches intérieures ne soient visibles. Chaque série est une couche des données stockées GSAN .)

dumpmaintlogs --types=gc --days=30 | grep passes | cut -d ' ' -f1,14-20
 

Exemple de résultat :

2025/10/07-12:00:35.24463 passes="24" start-time="1758283220" elapsed-time="250" end-time="1758283235"/>
2025/10/08-12:00:34.60779 passes="3" start-time="1758369620" elapsed-time="70" end-time="1758369627"/>
2025/10/09-12:00:35.14232 megabytes-recovered="1" passes="4" start-time="1758456020" elapsed-time="85" end-time="1758456028"/>
2025/10/10-12:00:34.67590 passes="3" start-time="1758542420" elapsed-time="72" end-time="1758542427"/>
...
2025/11/02-13:00:34.38348 megabytes-recovered="2" passes="18" start-time="1762088419" elapsed-time="89" end-time="1762088427"/>
2025/11/03-13:00:34.69743 passes="18" start-time="1762174819" elapsed-time="9" end-time="1762174828"/>
2025/11/04-13:00:34.17943 megabytes-recovered="8" passes="22" start-time="1762261219" elapsed-time="134" end-time="1762261228"/>
2025/11/05-13:00:34.44187 megabytes-recovered="2" passes="16" start-time="1762347619" elapsed-time="119" end-time="1762347628"/>

 

Notez le nombre de validations et le elapsed-time (secondes).

 

c. Supposons que maxtime est différent de zéro, calculez les 2/3 de maxtime, et comparez-le au temps écoulé.
(Dans l’exemple ci-dessus, 2/3 sur 14 400 correspond à 9 600, et tous les résultats de temps écoulé sont bien en dessous de ce chiffre.)

  • Si le elapsed-time est inférieur au 2/3 du maxtime, il est probable que le nettoyage se soit terminé plus tôt car il n’y avait plus de données à nettoyer.

  • Si le nombre de validation est élevé (14 ou plus), il est probable que le nettoyage supprime une quantité suffisante de données.
    Remarque : n’oubliez pas que si aucune donnée n’a expiré et qu’il n’y a rien à nettoyer, la valeur des validations devrait être faible. Il est donc préférable de comprendre également l’ensemble de la situation et de l’environnement. Ne supposez pas que quelques validations impliquent un problème.
 

Divers problèmes peuvent ralentir l’exécution du nettoyage ou ne pas tout analyser. Cela peut inclure un manque de temps ou de jours d’exécution par le passé, une configuration incorrecte, des erreurs, etc.

En cas de préoccupations concernant le maxtime, ou le nombre de validations, créez une demande de service auprès de l’équipe de support Dell technologies Avamar pour approfondir la procédure d’enquête.

 

Étape 8. S’il est suspecté que le nettoyage n’a pas supprimé suffisamment de données ou les données attendues :

S’il est confirmé que le nettoyage est en cours d’exécution suffisamment longtemps, il est possible que les données ne soient pas collectées pour des raisons indépendantes au nettoyage. Ci-dessous une liste des raisons documentées qui doivent généralement être vérifiées :

a. Vérifiez que les sauvegardes sont configurées pour expirer au moins éventuellement ou régulièrement. Si les sauvegardes ne sont pas fréquemment expirées, le nettoyage n’aura pas beaucoup de travail à faire.

b. Utilisez cet article pour trouver les « Top Change Rate » Clients : Avamar : gestion de la capacité avec le script capacity.sh (en anglais). (Passez en revue « % OF TOTAL » et « CHGRATE ».)

c. Cas de hachages ignorés par Avamar : Le nettoyage Avamar signale des « hachages ignorés » qui ne peuvent pas être nettoyés. (En anglais) Si ces événements se produisent occasionnellement, il n’y a pas lieu de s’inquiéter et ils peuvent être ignorés.

d. Il existe un indicateur ou une option qui force le serveur Avamar à conserver la dernière sauvegarde et la plus récente de chaque client. Ceci est utilisé à des fins de sécurité afin d’éviter qu’un client ne voie toutes ses sauvegardes expirer accidentellement. Cependant, cela peut causer d’autres problèmes en ce qui concerne le nettoyage des données et Le nettoyage. L’équipe de support Dell Technologies Avamar peut confirmer si cette fonctionnalité est activée.

e. Cas où les sauvegardes ont été récemment basculées de GSAN vers DD backend ou si une sauvegarde GSAN accidentelle est survenue, mais que la capacité GSAN ne diminue pas, veuillez créer une demande de service auprès de l’équipe de support Dell Technologies Avamar pour une enquête plus approfondie.

 

Étape 9. La grille Avamar est sous-dimensionnée pour la quantité de données actuelles ou attendues à ajouter :

Après avoir examiné toutes les autres solutions et causes possibles pour la haute capacité, et qu’il ne s’agit pas d’un problème de configuration ou de données accidentelles :

Cela signifie que les données peuvent nécessiter une suppression ou des options explorées, telles que la migration de certains clients vers d’autres grilles Avamar, l’ajout de nouveaux nœuds de données, etc.

 

Étape 10. Validation des événements de capacité et reprise du planificateur de sauvegarde si nécessaire :

a. Une fois les problèmes de capacité résolus, confirmez tous les événements liés à la capacité dans l’interface utilisateur d’administration Avamar.

b. Reprise du planificateur de sauvegarde :

dpnctl start sched
 

Pour toute autre question sur la capacité Avamar, la formation, le dépannage, etc., voir : Avamar : problèmes et questions liés à au dépannage de la capacité - Toutes les capacités (chemin de résolution) (en anglais)

Additional Information

Le nettoyage manuel ou « agressif » n’est pas recommandé.
(Il s’agit d’une référence à l’exécution du nettoyage en dehors des heures automatiques planifiées.)
  • Cette action peut, à elle seule, « masquer » et dissimuler les problèmes réels, lesquels réapparaîtront souvent quelques jours ou semaines plus tard, rendant cette opération manuelle inutile et chronophage.
  • De plus, un nettoyage manuel peut ne pas s’exécuter aussi efficacement qu’un nettoyage lancé selon la planification prévue.
 
Les étapes de résolution décrites ci-dessus ne mentionnent ni ne recommandent en aucun cas de modifier les paramètres de capacité maximale du disque propres à la capacité GSAN .
  • Ce type de modification ou d’action n’est généralement pas effectué et ne doit pas être envisagé par défaut. Toute modification doit être approuvée par un ingénieur Avamar de niveau L2 ou par un SME (Subject Matter Expert).
  • Ces actions peuvent souvent entraîner des dommages permanents à une grille Avamar de différentes manières, qui ne peuvent être résolus que par l’ajout de nœuds de stockage supplémentaires ou par un redéploiement complet.
 

Il est important de comprendre que les actions répertoriées ci-dessus ne sont pas réalisées par l’équipe de support, car celle-ci cherche à résoudre les problèmes de capacité de la manière la plus bénéfique et la plus sûre possible.

Affected Products

Avamar

Products

Avamar, Avamar Server
Article Properties
Article Number: 000164132
Article Type: Solution
Last Modified: 07 Nov 2025
Version:  10
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.