Avamar GSAN- eller User Capacity Resolution Path

Summary: Denne artikel om løsningssti omhandler håndtering og fejlfinding af problemer med GSAN-kapacitet (også kaldet brugerkapacitet) på 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

Du kan finde indledende begreber og forståelse af operativsystemets (OS) kapacitet under Avamar: Kapacitet generel undervisning – løsningssti

Det er ofte nemmest at overveje GSAN Kapacitet som plads og udnyttelse til klientsikkerhedskopier.

Som opsummeret fra denne undervisningsartikel, bør en rimelig forståelse af følgende emner være påkrævet for at fortsætte gennem resten af denne artikel:
  • Grundlæggende forståelse af deduplikering
  • Grundlæggende forståelse af kontrolpunkt, validering af kontrolpunkt (hfscheck) og Garbage Collection, og vigtigheden af hver.
  • Forskellen mellem GSAN (eller bruger) Kapacitet og OS-kapacitet
  • Skift hastighed
  • Stabil tilstand
 
Virkninger af høj GSAN Kapaciteten kan omfatte:
  • Sikkerhedskopierings- eller replikeringsfejl, når netadgangstilstanden er ændret til "admin-tilstand"
    • Et sikkerhedskopieringsjob for klienten kan mislykkes med en meddelelse, der ligner:  "avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
  • Den automatiske deaktivering af backupplanlæggeren (indtil den anerkendes og ryddes af nogen)
 
Når følgende tærskler overskrides, genereres der en hændelsesadvarsel eller fejl i brugergrænsefladen i Avamar-administrationen:
  • 80 % – Kapacitetsadvarsel
  • 95 % - Sundhedstjekgrænsen er nået (dette kan nogle gange deaktivere backupplanlæggeren, i det mindste indtil den bekræftes manuelt)
  • 100 % – Servergrænsen er nået (gitteret skifter til administratortilstand)

Cause

I en hurtig oversigt: Avamar server og GSAN Kapacitet "deduplikerer" backupdata, hvilket betyder, at når visse bytes eller klumper af data ligner hinanden, er det kun nødvendigt at gemme den pågældende del én gang. Alle data kan "deduplikeres" i forhold til alle andre data fra de samme eller forskellige klienter, der sikkerhedskopieres på Avamar-nettet. Da disse klumper af data er små, kan den finde mange dubletter og spare en masse kapacitet uden at skulle sikkerhedskopiere dem gentagne gange.
Kapacitetens livscyklus for klientsikkerhedskopieringsdata:
  1. Avamar behøver kun at gemme og gemme de mindre ændringer og forskelle mellem hvert klientsikkerhedskopieringsjob på grund af deduplikering. Når nye sikkerhedskopier (eller indgående replikering) køres, kan det tilføje nye data og øge Avamar-kapaciteten eller udnyttelsesværdien. 
  2. Efter et vist tidsrum udløber sikkerhedskopier baseret på deres konfigurerede opbevaring og udløb, og der findes ikke nogen i Avamar-nettet, der kan gendannes. 
  3. Når Avamar-vedligeholdelsesjobbet kaldet Garbage Collection (GC) kører, finder det alle de unikke dele eller klumper af data, der ikke længere er brug for på grund af disse udløbne sikkerhedskopier. GC kontrollerer, at ingen andre aktuelle sikkerhedskopier deler de samme data (på grund af deduplikering), og fjerner eller frigør derefter de klumper af data, der ikke længere er nødvendige for at reducere Avamar-serverkapaciteten eller -udnyttelsen.
 

Når mængden af daglige indgående data, der tilføjes, er omtrent den samme som mængden af daglige data, der ryddes, kaldes dette "Steady State". Dette er målet for alle installerede Avamar-net.

Før et nyt Avamar-net konfigureres og konfigureres, foretages der generelle størrelsesberegninger forud for installationen for at bestemme den kapacitet, der kræves for at gemme sikkerhedskopidataene. Disse beregninger er baseret på kundernes fastholdelseskrav, og hvor meget data der skal sikkerhedskopieres. Det estimerer også, hvor meget af disse data der kan deduplikeres i gennemsnit og så videre.

Men nogle gange når kapaciteten ikke en stabil tilstand. Dette kan skyldes:
  1. Garbage Collection kører ikke konsekvent
  2. Garbage Collection ydeevne er langsom eller kører ikke længe nok
  3. Deduplikeringsestimater forud for Avamar-netinstallationen var ikke nøjagtige nok
  4. Andre data end dem, der blev beregnet før Avamar-netinstallationen, sikkerhedskopieres til denne Avamar-server.
  5. Andre grunde

