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

Summary: Cet article de résolution est consacré à la gestion et au 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 initiaux et la compréhension de la capacité du système d’exploitation (OS), reportez-vous à Avamar : Formation générale sur les capacités-Résolution

Il est souvent plus facile d’envisager GSAN Capacité 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 requise pour poursuivre la suite de cet article :
  • Notions de base sur la déduplication
  • Compréhension de base des points de contrôle, validation des points de contrôle (hfscheck) et la collecte des ordures, ainsi que l’importance de chacun.
  • La différence entre GSAN (ou Utilisateur) Capacité et capacité du système d’exploitation
  • Taux de modification
  • État stable
 
Impacts d’une GSAN La capacité peut inclure :
  • Échec de la sauvegarde ou de la réplication lorsque l’état d’accès à la grille est passé en « mode administrateur »
    • Une procédure de sauvegarde d’un client peut échouer avec un message semblable à :  »avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
  • Désactivation automatique de l’ordonnanceur de sauvegarde (jusqu’à ce qu’il soit reconnu et effacé par quelqu’un)
 
Lorsque les seuils suivants sont franchis, un avertissement d’événement ou une erreur est généré dans l’interface utilisateur d’administration d’Avamar :
  • 80 % - Avertissement de capacité
  • 95 % : la limite du bilan de santé est atteinte (cela peut parfois désactiver le planificateur de sauvegarde, au moins jusqu’à ce qu’il soit accusé de réception manuellement)
  • 100 % : limite de lecture seule du serveur atteinte (la grille passe en mode administrateur)

Cause

En bref : Avamar Server et GSAN La capacité « déduplique » les données de sauvegarde, ce qui signifie que lorsque certains octets ou segments de données sont similaires, il n’est nécessaire de stocker ce fragment qu’une seule fois. Toutes les données peuvent être « dédupliquées » par rapport aux autres données provenant du même client ou d’un client différent sauvegardé sur la grille Avamar. Étant donné que ces segments de données sont petits, il peut trouver de nombreux doublons et économiser beaucoup de capacité en évitant d’avoir à les sauvegarder à plusieurs reprises.
Cycle de vie de la capacité des données de sauvegarde client :
  1. Avamar n’a besoin d’enregistrer et de stocker que les modifications mineures et les différences entre chaque procédure de sauvegarde client en raison de la déduplication. À mesure que de nouvelles sauvegardes (ou réplications entrantes) s’exécutent, il peut ajouter de nouvelles données et augmenter la capacité ou la valeur d’utilisation d’Avamar. 
  2. Au bout d’un certain temps, les sauvegardes expirent en fonction de leur rétention et de leur expiration configurées et sont introuvables sur la grille Avamar disponibles à la restauration. 
  3. Lorsque la tâche de maintenance Avamar appelée Garbage Collection (GC) s’exécute, elle trouve toutes les parties ou fragments de données uniques qui ne sont plus nécessaires en raison de ces sauvegardes expirées. GC vérifie qu’aucune autre sauvegarde en cours 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 de l’instance d’Avamar Server.
 

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

Avant l’installation et la configuration d’une nouvelle grille Avamar, des calculs généraux de dimensionnement préalables à l’installation sont effectués afin de déterminer la capacité requise pour stocker les données de sauvegarde. Ces calculs sont basés sur les exigences de rétention des clients et sur la quantité de données à sauvegarder. Il estime également la quantité moyenne de données qui pourrait être dédupliquée, et ainsi de suite.

Toutefois, il arrive que la capacité n’atteigne pas un état stable. Cela peut être causé par :
  1. Le nettoyage de la mémoire ne fonctionne pas de manière cohérente
  2. Les performances du nettoyage de la mémoire sont lentes ou ne fonctionnent pas assez longtemps
  3. Les estimations de la déduplication avant l’installation de la grille Avamar n’étaient pas suffisamment précises
  4. Les données autres que celles calculées avant l’installation de la grille Avamar sont sauvegardées sur cette instance d’Avamar Server.
  5. Autres raisons

Resolution

Vérifiez que chaque étape de dépannage ci-dessous est adaptée à l’environnement :

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

Étape 1. Collecte de données:

Assurez-vous qu’il n’existe aucun autre problème hors capacité avec la grille Avamar. Si c’est le cas, ils peuvent nécessiter une intervention AVANT la capacité de dépannage.

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 de point de contrôle ou les tâches de maintenance défaillantes. Si l’un de ces problèmes est en cause, le dépannage de la capacité doit être arrêté et les autres problèmes doivent être résolus. Une fois les autres problèmes résolus, la capacité peut être réexaminée.

