Avamar: Felsökning, problem och frågor om kapacitet – all kapacitet (lösningssökväg)

Summary: Den här artikeln om lösningssökväg kan användas som utgångspunkt för alla problem med Avamar-kapacitet.

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.

Symptoms

Kapacitet kan ses som de data eller det diskutrymme som används på en server av klientsäkerhetskopieringar av klientdata.

Kapacitetsproblem kan förhindra normal serverfunktionalitet från att lägga till nya data, eller ibland tillåta att gamla data rensas och tas bort.

 

Tjänstebegäranden kan öppnas för att åtgärda olika kapacitetsproblem, t.ex.:
  • Träning
  • Utbildning
  • Frågor
  • Problem med fel vid skräpinsamling (GC)
  • Kapacitetsproblem i operativsystemet (OS)
  • GSAN Kapacitetsproblem
  • Problem med metadatakapacitet
  • Problem med Data Domain-integreringskapacitet (DD)

Cause

Det finns flera faktorer att ta hänsyn till när man hanterar kapacitetsproblem i ett Avamar-rutnät. Den viktigaste skillnaden när man hanterar kapacitetsproblem är att avgöra vilken typ av kapacitetsproblem detta kan vara relaterat. 

Den här lösningen hjälper till att fastställa vilken typ av problem som har upplevts och sätt att åtgärda det.

Resolution

Kontrollera att varje felsökningssteg nedan gäller för din miljö. Varje steg innehåller instruktioner eller en länk till ett dokument för att eliminera möjliga orsaker och vidta korrigerande åtgärder vid behov. Stegen ordnas i den lämpligaste ordningen för att isolera problemet och identifiera rätt lösning. Hoppa inte över ett steg. Om det finns flera problem som uppstår på olika sätt med kapacitet måste de också åtgärdas i en viss ordning.

Även om Avamar nämns i de flesta av stegen kan integreringar av både Avamar – NetWorker och Avamar – Data Domain ändå ge upphov till många av problemen nedan.

 

Steg 1: Insamling av information: Om du vill förstå Avamar-kapacitetsproblem behöver du i allmänhet "måla upp en bild" för att se hela problemet och situationen. Ibland kan en aspekt av kapaciteten påverka en annan, eller så kanske vissa inte inser från början att det finns flera problem. Du måste ha fullständig förståelse för problemet för att felsökning ska kunna inledas.

Se Avamar: Hur du samlar in information som krävs för att felsöka kapacitetsproblem för informationsinsamling.

 

Steg 2: Utbildning: Om en kund vill ha utbildning eller förståelse för hur kapacitet fungerar, vad vissa värden betyder och så vidare kan den här artikeln användas. Det är fortfarande en bra idé att förstå deras problem och "måla upp en bild" eftersom frågor eller utbildning ofta kan vara resultatet av kapacitetsproblem.

Se Avamar Capacity General Training – Resolution Path för utbildningsrelaterade kapacitetsproblem.

 

Steg 3: Hög OS-kapacitet:  Kontrollera värdena för operativsystemskapacitet från de insamlade utdata i steg 1. OS-kapaciteten begränsas av det HÖGSTA användningsvärdet i alla partitioner, även om andra är lägre. Det högsta värdet är den "begränsande faktorn" och måste minskas.

Om det högsta användningsvärdet för en nodpartition överstiger 89 % läser du Avamar OS-kapacitet (lösningssökväg)

Obs! Om skillnaden mellan de högsta och lägsta partitionsvärdena på en datanod är 20 % eller mer gäller även Avamar OS-kapacitet (lösningssökväg).
 
 

Steg 4: Skräpinsamlingsfel eller fel: Om ett Avamar-skräpinsamlingsjobb matar ut felmeddelanden från insamlade utdata måste det åtgärdas härnäst innan återstående typer av kapacitetsproblem.

Information om den här typen av problem finns i Avamar – Felsöka fel vid skräpinsamling (GC) (lösningssökväg)

 

Steg 5: Hög GSAN-kapacitet:  Om det inte finns några problem med OS-kapaciteten och GC inte visar felmeddelanden från insamlade utdata granskar du GSAN Kapacitetsvärden: 

Från status.dpninnebär ett värde på 65 % att rutnätet är fullt (även kallat "admin"-läge eller skrivskyddat) och att det inte finns något utrymme kvar för kapacitetstillväxt.

Obs: det är också möjligt att se "admin"-läge eller skrivskyddat när GSAN kapaciteten är cirka 63 % (på grund av något som kallas disknormaldelta)
 

Information om dessa situationer finns i Avamar GSAN (eller användare) Kapacitet (lösningssökväg)

 

Steg 6: Metadatakapacitet:  När en Data Domain integreras med Avamar introduceras en ny kapacitetsgräns – Metadata Capacity. Metadatakapacitet är kapacitet som finns på Avamar.

Med Data Domain-integreringar kan data dirigeras och skickas till Data Domain för lagring, men Avamar innehåller fortfarande säkerhetskopieringsfilernas metadata på Avamar. Avamar spårar den här kapaciteten för metadata som metadatakapacitet.

När steg 1–5 har granskats och eventuella kapacitetsrelaterade problem åtgärdats kan du granska Upplösning av metadatakapacitet i Avamar Metadata Capacity Resolution Path.

 

Steg 7: Hög Data Domain-kapacitet:  När en Data Domain är integrerad med Avamar kan Data Domain-servern fylla sin kapacitet.

Följande artikel om lösningssökväg: hjälper till att avgöra:

  • Vilka potentiella problem från Avamar kan leda till att Data Domain-kapaciteten växer eller blir full.
  • Vissa Data Domain-specifika problem
  • Om Data Domain är fullt av skäl som inte är relaterade till Avamar.

När steg 1–6 har granskats och eventuella kapacitetsrelaterade problem åtgärdats kan du läsa Data Domain sökväg med hög kapacitet från Avamar-integreringsupplösning

 
 

Övriga frågor: Dessa kan fortfarande ses som problem eller problem som påverkar kapaciteten:

  • Replikeringskälla och målkapacitet matchar inte: När du replikerar data med Avamar eller andra integrerade produkter finns det en förväntan att kapaciteten matchar i rutnäten för replikeringskälla och replikeringsmål.
Detta ingår i kontrollen av GSAN kapacitet på BÅDA rutnäten, men kräver alltid att ytterligare valideringar utförs kring replikeringskonfigurationen och jobbstatus om det finns andra kapacitetsrelaterade problem: Avamar: Ett replikerande par visar olika nivåer av kapacitetsanvändning. Hur man undersöker orsakerna. 
 
  • Management Console Server (MCS) rapporterar följande meddelande:
2012/10/06-21:11:09.75264 {0.4} [manage:3070]  ERROR: <0001> diskinfo::update invalid disk space parameters dev=831 total=1906261MB avail=1675818MB reserved=223410MB maxmb=223978MB newavail=1675818MB reservedoverflow=1 availmboverflow=0 

Det här är ett rapporteringsproblem om stripe-kapacitet i MC-användargränssnittet (UI) som endast är vagt relaterat till de andra kapacitetsavsnitten som diskuteras här. Det finns ingen identifierad effekt av detta förutom att meddelandet visas i användargränssnittet.

Övrig information finns här:
 
  • Rapporter om kapacitetsprognoser:

 


 

Affected Products

Avamar, Avamar Server
Article Properties
Article Number: 000163006
Article Type: Solution
Last Modified: 06 Mar 2025
Version:  11
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.