Lösungspfad für Avamar-GSAN- bzw. -Nutzerkapazität

Grundlegende Konzepte und Erläuterungen zur Kapazität des Betriebssystems (BS) finden Sie unter Avamar: Allgemeine Schulung zur Kapazität – Lösungspfad

Es ist oft am einfachsten, die GSAN -Kapazität als den Speicherplatz und die Auslastung für Client-Backups zu betrachten.

• Grundlegendes Verständnis der Deduplizierung
• Grundlegendes Verständnis von Prüfpunkten, Prüfpunktvalidierung (hfscheck), GC und deren Bedeutung
• Der Unterschied zwischen der GSAN -(bzw. Nutzer-)Kapazität und der Kapazität des Betriebssystems
• Änderungsrate
• Stabiler Status

• Backup- oder Replikationsfehler, wenn der Status für den Rasterzugriff auf „Admin-Modus“ geändert wurde

  • Ein Client-Backupjob kann mit einer Meldung ähnlich der folgenden fehlschlagen:  “avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
• Die automatische Deaktivierung des Backup-Planers (bis das Ereignis bestätigt und gelöscht wird)

• 80 % – Kapazitätswarnung
• 95 % – Das Limit für die Integritätsprüfung ist erreicht (dadurch wird manchmal der Backup-Planer deaktiviert, zumindest bis zur manuellen Bestätigung).
• 100 % – Das Limit für den Server-Schreibschutz ist erreicht (das Raster wechselt in den Admin-Modus).

1. Aufgrund der Deduplizierung muss Avamar nur die geringfügigen Änderungen und Unterschiede zwischen den einzelnen Client-Backupjobs speichern. Wenn neue Backups (oder eingehende Replikationen) ausgeführt werden, kann es neue Daten hinzufügen und so die Kapazität oder Auslastung von Avamar erhöhen. 
2. Nach einer bestimmten Zeit laufen Backups basierend auf der konfigurierten Aufbewahrungs- und Ablauffrist ab und werden im Avamar-Raster nicht mehr für die Wiederherstellung gefunden. 
3. Wenn der Avamar-Wartungsjob namens automatische Speicherbereinigung (Garbage Collection, GC) ausgeführt wird, findet dieser alle eindeutigen Datenteile oder -blöcke, die aufgrund der abgelaufenen Backups nicht mehr benötigt werden. Die GC überprüft, dass keine anderen aktuellen Backups dieselben Daten verwenden (aufgrund der Deduplizierung) und entfernt oder gibt die Datenblöcke frei, die nicht mehr benötigt werden, um die Kapazität oder Auslastung des Avamar Servers zu reduzieren.

Wenn die Menge der täglich eingehenden Daten ungefähr der Menge der täglich bereinigten Daten entspricht, wird dies als „stabiler Status“ bezeichnet. Dies ist für jedes installierte Avamar-Raster das Ziel.

Bevor ein neues Avamar-Raster eingerichtet und konfiguriert wird, werden vor der Installation allgemeine Dimensionierungsberechnungen durchgeführt, um die erforderliche Kapazität zum Speichern der Backupdaten zu ermitteln. Diese Berechnungen basieren auf den Aufbewahrungsanforderungen von KundInnen und auf der Menge der zu sichernden Daten. Außerdem wird geschätzt, wie viele dieser Daten durchschnittlich dedupliziert werden können usw.

1. Die automatische Speicherbereinigung wird nicht konsistent ausgeführt.
2. Die automatische Speicherbereinigung ist langsam oder wird nicht lange genug ausgeführt.
3. Die Deduplizierungsschätzungen vor der Installation des Avamar-Rasters waren nicht genau genug.
4. Auf dem Avamar Server werden weitere Daten, als die vor der Installation des Avamar-Rasters berechneten, gesichert.
5. Andere Gründe

Überprüfen Sie, ob jeder der unten aufgeführten Troubleshooting-Schritte für Ihre Umgebung geeignet ist.

Schritt 1: Datenerfassung:

Stellen Sie sicher, dass keine anderen nicht kapazitätsbezogenen Probleme beim Avamar-Raster vorliegen. Falls ja, müssen diese möglicherweise VOR dem Kapazitäts-Troubleshooting behoben werden.