Un bilan de santé doit être exécuté (Avamar : Exécution du script de bilan de santé proactive_check.pl sur une instance d’Avamar Server, mais au minimum status.dpn peut donner une vue d’ensemble et une vérification rapides de la plupart de ces mêmes problèmes. Voir Avamar : Comment comprendre la sortie générée par la commande status.dpn

Pour plus d’informations, reportez-vous à l’article suivant : Avamar : Application correcte de l’approche « hiérarchie de dépannage Avamar ».

Si vous avez besoin d’aide pour résoudre des problèmes d’incapacité, créez une demande de service auprès de l’équipe de support Dell Technologies Avamar.

 

Étape 2. Collecte d’informations sur la capacité : 

Reportez-vous à ce qui suit pour obtenir toutes les informations requises pour résoudre les problèmes de capacité Avamar : Avamar : Comment collecter les informations nécessaires au dépannage des problèmes de capacité

À tout le moins, le status.dpn ou les valeurs de l’interface utilisateur d’administration d’Avamar affichent le GSAN capacité.

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

Étape 3. Vérifiez si la capacité du système d’exploitation est saturée :

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 ayant une capacité élevée du système d’exploitation :

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

Exemples de sorties :

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 : Bien que la capacité élevée du système d’exploitation ne semble pas être la principale préoccupation, cela empêche le dépannage GSAN Capacity, car le nettoyage de la mémoire ne peut pas s’exécuter si la capacité dépasse 89 %. Cette procédure est abordée plus en détail et les étapes de dépannage sont décrites dans la section : Avamar : Capacité du système d’exploitation (SE) (chemin de résolution)
 

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

 

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

Il est possible que les sauvegardes client échouent non pas pour des raisons de « capacité », mais plutôt pour des raisons de « quota ». Ceux-ci peuvent parfois être interprétés à tort comme des capacités.

Cette situation peut être confirmée par le status.dpn ou une autre sortie collectée affichant une capacité inférieure.

Il est également possible que les sauvegardes client aient échoué ou ne se soient pas exécutées en raison d’autres Non-GSAN Raisons de capacité. Les informations collectées doivent confirmer cette information, ou sont également visibles dans l’interface utilisateur d’administration d’Avamar.

Si la demande GSAN Si la capacité n’est pas élevée, reportez-vous aux articles suivants :
 

Si la demande GSAN Si la capacité 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 prioritaire).

Remarque : Il est possible que l’option GSAN , la capacité de 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. Répartition par 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 elles peuvent parfois devenir déséquilibrées.

Dans Avamar, la plus grande partition de disque ou de nœud est le facteur limitatif en matière de capacité Avamar.

Ceci est intentionnel, de sorte qu’aucun des disques ou nœuds ne crée plus de bandes qu’il ne peut en gérer (ou ne le permet). Par conséquent, il est important d’avoir des bandes équilibrées 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 répartir uniformément les bandes sur les nouveaux nœuds et réduire ainsi le pourcentage global d’Avamar Capacity.

Remarque : Bien qu’un équilibre parfait des bandes soit souhaité et souvent observé, des problèmes peuvent survenir et « pas tout à fait », mais presque, l’équilibrage est observé. L’équipe d’ingénieurs Avamar a confirmé qu’une différence et une tolérance de 4 % entre les soldes de répartition se situent dans les limites attendues.
 
 

Un autre type d’équilibrage à comprendre est l’équilibrage du disque du système d’exploitation. Cela se limite uniquement aux partitions de données sur le même nœud, et non aux 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 se fasse généralement sur le système d’exploitation et non sur le GSAN Capacity, elle peut être signalée en tant que GSAN Problème de capacité.

 

Étape 6. Vérifiez si le nettoyage de la mémoire est en cours : 

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

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

Idéalement, la sortie indiquera que le GC a terminé 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 GC 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 GC a rencontré un problème, abordez-le d’abord à l’aide de l’article suivant comme référence : Avamar : Dépannage des échecs de nettoyage de la mémoire (GC) (chemin de résolution)
(Si des problèmes ont déjà été résolus, passez à l’étape suivante.)

 

Étape 7. Le GC est-il assez long ?

Avertissement : Ne le confondez pas avec le « MSG_ERR_TIMEOUT » des résultats du GC. Il s’agit d’une toute autre erreur qui peut être abordée dans l’article Chemin de résolution des erreurs du GC. Ici, le délai d’attente signifié comme dans GC a atteint son temps d’exécution maximal, mais se termine tranquillement et proprement sans aucune erreur. Les informations de cette étape permettent de confirmer si cela se produit.
 
 

un. Exécutez la commande suivante pour vérifier la durée maximale autorisée pour GC :

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"/>
 

Prenez note de l’icône maxtime , qui dans cet exemple est 14 400 (secondes).
(La valeur 0 signifie illimité)

b. Exécutez la commande suivante pour déterminer la durée d’exécution du GC et le nombre de « passes » effectuées :
(Les passes sont liées aux couches des données de sauvegarde stockées. Pensez à la GSAN Capacité comme les couches d’un oignon. Les couches extérieures doivent être décollées ou enlevées avant que les couches internes ne soient visibles. Chaque passe est une couche de la GSAN données stockées.)

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"/>

 

Prenez note du nombre de passes et du elapsed-time (secondes).

 

