Avamar GSAN eller matchningssökväg för användarkapacitet

Information om operativsystemskapacitet finns i Avamar: Kapacitet Allmän utbildning – Lösning Sökväg

Det är ofta enklast att tänka på GSAN Kapacitet som utrymme och användning för klientsäkerhetskopiering.

• Grundläggande förståelse för deduplicering
• Grundläggande förståelse för kontrollpunkt, validering av kontrollpunkt (hfscheck) och skräpinsamling, och vikten av var och en.
• Skillnaden mellan GSAN (eller användare) Kapacitet och OS-kapacitet
• Ändra hastighet
• Stabil status

• Säkerhetskopierings- eller replikeringsfel när rutnätsåtkomsttillståndet har ändrats till administratörsläge

  • Ett klientsäkerhetskopieringsjobb kan misslyckas med ett meddelande som liknar:  ”avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
• Den automatiska inaktiveringen av schemaläggaren för säkerhetskopiering (tills den bekräftas och rensas av någon)

• 80 % – kapacitetsvarning
• 95 % – Hälsokontrollgränsen har nåtts (detta kan ibland inaktivera schemaläggaren för säkerhetskopiering, åtminstone tills den bekräftas manuellt)
• 100 % – Serverns skrivskyddade gräns har nåtts (rutnätet går in i administratörsläge)

1. Avamar behöver bara spara och lagra mindre ändringar och skillnader mellan varje klientsäkerhetskopieringsjobb på grund av deduplicering. När nya säkerhetskopior (eller inkommande replikering) körs kan den lägga till nya data och öka Avamar-kapaciteten eller användningsvärdet. 
2. Efter en viss tid upphör säkerhetskopiorna att gälla baserat på deras konfigurerade kvarhållning och förfallodatum och finns inte i Avamar-rutnätet som är tillgängligt för återställning. 
3. När Avamar-underhållsjobbet som kallas skräpinsamling (GC) körs hittar det alla unika delar eller segment av data som inte längre behövs på grund av dessa utgångna säkerhetskopior. GC verifierar att inga andra aktuella säkerhetskopior delar samma data (på grund av deduplicering) och tar sedan bort eller frigör de datasegment som inte längre behövs för att minska Avamar-serverns kapacitet eller användning.

När mängden inkommande data som läggs till varje dag är ungefär densamma som mängden data som rensas per dag kallas detta för "Steady State". Det här är målet för alla Avamar-rutnät som installeras.

Innan ett nytt Avamar-rutnät konfigureras görs allmänna storleksberäkningar före installationen för att fastställa vilken kapacitet som krävs för att lagra säkerhetskopierade data. Dessa beräkningar baseras på kundens kvarhållningskrav och hur mycket data som ska säkerhetskopieras. Den uppskattar också hur mycket av dessa data som i genomsnitt kan dedupliceras och så vidare.

1. Skräpinsamlingen körs inte konsekvent
2. Skräpinsamlingsprestandan är långsam eller körs inte tillräckligt länge
3. Uppskattningar av deduplicering före installation av Avamar-rutnät var inte tillräckligt exakta
4. Andra data än de som beräknades före installationen av Avamar-rutnätet säkerhetskopieras till den här Avamar-servern.
5. Andra orsaker

Kontrollera att varje felsökningssteg nedan är sant för miljön:

Steg 1. Datainsamling:

Se till att det inte finns några andra icke-kapacitetsrelaterade problem med Avamar-nätet. Om så är fallet kan de behöva åtgärdas INNAN felsökningskapacitet används.

Detta omfattar maskinvarufel, dataintegritetsproblem (inklusive offlinenoder), offlinestripes, misslyckade kontrollpunktsvalideringar eller misslyckade underhållsjobb. Om något av dessa är ett problem måste felsökning av kapacitet stoppas och andra problem åtgärdas. När andra problem har lösts kan kapaciteten ses över.

