Avamar GSAN oder Pfad zur Lösung der 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 zu erwägen GSAN Kapazität als Speicherplatz und Auslastung für Clientbackups.

• Grundlegendes Verständnis der Deduplizierung
• Grundlegendes Verständnis von Kontrollpunkten, Kontrollpunktvalidierung (hfscheck) und Garbage Collection und deren Bedeutung.
• Der Unterschied zwischen GSAN (oder Nutzer) Kapazität und Kapazität des Betriebssystems
• Änderungsrate
• Stationärer Zustand

• Backup- oder Replikationsfehler, wenn der Status des Grid-Zugriffs in den "Admin-Modus" geändert wurde

  • Ein Clientbackupjob 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-Schedulers (bis er von jemandem bestätigt und freigegeben wurde)

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

1. Aufgrund der Deduplizierung muss Avamar nur die geringfügigen Änderungen und Unterschiede zwischen den einzelnen Clientbackupjobs speichern und speichern. Wenn neue Backups (oder eingehende Replikationen) ausgeführt werden, kann es neue Daten hinzufügen und die Kapazität oder den Auslastungswert von Avamar erhöhen. 
2. Nach einer bestimmten Zeit laufen Backups basierend auf der konfigurierten Aufbewahrungs- und Ablauffrist ab und werden nicht im Avamar-Raster gefunden, das wiederhergestellt werden kann. 
3. Wenn der Avamar-Wartungsjob namens Garbage Collection (GC) ausgeführt wird, findet er alle eindeutigen Teile oder Datenblöcke, die aufgrund dieser abgelaufenen Backups nicht mehr benötigt werden. GC überprüft, ob keine anderen aktuellen Backups dieselben Daten gemeinsam nutzen (aufgrund der Deduplizierung) und entfernt oder gibt dann die Datenblöcke heraus oder 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 Zustand" bezeichnet. Dies ist das Ziel jedes installierten Avamar-Rasters.

Bevor ein neues Avamar Grid eingerichtet und konfiguriert wird, werden allgemeine Dimensionierungsberechnungen vor der Installation durchgeführt, um die Kapazität zu bestimmen, die zum Speichern der Backupdaten erforderlich ist. Diese Berechnungen basieren auf den Aufbewahrungsanforderungen der Kunden und darauf, wie viele Daten gesichert werden sollen. Außerdem wird geschätzt, wie viele dieser Daten durchschnittlich dedupliziert werden könnten usw.

1. Die automatische Speicherbereinigung wird nicht konsistent ausgeführt.
2. Die automatische Speicherbereinigung ist langsam oder wird nicht lange genug ausgeführt.
3. Deduplizierungsschätzungen vor der Avamar-Grid-Installation waren nicht genau genug
4. Andere Daten als das, was vor der Avamar Grid-Installation berechnet wurde, werden auf diesem Avamar Server gesichert.
5. Andere Gründe

Überprüfen Sie, ob jeder der folgenden Schritte zur Fehlerbehebung für die Umgebung zutrifft:

Schritt 1: Datensammlung:

Stellen Sie sicher, dass keine anderen Nicht-Kapazitätsprobleme mit dem Avamar Grid vorliegen. Falls ja, müssen sie möglicherweise VOR dem Troubleshooting bearbeitet werden.

Dazu gehören Hardwarefehler, Datenintegritätsprobleme (einschließlich Offline-Nodes), Offline-Stripes, Kontrollpunktvalidierungsfehler oder fehlgeschlagene Wartungsjobs. Wenn einer dieser Punkte ein Problem darstellt, muss das Kapazitäts-Troubleshooting gestoppt und andere Probleme behoben werden. Sobald andere Probleme behoben wurden, kann die Kapazität erneut überprüft werden.