Dazu gehören Hardwarefehler, Datenintegritätsprobleme (auch bei Offline-Nodes), Offline-Stripes, Fehler bei der Prüfpunktvalidierung oder fehlgeschlagene Wartungsjobs. Wenn eines dieser Problem vorliegt, muss das Kapazitäts-Troubleshooting gestoppt und die anderen Probleme zuerst behoben werden. Sobald die anderen Probleme behoben wurden, kann sich um das Kapazitätsproblem gekümmert werden.

Es sollte eine Integritätsprüfung ausgeführt werden: (Avamar: Anleitung zum Ausführen des proactive_check.pl-Integritätsprüfungsskripts auf einem Avamar Server. Mit dem Befehl status.dpn erhalten Sie jedoch zumindest einen schnellen Überblick, ob eines dieser Probleme vorliegt. Siehe Avamar: Erläuterungen zur Ausgabe des status.dpn-Befehls

Weitere Informationen finden Sie in folgendem Wissensdatenbank-Artikel: Avamar: Ordnungsgemäßes Anwenden der „Avamar Troubleshooting-Hierarchie“

Wenn Sie Unterstützung bei der Behebung nicht kapazitätsbezogener Probleme benötigen, erstellen Sie einen Service-Request beim Dell Technologies Avamar-Supportteam.

Schritt 2. Erfassung der Kapazitätsinformationen: 

Nachfolgend finden Sie alle erforderlichen Informationen für das Troubleshooting von Avamar-Kapazitätsproblemen: Avamar: So erfassen Sie die Informationen zum Troubleshooting von Kapazitätsproblemen

Der Befehl status.dpn bzw. die Werte auf der Avamar-Administrations-Benutzeroberfläche zeigen zumindest die GSAN -Kapazität an.

Schritt 3. Überprüfen, ob die Kapazität des Betriebssystems voll ist:

Mit dem folgenden Befehl können Sie die aktuelle Betriebssystemkapazität für alle Festplattenpartitionen anzeigen. Wenn einer der Werte 85 % erreicht oder überschritten hat, wie in der zweiten Beispielausgabe zu sehen, wird dies als hohe Betriebssystemkapazität betrachtet:

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

Beispielausgabe:

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"

Nur wenn die Betriebssystemkapazität unter 85 % liegt, sollte das Troubleshooting der GSAN -Kapazität durchgeführt werden. 

Schritt 4. Nicht kapazitätsbezogene Probleme, die für Kapazitätsprobleme gehalten werden können:

Es kann passieren, dass Client-Backups nicht aus „Kapazitätsgründen“, sondern aus „Kontingentgründen“ fehlschlagen. Dies kann manchmal als Kapazitätsproblem missverstanden werden.

Diese Situation kann mithilfe des Befehls status.dpn oder einer der anderen erfassten Ausgaben, die eine geringere Kapazität anzeigen, überprüft werden.

Es kann auch passieren, dass Client-Backups aufgrund anderer Non-GSAN -Kapazitätsprobleme fehlschlagen oder nicht ausgeführt werden können. Dies sollte anhand der erfassten Informationen bestätigt werden können. Außerdem wird es auf der Avamar-Administrations-Benutzeroberfläche angezeigt.

• Avamar: Lösungspfad für Metadatenkapazität
• Data Domain: Lösungspfad für hohe Kapazität durch Avamar-Integration

Wenn die GSAN -Kapazität hoch ist und die anderen Kapazitäten ebenfalls hoch sind, kann das Troubleshooting in beliebiger Reihenfolge durchgeführt werden (mit Ausnahme der Betriebssystemkapazität, die immer zuerst überprüft werden muss).

Schritt 5. Stripe-Ausgleich und BS-Festplattenausgleich:

Bei Avamar sind „Stripes“ die Containerdateien, in denen die Backupdaten auf den Daten-Nodes gespeichert werden (mit Ausnahme eines Avamar-Rasters mit einem Node).

Es wird erwartet, dass die Stripes „ausgeglichen“ oder gleichmäßig über die verschiedenen Festplatten und Nodes innerhalb des Rasters verteilt sind. Manchmal ist dies jedoch nicht der Fall.

Bei Avamar ist der größte Node bzw. die größte Festplattenpartition der limitierende Faktor in Bezug auf die Avamar-Kapazität.

Dies ist beabsichtigt, damit keine/r der Festplatten oder Nodes mehr Stripes erzeugt, als verarbeitet werden können (oder zulässig sind). Daher sind ausgeglichene Stripes wichtig für die Kapazität.

Wenn Sie beispielsweise weitere Daten-Nodes für die Erweiterung des Avamar-Rasters hinzufügen, muss ein Neuausgleich ausgeführt werden, um die Stripes gleichmäßig auf die neuen Nodes zu verteilen und so den Prozentsatz der Avamar-Gesamtkapazität zu verringern.

Eine weitere Ausgleichsart, die näher betrachtet werden muss, ist der BS-Festplattenausgleich. Dies bezieht sich nur auf Datenpartitionen auf demselben Node, nicht auf Partitionen auf mehreren Nodes. 

Wenn auf einem Daten-Node eine Partition viel größer oder kleiner als eine andere Partition auf demselben Node ist, kann ein Grenzwert namens „freespaceunbalance“ überschritten werden. Dies betrifft zwar in der Regel die Betriebssystem- und nicht die GSAN -Kapazität, es kann jedoch als GSAN -Kapazitätsproblem gemeldet werden.

Schritt 6. Überprüfen, ob die automatische Speicherbereinigung ausgeführt wurde 

Führen Sie den folgenden Befehl aus, um Informationen zur automatischen Speicherbereinigung abzurufen:

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

Im Idealfall zeigt die Ausgabe, dass die GC in den letzten 30 Tagen ausgeführt wurde:

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-Fehlermeldungen können u. a. Folgendes enthalten:

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

Wenn die GC fehlgeschlagen ist, beheben Sie dieses Problem zuerst mithilfe des folgenden Artikels: Avamar: Troubleshooting von Fehlern bei der automatischen Speicherbereinigung (Lösungspfad)
(Wenn die Probleme bereits behoben wurden, fahren Sie mit dem nächsten Schritt fort.)

Schritt 7. Wird die automatische Speicherbereinigung lange genug ausgeführt?

a. Führen Sie den folgenden Befehl aus, um die maximal zulässige Zeit für die GC zu überprüfen:

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

Beispielausgabe:

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

Beachten Sie den Wert maxtime , der in diesem Beispiel 14.400 (Sekunden) beträgt.
(Ein Wert von 0 bedeutet unbegrenzt.)

b. Führen Sie den folgenden Befehl aus, um zu ermitteln, wie lange die GC ausgeführt wird und wie viele „Durchläufe“ abgeschlossen werden:
(Durchläufe beziehen sich auf die Schichten der gespeicherten Backupdaten. Stellen Sie sich die GSAN -Kapazität wie die Schichten einer Zwiebel vor. Die äußeren Schichten müssen abgezogen oder entfernt werden, bevor die inneren Schichten zu sehen sind. Jeder Durchgang stellt eine Schicht der gespeicherten GSAN -Daten dar.)

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

Beispielausgabe:

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

Beachten Sie die Anzahl der Durchläufe und die elapsed-time (Sekunden).

c. Unter der Annahme, dass die maxtime ungleich Null ist, berechnen Sie 2/3 der maxtimeund vergleichen Sie den Wert mit der verstrichenen Zeit.
(Im obigen Beispiel sind 2/3 von 14.400 9.600 und alle Ausgaben zur verstrichenen Zeit liegen deutlich unter dieser Zahl.)

Verschiedene Probleme können dazu führen, dass die GC langsam ausgeführt wird oder nicht alles scannt. Beispielsweise, wenn in der Vergangenheit nicht genügend Zeit für die Ausführung war, eine falsche Konfiguration oder Fehler vorliegen usw.

Wenn Sie Bedenken hinsichtlich der maxtimeoder der Anzahl der Durchläufe haben, erstellen Sie einen Service-Request beim Dell Technologies Avamar-Supportteam, um weitere Untersuchungen durchzuführen.

Schritt 8. Wenn der Verdacht besteht, dass die GC nicht genügend oder nicht die erwarteten Daten entfernt hat:

Wenn bestätigt wurde, dass die GC lange genug ausgeführt wird, kann es passieren, dass Daten aus Gründen, die außerhalb der Kontrolle der GC liegen, nicht erfasst werden. Nachfolgend finden Sie eine Liste der dokumentierten Gründe, die in der Regel überprüft werden sollten:

a. Vergewissern Sie sich, dass die Backups so konfiguriert sind, dass sie zumindest irgendwann oder regelmäßig ablaufen. Wenn Backups nicht häufig ablaufen, hat die GC nicht viel zu tun.

b. Lesen Sie diesen Artikel, um die Clients mit der höchsten Änderungsrate zu ermitteln: Avamar: So managen Sie die Kapazität mit dem capacity.sh-Skript (Überprüfen Sie sowohl „% OF TOTAL“ als auch „CHGRATE“.)

c. Prüfen Sie auf übersprungene Hashes, siehe Avamar: Avamar-GC meldet „übersprungene Hashes“, die nicht bereinigt werden können. Dies tritt zwar selten auf, ist aber normal und kann übersprungen werden.

d. Es gibt eine Markierung oder Option, die den Avamar Server zwingt, das letzte und das neueste Backup von jedem Client aufzubewahren. Dies geschieht aus Sicherheitsgründen, damit nicht alle Backups eines Clients versehentlich ablaufen. Dies kann jedoch zu anderen Problemen führen, wenn es um die Datenbereinigung und die automatische Speicherbereinigung geht. Das Dell Technologies Avamar-Supportteam kann überprüfen, ob dies aktiviert ist.

e. Wenn Backups kürzlich von GSAN auf das DD-Back-end verschoben wurden oder ein versehentlicher GSAN -Backup stattgefunden hat, die GSAN -Kapazität jedoch nicht verringert wurde, erstellen Sie einen Service-Request beim Dell Technologies Avamar-Supportteam, um weitere Untersuchungen durchzuführen.

Schritt 9. Das Avamar-Raster ist für die Menge der aktuellen oder erwarteten Daten unterdimensioniert:

Nachdem alle anderen Lösungen und möglichen Ursachen auf hohe Kapazität überprüft wurden und es sich nicht um ein Konfigurationsproblem oder ein Problem mit versehentlichen Daten handelt:

Das bedeutet, dass Daten möglicherweise gelöscht oder Optionen untersucht werden müssen, wie z. B. die Migration bestimmter Clients auf andere Avamar-Raster, das Hinzufügen neuer Daten-Nodes usw.

Schritt 10. Bestätigen Sie alle Kapazitätsereignisse und setzen Sie den Backup-Planer bei Bedarf fort:

a. Sobald die Kapazitätsprobleme behoben sind, bestätigen Sie alle kapazitätsbezogenen Ereignisse auf der Avamar-Admin-Benutzeroberfläche.

b. Setzen Sie den Backup-Planer fort:

dpnctl start sched

Weitere Informationen zur Avamar-Kapazität, zu Schulungen, Troubleshooting und mehr finden Sie unter: Avamar: Troubleshooting, Probleme und Fragen zur Kapazität – Alle Kapazitäten (Lösungspfad)

• Durch die Aktion selbst können die wirklichen Probleme „maskiert“ und verborgen werden, so dass sie in ein paar Tagen oder Wochen wieder auftauchen und dieser manuelle Vorgang quasi Zeitverschwendung war.
• Darüber hinaus wird die manuelle Speicherbereinigung möglicherweise nicht so effizient ausgeführt, da sie außerhalb des Zeitplans läuft.
  • Gelegentlich können dadurch auch andere Probleme verschlimmert werden. Weitere Informationen finden Sie unter: Avamar: Informationen zur Verwendung der manuellen Speicherbereinigung

• Diese Änderung oder Aktion wird in der Regel nicht durchgeführt und sollte auch nicht standardmäßig berücksichtigt werden. Diese Änderung muss von einem/einer Avamar-L2-TechnikerIn oder Subject Matter ExpertIn (SME) genehmigt werden.
• Leider können solche Aktionen auf unterschiedliche Weise dauerhafte Schäden an einem Avamar-Raster verursachen, die nur durch das Hinzufügen zusätzlicher Storage Nodes oder eine erneute Bereitstellung behoben werden können.

Beachten Sie, dass keine der oben aufgeführten Aktionen durchgeführt wird, da das Support-Team die Kapazitätsprobleme bestmöglich lösen möchte.