En hälsokontroll bör köras (Avamar: Så här kör du det proactive_check.pl hälsokontrollskriptet på en Avamar Server, men minst status.dpn kan ge en snabb överblick och verifiering av de flesta av dessa problem. Se Avamar: Så här förstår du utdata som genereras av kommandot status.dpn

Mer information finns i följande artikel: Avamar: Så här tillämpar du metoden "Avamar-felsökningshierarki" på rätt sätt.

Om du behöver hjälp med att åtgärda problem som inte är kopplade till funktionen skapar du en tjänstebegäran hos Dell Technologies Avamar-supportteam.

Steg 2. Insamling av kapacitetsinformation: 

Se följande för all nödvändig information som krävs för att felsöka problem med Avamar-kapacitet: Avamar: Så här samlar du in information för att felsöka kapacitetsproblem

Åtminstone har status.dpn kommandot eller värdena i Avamar-administrationsgränssnittet visar GSAN kapacitet.

Steg 3. Kontrollera om operativsystemets kapacitet är full:

Följande kommando hjälper dig att visa det aktuella värdet för OS-kapaciteten för varje diskpartition. Om något av värdena har nått eller överskridit 85 %, som i det andra provets utdata, anses det vara hög OS-kapacitet:

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

Exempel på resultat:

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"

Endast om OS-kapaciteten är lägre än 85 % bör GSAN Felsökning av kapacitet fortsätter. 

Steg 4. Icke-kapacitetsproblem som ibland kan missförstås som kapacitet:

Det är möjligt att klientsäkerhetskopieringar misslyckas inte av kapacitetsskäl utan i stället av kvotskäl. Dessa kan ibland missförstås som kapacitet.

Denna situation kan bekräftas av status.dpn kommandot eller några av de andra insamlade utdata som visar lägre kapacitet.

Det är också möjligt att klientsäkerhetskopieringar kan ha misslyckats eller inte köras på grund av andra Non-GSAN Kapacitetsskäl. Den insamlade informationen bör bekräfta detta eller kan också ses i Avamar-administrationsgränssnittet.

• Avamar: Sökväg för metadatakapacitetsmatchning
• Data Domain: Hög kapacitet från Avamar-integrering Upplösningssökväg

Om den GSAN Kapaciteten är hög, och dessa andra kapaciteter är också höga. Felsökning kan utföras i valfri ordning (förutom OS-kapacitet som alltid måste vara först).

Steg 5. Stripe-saldo och OS-disksaldo:

"Stripes" i Avamar är behållarfilerna som säkerhetskopierade data lagras i på datanoderna (förutom ett Avamar-rutnät med en nod).

Förväntningen är att stripes är "balanserade" eller jämnt fördelade över de olika diskarna och noderna i rutnätet, men ibland kan de bli obalanserade.

Avamar innebär att den största noden eller diskpartitionen är den begränsande faktorn när det gäller Avamar-kapacitet.

Detta är avsiktligt, så ingen av diskarna eller noderna skapar fler stripes än de kan hantera (eller tillåts), därför är det viktigt för kapaciteten att ha balanserade stripes.

När du till exempel lägger till ytterligare datanoder för Avamar-rutnätsexpansion måste balansering köras för att jämnt fördela ränderna till de nya noderna för att minska den totala Avamar-kapacitetsprocenten.

En annan typ av balans som kräver förståelse är OS-diskbalans. Detta är endast begränsat till datapartitioner på samma nod, inte partitioner på flera noder. 

Om en partition på samma datanod är mycket större eller mindre än en annan partition av samma nod kan en gräns överskridas som kallas "freespaceunbalance”. Även om detta vanligtvis är på operativsystemet och inte GSAN Kapacitet kan den rapporteras som en GSAN Kapacitetsproblem.

Steg 6. Kontrollera om skräpinsamlingen slutförs: 

Kör följande kommando för att hämta information om skräpinsamling:

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

Vi rekommenderar att utdata visar att GC har slutförts under de senaste 30 dagarna:

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-felmeddelanden kan innehålla, men inte begränsat till, följande:

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

Om GC har misslyckats åtgärdar du detta först med hjälp av följande artikel som referens: Avamar: Felsöka fel vid skräpinsamling (GC) (lösningssökväg)
(Gå till nästa steg om några problem redan har lösts.)

Steg 7. Är GC tillräckligt lång?

a. Kör följande kommando för att kontrollera den maximala tid som tillåts för GC:

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

Exempel på utdata:

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

Notera maxtime value, som i det här exemplet är 14400 (sekunder).
(Värdet 0 innebär obegränsat)

b. Kör följande kommando för att avgöra hur länge GC körs och hur många "pass" som slutförs:
(Strängar har att göra med lagren i lagrade säkerhetskopierade data. Tänk på GSAN Kapacitet som lager av en lök. De yttre lagren måste skalas av eller tas bort innan de inre lagren syns. Varje pass är ett lager av GSAN lagrade data.)

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

Exempel på utdata:

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

Notera antalet passeringar och elapsed-time (sekunder).

c. Om man antar att maxtime är skild från noll, beräkna 2/3 av maxtimeoch jämför den med den förflutna tiden.
(I exemplet ovan är 2/3 av 14400 9600, och alla utgångar för förfluten tid ligger långt under denna siffra.)

Olika problem kan göra att GC körs långsamt eller inte genomsöker allt. Detta kan innefatta att inte ha haft tillräckligt med tid att köra under en betydande tid eller dagar tidigare, felaktig konfiguration, fel med mera.

Om det finns farhågor om maxtimeeller antal passer, skapar du en tjänstebegäran hos Dell Technologies Avamar-supportteam för att undersöka saken närmare.

Steg 8. Om det misstänks att GC inte tog bort tillräckligt med eller förväntade data:

Om det bekräftas att GC körs tillräckligt länge är det möjligt att data inte samlas in av orsaker utanför skräpinsamlingskontrollen. Det här är en lista över de dokumenterade orsaker som i allmänhet bör kontrolleras:

a. Kontrollera att säkerhetskopieringar är konfigurerade så att de åtminstone upphör att gälla så småningom eller regelbundet. Om det inte finns frekventa säkerhetskopior som upphör att gälla har GC inte mycket arbete att göra.

b. Använd den här artikeln för att hitta klienterna för "Bästa ändringshastighet": Avamar: Hantera kapacitet med capacity.sh-skriptet. (Granska både "% OF TOTAL" och "CHGRATE".)

c. Kontrollera om det finns överhoppade hashvärden per Avamar: Avamar-skräpinsamling rapporterar "överhoppade hashvärden" som inte kan rensas. Om dessa förekommer men är sällsynta är detta normalt och detta kan hoppas över.

d. Det finns en flagga eller ett alternativ som tvingar Avamar-servern att behålla den senaste och senaste säkerhetskopian från varje klient. Detta används av säkerhetsskäl så att en klient inte får alla säkerhetskopior av misstag att upphöra att gälla. Detta kan dock orsaka andra problem när det gäller datarensning och skräpinsamling. Dell Technologies Avamar-supportteam kan bekräfta om detta är aktiverat.

e. Om du nyligen har bytt från säkerhetskopior GSAN till DD-backend eller så inträffade en oavsiktlig GSAN backup, men GSAN Kapaciteten minskar inte. Skapa en tjänstebegäran hos Dell Technologies Avamar-supportteam för att undersöka saken närmare.

Steg 9. Avamar-rutnätet är underdimensionerat för den mängd aktuella eller förväntade data som ska läggas till:

När alla andra lösningar och möjliga orsaker har granskats för hög kapacitet, och detta inte är ett konfigurationsproblem eller problem med oavsiktliga data:

Det innebär att data kan behöva tas bort eller alternativ utforskas, såsom att migrera vissa klienter till andra Avamar-rutnät, lägga till nya datanoder och så vidare.

Steg 10. Bekräfta eventuella kapacitetshändelser och återuppta schemaläggaren för säkerhetskopiering om så krävs:

a. När kapacitetsproblem har åtgärdats bekräftar du alla kapacitetsrelaterade händelser i Avamar-administratörsgränssnittet.

b. Återuppta schemaläggaren för säkerhetskopiering:

dpnctl start sched

Övriga frågor om Avamar-kapacitet, utbildning, felsökning och annat finns i: Avamar: Felsökning, problem och frågor om kapacitet – all kapacitet (lösningssökväg)

• Den här åtgärden i sig kan "maskera" och dölja de verkliga problemen, vilket bara gör att de dyker upp igen om några dagar eller veckor senare, vilket gör att det här manuella jobbet är bortkastad tid.
• Dessutom kanske den manuella GC inte körs lika effektivt eftersom den körs utanför schemat.
  • Ibland kan det göra andra problem värre. Mer information finns i: Avamar: Om användningen av manuell skräpinsamling

• Den här ändringen eller åtgärden utförs vanligtvis inte och bör inte övervägas som standard. En Avamar L2-tekniker eller ämnesexpert (SME) måste godkänna ändringen.
• Tyvärr kan sådana åtgärder ofta orsaka permanenta skador på ett Avamar-rutnät på olika sätt som bara kan lösas genom att lägga till ytterligare lagringsnoder eller distribuera om.

Du är medveten om att ingen av de åtgärder som anges ovan utförs eftersom supportteamet vill hjälpa till att lösa kapacitetsproblemen på det mest fördelaktiga sättet.