Es sollte eine Integritätsprüfung ausgeführt werden (Avamar: Ausführen des proactive_check.pl Skripts für die Integritätsprüfung auf einem Avamar Server, mindestens jedoch status.dpn kann einen schnellen Überblick und eine schnelle Überprüfung der meisten dieser Probleme geben. Siehe Avamar: So verstehen Sie die Ausgabe, die durch den Befehl status.dpn erzeugt wird

Weitere Informationen finden Sie im folgenden Artikel: Avamar: So wenden Sie den Ansatz der "Avamar-Troubleshooting-Hierarchie" richtig an.

Wenn Unterstützung erforderlich ist, um Probleme mit der fehlenden Kapazität zu beheben, erstellen Sie einen Service-Request beim Dell Technologies Avamar Support-Team.

Schritt 2. Erfassung von Kapazitätsinformationen: 

Im Folgenden finden Sie alle erforderlichen Informationen, die zum Troubleshooting von Avamar-Kapazitätsproblemen erforderlich sind: Avamar: So erfassen Sie die Informationen zum Troubleshooting von Kapazitätsproblemen

Zumindest ist die status.dpn oder die Werte in der Avamar-Administrations-Benutzeroberfläche zeigen die GSAN Fassungsvermögen.

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

Mit dem folgenden Befehl können Sie den aktuellen Wert der Betriebssystemkapazität für jede Festplattenpartition anzeigen. Wenn einer der Werte 85 % erreicht oder überschritten hat, wie in der zweiten Beispielausgabe, wird dies als hohe Betriebssystemkapazität betrachtet:

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

Beispiele für Ausgaben:

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 die GSAN Das Kapazitäts-Troubleshooting wird fortgesetzt. 

Schritt 4. Nicht-Kapazitätsprobleme, die manchmal als Kapazität missverstanden werden können:

Es ist möglich, dass Clientbackups nicht aus "Kapazitätsgründen", sondern aus "Quotengründen" fehlschlagen. Diese können manchmal als Kapazität missverstanden werden.

Diese Situation kann bestätigt werden durch die status.dpn Befehl oder eine der anderen erfassten Ausgaben mit geringerer Kapazität.

Es ist auch möglich, dass Clientbackups aufgrund anderer Umstände fehlgeschlagen sind oder nicht ausgeführt werden können. Non-GSAN Kapazitätsgründe. Die erfassten Informationen sollten dies bestätigen oder können auch in der Avamar-Administrations-Benutzeroberfläche angezeigt werden.

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

Wenn die GSAN Die Kapazität ist hoch und diese anderen Kapazitäten sind ebenfalls hoch. Das Troubleshooting kann in beliebiger Reihenfolge durchgeführt werden (mit Ausnahme der Betriebssystemkapazität, die immer an erster Stelle stehen muss).

Schritt 5. Stripe-Ausgleich und BS-Festplattenausgleich:

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

Die Erwartung ist, dass Stripes "ausgeglichen" oder gleichmäßig über die verschiedenen Festplatten und Nodes innerhalb des Rasters verteilt sind, manchmal können sie jedoch unausgeglichen werden.

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

Dies ist beabsichtigt, sodass keine der Festplatten oder Nodes mehr Stripes erzeugt, als sie verarbeiten können (oder zulassen). Daher sind ausgeglichene Stripes wichtig für die Kapazität.

Wenn Sie beispielsweise zusätzliche Daten-Nodes für die Avamar-Grid-Erweiterung hinzufügen, muss ein Lastenausgleich 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 Art des Ausgleichs, die Verständnis erfordert, ist der BS-Festplattenausgleich. Dies ist nur auf Datenpartitionen auf demselben Node beschränkt, nicht auf Partitionen auf mehreren Nodes. 

Wenn auf demselben Daten-Node eine Partition viel größer oder kleiner als eine andere Partition desselben Node ist, kann ein Limit namens " überschritten werdenfreespaceunbalance“. Dies ist zwar in der Regel auf dem Betriebssystem und nicht auf dem GSAN Kapazität, kann sie als GSAN Kapazitätsproblem.

Schritt 6. Überprüfen Sie, ob die automatische Speicherbereinigung abgeschlossen wird: 

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 GC in den letzten 30 Tagen abgeschlossen 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 umfassen:

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 GC fehlgeschlagen ist, beheben Sie dieses Problem zuerst anhand des folgenden Artikels als Referenz: Avamar: Troubleshooting von Fehlern bei der automatischen Speicherbereinigung (GC) (Lösungspfad)
(Wenn Probleme bereits behoben wurden, fahren Sie mit dem nächsten Schritt fort.)

Schritt 7. Läuft GC lange genug?

ein. Führen Sie den folgenden Befehl aus, um die maximal zulässige Zeit für 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 die maxtime Wert, der in diesem Beispiel 14400 (Sekunden) beträgt.
(Ein Wert von 0 bedeutet unbegrenzt)

b. Führen Sie den folgenden Befehl aus, um zu bestimmen, wie lange der GC ausgeführt wird und wie viele "Durchläufe" abgeschlossen werden:
(Durchläufe betreffen die Schichten der gespeicherten Backupdaten. Denken Sie an die GSAN Fassungsvermögen wie die Schichten einer Zwiebel. Die äußeren Schichten müssen abgezogen oder entfernt werden, bevor die inneren Schichten zu sehen sind. Jeder Durchgang ist eine Ebene der GSAN gespeicherten Daten.)

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

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

c. Unter der Annahme, dass die maxtime ungleich Null ist, berechnen Sie 2/3 von maxtime, und vergleichen Sie sie mit der verstrichenen Zeit.
(Im obigen Beispiel ist 2/3 von 14400 9600, und alle Ausgaben der verstrichenen Zeit liegen deutlich unter dieser Zahl.)

Verschiedene Probleme können dazu führen, dass GC langsam läuft oder nicht alles scannt. Dazu kann gehören, dass Sie in der Vergangenheit über einen längeren Zeitraum oder mehrere Tage nicht genügend Zeit für die Ausführung hatten, eine falsche Konfiguration, Fehler usw.

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

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

Wenn bestätigt wird, dass die Speicherbereinigung lange genug ausgeführt wird, ist es möglich, dass Daten aus Gründen, die außerhalb der Kontrolle der automatischen Speicherbereinigung liegen, nicht erfasst werden. Dies ist eine Liste der dokumentierten Gründe, die in der Regel überprüft werden sollten:

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

b. Verwenden Sie diesen Artikel, um die Clients mit der höchsten Änderungsrate zu finden: Avamar: So verwalten Sie die Kapazität mit dem capacity.sh Skript. (Überprüfen Sie sowohl die "% OF TOTAL" und "CHGRATE".)

c. Prüfen Sie per Avamar auf übersprungene Hashes: Avamar Garbage Collection meldet "übersprungene Hashes", die nicht bereinigt werden können. Wenn diese auftreten, aber selten, ist dies normal und kann übersprungen werden.

d. Es gibt ein Flag oder eine Option, die den Avamar Server zwingt, das letzte und das neueste Backup von jedem Client aufzubewahren. Dies wird aus Sicherheitsgründen verwendet, damit nicht jedes Backup eines Clients versehentlich abgelaufen ist. Dies kann jedoch zu anderen Problemen führen, wenn es um die Datenbereinigung und die automatische Speicherbereinigung geht. Das Supportteam von Dell Technologies Avamar kann bestätigen, ob dies aktiviert ist.

e. Wenn Backups kürzlich von GSAN an das DD-Backend oder es gab einen versehentlichen GSAN Backup, aber die GSAN Die Kapazität wird nicht verringert. Erstellen Sie einen Service-Request beim Dell Technologies Avamar Support-Team, um weitere Untersuchungen durchzuführen.

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

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

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

Schritt 10. Quittieren Sie alle Kapazitätsereignisse und setzen Sie den Backup-Scheduler bei Bedarf fort:

ein. Sobald die Kapazitätsprobleme behoben sind, quittieren Sie alle kapazitätsbezogenen Ereignisse in der Avamar-Admin-Benutzeroberfläche.

b. Setzen Sie den Backup-Scheduler fort:

dpnctl start sched

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

• Diese Aktion an sich kann die wirklichen Probleme "maskieren" und verbergen, so dass sie erst in ein paar Tagen oder Wochen später wieder auftauchen, was dazu führt, dass diese manuelle Arbeit verschwendete Zeit ist.
• Darüber hinaus läuft der manuelle GC möglicherweise nicht so effizient, da der Zeitplan abgelaufen ist.
  • Gelegentlich kann es andere Probleme verschlimmern. Weitere Informationen finden Sie unter: Avamar: Informationen zur Verwendung der manuellen automatischen Speicherbereinigung

• Diese Änderung oder Aktion wird in der Regel nicht durchgeführt und sollte nicht standardmäßig berücksichtigt werden. Ein Avamar L2-Techniker oder Subject Matter Expert (SME) muss diese Änderung genehmigen.
• Leider können solche Aktionen auf verschiedene 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.

Bitte beachten Sie, dass keine der oben aufgeführten Aktionen durchgeführt wird, da das Support-Team die Kapazitätsprobleme auf die vorteilhafteste Weise lösen möchte.