Resolution

Kontrollér, at hvert fejlfindingstrin nedenfor gælder for miljøet:

Bemærk: Trinnene er sorteret i den mest hensigtsmæssige rækkefølge for at isolere problemet og identificere den korrekte løsning.
Spring ikke nogen trin over.
 
 

Trin 1. Dataindsamling:

Sørg for, at der ikke er andre problemer med manglende kapacitet i Avamar-nettet. Hvis der er, kan de kræve opmærksomhed FØR fejlfinding kapacitet.

Dette omfatter hardwarefejl, dataintegritetsproblemer (herunder offlinenoder), offline-stripes, kontrolpunktsvalideringsfejl eller mislykkede vedligeholdelsesjob. Hvis noget af dette er et problem, skal fejlfinding af kapaciteten stoppes, og andre problemer skal løses. Når andre problemer er løst, kan kapaciteten besøges igen.

Der skal køres et helbredstjek (Avamar: Sådan køres proactive_check.pl-tilstandskontrolscriptet på en Avamar-server, men som minimum status.dpn kommando kan give et hurtigt overblik og verifikation af de fleste af de samme problemer. Se Avamar: Sådan forstås det output, der genereres af kommandoen status.dpn

Se følgende artikel for at få flere oplysninger: Avamar: Sådan anvender du tilgangen "Avamar-fejlfindingshierarki" korrekt.

Hvis der er behov for hjælp til at løse problemer med manglende kapacitet, skal du oprette en serviceanmodning hos Dell Technologies Avamar-supportteamet.

 

Trin 2. Indsamling af kapacitetsoplysninger: 

Se nedenstående for at få alle de nødvendige oplysninger til fejlfinding af Avamar-kapacitetsproblemer: Avamar: Sådan indsamler du oplysningerne til fejlfinding af kapacitetsproblemer

I det mindste er status.dpn , eller værdierne i Avamar-administrationens brugergrænseflade viser GSAN kapacitet.

Bemærk: Den kapacitet, der vises af status.dpn kommando og brugergrænsefladen adskiller sig efter tilsigtet design.
 
 

Trin 3. Kontrollér, om OS-kapaciteten er fuld:

Følgende kommando hjælper med at vise den aktuelle værdi af OS-kapaciteten for hver diskpartition. Hvis nogen af værdierne har nået eller overskredet 85%, som i det andet prøveoutput, betragtes det som høj OS-kapacitet:

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

Eksempler på output:

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"
 
Advarsel: Selvom høj OS-kapacitet måske ikke ser ud til at være den største bekymring, forhindrer dette fejlfinding GSAN Kapacitet, fordi Garbage Collection ikke kan køre, hvis kapaciteten overstiger 89 %. Dette diskuteres mere detaljeret, og fejlfindingstrin findes i: Avamar: Operativsystemkapacitet (OS) (løsningssti)
 

Kun hvis operativsystemets kapacitet er under 85 %, bør GSAN Kapacitetsfejlfinding fortsætter. 

 

Trin 4. Problemer med manglende kapacitet, der nogle gange kan misforstås som kapacitet:

Det er muligt, at sikkerhedskopieringer af klienter mislykkes, ikke af hensyn til "kapacitet", men i stedet er "kvote"-årsager. Disse kan undertiden misforstås som kapacitet.

Denne situation kan bekræftes af status.dpn kommando eller noget af det andet indsamlede output, der viser lavere kapacitet.

Det er også muligt, at klientsikkerhedskopieringer kan have mislykkedes eller ikke køre på grund af andre Non-GSAN Kapacitetsmæssige årsager. De indsamlede oplysninger bør bekræfte dette, eller de kan også ses i brugergrænsefladen for Avamar-administrationen.

Hvis ikonet GSAN Kapaciteten er ikke høj, se følgende artikler:
 

Hvis ikonet GSAN Kapaciteten er høj, og disse andre kapaciteter er også høje, fejlfinding kan udføres i vilkårlig rækkefølge (undtagen OS-kapacitet, som altid skal være først).

Bemærk: Det er muligt, at GSAN Kapaciteten, metadatakapaciteten og DD-kapaciteten kan være høje. I disse situationer kan de løses i vilkårlig rækkefølge i modsætning til OS-kapacitet, som altid skal adresseres først.
 
 
 

Trin 5. Stripebalance og OS-disksaldo:

"Stripes" på Avamar er de beholderfiler, som sikkerhedskopieringsdata gemmes i på datanoderne (undtagen et Avamar-net med en enkelt node).

Forventningen er, at striber er "afbalancerede" eller jævnt fordelt på tværs af de forskellige diske og noder i nettet, men nogle gange kan de blive ubalancerede.

Efter design på Avamar er den største node eller diskpartition den begrænsende faktor, når det kommer til Avamar-kapacitet.

Dette er tilsigtet, så ingen af diskene eller noderne opretter flere striber, end de kan håndtere (eller tillader), og derfor er det vigtigt for kapaciteten at have afbalancerede striber.

Når du f.eks. tilføjer yderligere datanoder til Avamar-netudvidelse, skal justeringen køres for at fordele striberne jævnt til de nye noder for at reducere den samlede Avamar-kapacitetsprocent.

Bemærk: Mens en perfekt stribebalance ønskes og ofte ses, kan der opstå problemer og "ikke helt", men tæt ses balance. Avamar Engineering-teamet har bekræftet, at en forskel på 4 % og tolerance mellem stripe-saldi er inden for de forventede grænser.
 
 

En anden type balance, der kræver forståelse, er OS-diskbalance. Dette er kun begrænset til datapartitioner på den samme node, ikke partitioner på flere noder. 

Hvis en partition på den samme dataknude er meget større eller mindre end en anden partition af den samme node, kan en grænse overskrides kaldet "freespaceunbalance". Selvom dette generelt er på operativsystemet og ikke på GSAN Kapacitet, kan det rapporteres som en GSAN Kapacitetsproblem.

 

Trin 6. Kontroller, om affaldsindsamlingen er færdig: 

Kør følgende kommando for at få oplysninger om affaldsindsamling:

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

Ideelt set vil outputtet vise, at GC har gennemført i de sidste 30 dage:

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
 

GC-fejlmeddelelser kan omfatte, men er ikke begrænset til, følgende:

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
 

Hvis GC har svigtet, skal du først adressere dette ved hjælp af følgende artikel som reference: Avamar: Fejlfinding af fejl i affaldsindsamling (GC) (løsningssti)
Hvis eventuelle problemer allerede er løst, skal du gå videre til næste trin.

 

Trin 7. Kører GC længe nok?

Advarsel: Forveksl ikke dette med "MSG_ERR_TIMEOUT" fra GC-resultater. Denne fejl er noget helt andet og kan løses i artiklen GC Error Resolution Path. Her betød timing som i GC sin maksimale driftstid, men slutter stille og rent uden fejl. Oplysningerne i dette trin hjælper med at bekræfte, om dette sker.
 
 

en. Kør følgende kommando for at kontrollere den maksimale tilladte tid for GC:

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

Eksempel på output:

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

Vær opmærksom på maxtime værdi, som i dette eksempel er 14400 (sekunder).
(En værdi på 0 betyder ubegrænset)

b. Kør følgende kommando for at finde ud af, hvor længe GC kører, og hvor mange "gennemløb" der er gennemført:
(Passene har at gøre med lagene i de lagrede sikkerhedskopieringsdata. Tænk på GSAN Kapacitet som lag af et løg. De ydre lag skal skrælles tilbage eller fjernes, før de indre lag ses. Hvert pas er et lag af GSAN lagrede data.)

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

Eksempel på output:

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

 

Vær opmærksom på antallet af adgangskort og elapsed-time (sekunder).

 

c. Hvis det antages, at maxtime er ikke-nul, beregn 2/3 af maxtime, og sammenlign det med den forløbne tid.
(I eksemplet ovenfor er 2/3 af 14400 9600, og alle forløbne tidsoutput er langt under dette tal.)

  • Hvis ikonet elapsed-time er mindre end 2/3 af maxtime, er det sandsynligt, at GC sluttede tidligt, fordi der ikke var noget tilbage at samle og er indhentet.

  • Hvis antallet af gennemløb er højt (14 eller flere), er det sandsynligt, at GC fjerner tilstrækkelige mængder data.
    Bemærk: Forstå, at hvis ingen data er udløbet, og der ikke er noget at rengøre, forventes værdien af passene at være lav, så det er bedst at forstå hele situationen og miljøet også. Antag ikke, at få passerer betyder, at der er et problem.
 

Forskellige problemer kan få GC til at køre langsomt eller ikke scanne alt. Dette kan omfatte ikke at have haft nok tid til at køre i en betydelig mængde tid eller dage tidligere, forkert konfiguration, fejl og mere.

Hvis der er betænkeligheder ved maxtimeeller antal adgangskort, oprette en serviceanmodning hos Dell Technologies Avamar-supportteamet for at undersøge sagen nærmere.

 

Trin 8. Hvis den havde mistanke om, at GC ikke fjernede nok eller de forventede data:

Hvis det bekræftes, at GC kører længe nok, er det muligt, at data ikke indsamles af årsager uden for Garbage Collection-kontrol. Dette er en liste over de dokumenterede årsager, der generelt bør kontrolleres:

en. Kontroller, at sikkerhedskopier er konfigureret til som minimum at udløbe til sidst eller regelmæssigt. Hvis der ikke er hyppige sikkerhedskopier, der udløber, har GC ikke meget arbejde at gøre.

b. Brug denne artikel til at finde "Top Change Rate"-klienter: Avamar: Sådan administrerer du kapacitet med scriptet capacity.sh. (Gennemgå både "% OF TOTAL" og "CHGRATE".)

c. Tjek for sprunget hashes pr. Avamar: Avamar Garbage Collection rapporterer "sprunget hashes", der ikke kan ryddes op. Hvis disse forekommer, men sjældne, er dette normalt, og dette kan springes over.

d. Der er et flag eller en indstilling, der tvinger Avamar-serveren til at beholde den sidste og seneste sikkerhedskopi fra hver klient. Dette bruges af sikkerhedsmæssige årsager, så en klient ikke har hver sikkerhedskopi ved et uheld udløbet. Dette kan dog forårsage andre problemer, når det kommer til dataoprydning og affaldsindsamling. Dell Technologies Avamar-supportteamet kan bekræfte, om dette er aktiveret.

e. Hvis sikkerhedskopier for nylig er blevet skiftet fra GSAN til DD-backend, eller der var et uheld GSAN backup, men GSAN Kapaciteten falder ikke. Opret en serviceanmodning hos Dell Technologies Avamar-supportteamet for at undersøge sagen nærmere.

 

Trin 9. Avamar-gitteret er for lille i forhold til mængden af aktuelle eller forventede data, der skal tilføjes:

Når alle andre løsninger og mulige årsager er blevet gennemgået for høj kapacitet, og dette ikke er et konfigurationsproblem eller problem med utilsigtede data:

Det betyder, at data muligvis skal slettes, eller at muligheder undersøges, f.eks. migrering af visse klienter til andre Avamar-gitre, tilføjelse af nye datanoder osv.

 

Trin 10. Anerkend eventuelle kapacitetshændelser, og genoptag backupplanlæggeren, hvis det er nødvendigt:

en. Når kapacitetsproblemer er løst, skal du anerkende alle kapacitetsrelaterede hændelser i Avamar Admin UI.

b. Genoptag sikkerhedskopieringsprogrammet:

dpnctl start sched
 

Hvis du har andre spørgsmål om Avamar-kapacitet, træning, fejlfinding og meget mere, kan du se: Avamar: Kapacitetsfejlfinding, problemer og spørgsmål – Al kapacitet (løsningssti)

Additional Information

Manuel eller "aggressiv" affaldsindsamling anbefales ikke.
(Dette er en reference til at køre GC uden for de planlagte automatiske tidspunkter.)
  • Denne handling i sig selv kan "maskere" og skjule de virkelige problemer, hvilket kun får dem til at dukke op igen om et par dage eller uger senere, hvilket får dette manuelle job til at spilde tid.
  • Desuden kører den manuelle GC muligvis ikke så effektivt, da den er ved at løbe tør for tidsplan.
 
Ovenstående løsningstrin nævner eller anbefaler ikke at ændre de maksimale disk- og kapacitetsindstillinger, der er specifikke for GSAN Kapacitet overhovedet.
  • Denne ændring eller handling udføres generelt ikke og bør ikke betragtes som standard. En Avamar L2-tekniker eller Subject Matter Expert (SME) skal godkende denne ændring.
  • Desværre kan sådanne handlinger ofte forårsage permanent skade på et Avamar-net på forskellige måder, der kun kan løses ved at tilføje yderligere lagernoder eller geninstallere.
 

Forstå, at ingen af de handlinger, der er anført ovenfor, udføres, fordi supportteamet ønsker at hjælpe med at løse kapacitetsproblemerne på den mest fordelagtige måde.

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.