c. À supposer que le maxtime n’est pas nul, calculez 2/3 de maxtime, et comparez-le au temps écoulé.
(Dans l’exemple ci-dessus, les 2/3 de 14 400 sont égales à 9 600, et toutes les sorties de temps écoulé sont bien inférieures à ce chiffre.)

  • Si la demande elapsed-time est inférieur à 2/3 de maxtime, il est probable que GC ait terminé tôt parce qu’il n’y avait plus rien à ramasser et qu’il est rattrapé.

  • Si le nombre de passes est élevé (14 ou plus), il est probable que le GC supprime des quantités suffisantes de données.
    Remarque : Comprenez que si aucune donnée n’a expiré et qu’il n’y a rien à nettoyer, la valeur des passes devrait être faible. Il est donc préférable de comprendre l’ensemble de la situation et de l’environnement. Ne présumez pas que quelques passages signifient qu’il y a un problème.
 

Divers problèmes peuvent ralentir l’exécution du GC ou empêcher l’analyse de tout. Il peut s’agir d’un manque de temps ou de jours d’exécution dans le passé, d’une configuration incorrecte, d’erreurs, etc.

S’il y a des inquiétudes au sujet de la maxtime, ou le nombre de passages, créez une demande de service auprès de l’équipe de support Dell Technologies Avamar pour en savoir plus.

 

Étape 8. S’il soupçonne que le GC n’a pas supprimé suffisamment de données ou les données attendues :

S’il est confirmé que le GC fonctionne suffisamment longtemps, il est possible que les données ne soient pas collectées pour des raisons indépendantes de la volonté du nettoyage de la mémoire. Voici une liste des raisons documentées qui doivent généralement être vérifiées :

un. Vérifiez que les sauvegardes sont configurées pour expirer au moins à terme ou régulièrement. S’il n’y a pas de sauvegardes fréquentes arrivant à expiration, GC n’aura pas beaucoup de travail à faire.

b. Utilisez cet article pour trouver les clients ayant le taux de modification le plus élevé : Avamar : Comment gérer la capacité avec le script capacity.sh. (Passez en revue les deux «% OF TOTAL» et «CHGRATE".)

c. Recherchez les hachages ignorés par Avamar : Le nettoyage de la mémoire Avamar signale des « hachages ignorés » qui ne peuvent pas être nettoyés. Si ceux-ci se produisent mais rarement, c’est normal et cela peut être ignoré.

d. Une balise ou une option force Avamar Server à conserver la dernière sauvegarde de chaque client, la plus récente. Elle est utilisée à des fins de sécurité afin que chaque sauvegarde d’un client n’expire pas accidentellement. Cependant, cela peut causer d’autres problèmes en ce qui concerne le nettoyage des données et le nettoyage de la mémoire. L’équipe de support Avamar de Dell Technologies peut confirmer si cette option est activée.

e. Si les sauvegardes ont récemment été basculées depuis GSAN vers le back-end DD ou une erreur GSAN sauvegarde, mais le GSAN La capacité ne diminue pas. Créez une demande de service auprès de l’équipe de support Dell Technologies Avamar pour en savoir plus.

 

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

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

Cela signifie que les données peuvent nécessiter d’être supprimées ou que des options peuvent être 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. Acquittez tous les événements de capacité et reprenez l’ordonnanceur de sauvegarde si nécessaire :

un. Une fois les problèmes de capacité résolus, accusez réception de tous les événements liés à la capacité dans Avamar Admin UI.

b. Reprenez l’ordonnanceur de sauvegarde :

dpnctl start sched
 

Pour toute autre question, formation, dépannage et autres sur la capacité Avamar, consultez : Avamar : Dépannage, problèmes et questions relatifs à la capacité - Toute la capacité (chemin de résolution)

Additional Information

Un nettoyage de la mémoire manuel ou « agressif » n’est pas recommandé.
(Il s’agit d’une référence à l’exécution de GC en dehors des heures automatiques planifiées.)
  • Cette action en elle-même peut « masquer » et cacher les vrais problèmes, ne les faisant réapparaître que quelques jours ou semaines plus tard, ce qui fait perdre du temps à ce travail manuel.
  • De plus, il se peut que le GC manuel ne s’exécute pas aussi efficacement qu’il n’est planifié.
 
Les étapes de résolution ci-dessus ne mentionnent ni ne recommandent la modification des paramètres de capacité et de disque maximum spécifiques au GSAN Pas du tout de capacité.
  • Cette modification ou action n’est généralement pas effectuée et ne doit pas être prise en compte par défaut. Un ingénieur Avamar L2 ou un expert Subject Matter Expert (SME) doit approuver ce changement.
  • Malheureusement, de telles actions peuvent souvent causer des dommages permanents à une grille Avamar, qui ne peuvent être résolus qu’avec l’ajout de nœuds de stockage supplémentaires ou le redéploiement.
 

Comprenez qu’aucune des actions répertoriées ci-dessus n’est effectuée, car l’équipe de support souhaite vous aider à résoudre les problèmes de capacité de la manière la plus avantageuse 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.