Avamar: Kapazität des Betriebssystems (BS) (Lösungspfad)

Summary: Dieser Artikel zum Lösungspfad ist für die Behandlung oder das Troubleshooting von Kapazitätsproblemen des Betriebssystems (BS) auf Avamar vorgesehen.

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

Umgang mit oder Troubleshooting von BS-Kapazitätsproblemen auf Avamar.

Dieser Artikel zum Lösungspfad wurde entwickelt, um Probleme mit der Betriebssystemkapazität auf Avamar zu beheben oder zu beheben.


Informationen zu den ersten Konzepten und zum Verständnis der Betriebssystemkapazität finden Sie im Schulungsartikel Avamar: Konzepte und Schulungen

zum KapazitätsmanagementWie im Schulungsartikel zusammengefasst, ist ein angemessenes Verständnis der folgenden Themen erforderlich, um mit dem Rest dieses Artikels fortzufahren:

  • Ein grundlegendes Verständnis von Kontrollpunkten (cp), Kontrollpunktvalidierung (hfscheck)und Garbage Collection (GC) und die Bedeutung der einzelnen
  • Der Unterschied zwischen GSAN (auch bekannt als "Nutzerkapazität" und BS-Kapazität)
  • Prüfpunkt-Overhead-Daten
  • Wenn eine der Datenpartitionen mehr als 89 % des gesamten physischen BS-Kapazitätsspeicherplatzes ausmacht, kann die automatische Speicherbereinigung nicht ausgeführt werden.
  • Je näher ein Avamar-Raster an 100 % Nutzerkapazität liegt, desto weniger Betriebssystemkapazität ist für Prüfpunkt-Overhead verfügbar.
  • Faktoren, die zum Kontrollpunktoverhead beitragen, einschließlich asynchrones Verarbeiten, Anzahl der gespeicherten Prüfpunkte, HFSCheck und die Wichtigkeit der Kontrollpunktvalidierung usw.
  • So finden Sie die Kapazitätsstufen des Betriebssystems
  • Grundlegende Maßnahmen zur Entlastung der Betriebssystemkapazität

 

Oft ist es am einfachsten, die Kapazität des Betriebssystems als die Größe des GSAN Daten (genauer gesagt der für diese Daten zugewiesene Speicherplatz) und der durch Avamar-Prüfpunkte erzeugte Overhead. Je größer die Anzahl der Prüfpunkte und je höher die Änderungsrate, desto höher ist der Kontrollpunkt-Overhead.


Eine hohe Betriebssystemkapazität kann sich wie folgt auswirken:

  • Fehler bei der automatischen Speicherbereinigung: GC schlägt mit MSG_ERR_DISKFULL fehl wenn die Betriebssystemkapazität über 89 % steigt
  • Backup- oder Replikationsfehler: Backups oder eingehende Replikationen können mit MSG_ERR_STRIPECREATE fehlschlagen, wenn die Betriebssystemkapazität über 90 % steigt. (Dies ist nur dann der Fall, wenn ein neuer Daten-Stripe erstellt werden muss. Wenn kein neuer Stripe benötigt wird, werden Backups und Replikationen möglicherweise trotzdem erfolgreich ausgeführt.)
  • Prüfpunktfehler: Ein Prüfpunkt schlägt mit MSG_ERR_DISKFULL fehl, wenn die Betriebssystemkapazität über 96 % steigt.


Wie oben gezeigt wird, ist die Betriebssystemkapazität oft der erste Typ von Avamar-Kapazität, der berücksichtigt werden muss, wenn auch andere Avamar-Kapazitäten hoch sind. Zumindest kann die automatische Speicherbereinigung nicht ausgeführt werden, wenn die Betriebssystemkapazität bestimmte Level erreicht, selbst wenn die GSAN Oder die Benutzerkapazität ist ebenfalls hoch.

Im Allgemeinen wird die Betriebssystemkapazität als hoch betrachtet, wenn GC mit MSG_ERR_DISKFULL fehlschlägt, wenn die Betriebssystemkapazität über 89 % steigt. Wenn die Betriebssystemkapazität weniger als 89 % beträgt, sind keine Wartungsjobs betroffen. 

 
Hinweis: Es wird erwartet, dass die Kapazität des Betriebssystems im Laufe des Tages schwankt. Die Überprüfung des reibungslosen Ablaufs der täglichen Wartungsjobs ist wichtig und in der Regel die beste Lösung, um Betriebssystemkapazitätsprobleme möglichst zu vermeiden.
 
Hinweis: Obwohl die oben genannten Schritte als Avamar-BS-Kapazität betrachtet werden, ist es möglich, dass Probleme mit der Betriebssystemkapazität vorliegen, die nicht direkt mit Backuppartitionen oder Prüfpunkten zusammenhängen. Dies sind die Festplatten und Partitionen, auf denen das Linux-Betriebssystem installiert ist. Diese Probleme sind zwar seltener, können aber andere Auswirkungen haben, die im Folgenden erläutert werden.

Cause

Die Kapazität des Avamar-Betriebssystems kann sich aus einer beliebigen Kombination der folgenden Gründe erhöhen:

  • Hohe Änderungsrate von Backupdaten, wobei "zu viele zu schnell" hinzugefügt werden
  • High GSAN oder "User Capacity", was weniger Platz für die Betriebssystemkapazität lässt und manchmal sogar zu höheren Änderungsraten führen kann
  • Der Prüfpunkt kann nicht erfolgreich abgeschlossen werden, was zum Status "MSG_ERR_DISKFULL" führt, wie in der Ausgabe zu sehen ist.
  • Eine Kontrollpunktvalidierung (hfscheck) ist fehlgeschlagen oder wurde vor kurzem nicht ausgeführt, sodass die ältesten Prüfpunkte nicht abgeschaltet oder entfernt werden können
  • Kontrollpunkte werden aus anderen Gründen nicht ausgeführt, z. B. zu hohe Kontrollpunktaufbewahrungseinstellungen
 

Eine hohe Betriebssystemkapazität auf anderen Festplattenpartitionen kann verschiedene Ursachen haben, darunter eine falsche Datenplatzierung, zu große Protokolldateien usw.

 
Eine kurze Erklärung des Ausdrucks "zu viel zu schnell" als Grund für eine hohe Betriebssystemkapazität kann wie folgt erklärt werden:
  • Ein kurzer Hintergrund: Avamar-Prüfpunkte sind schreibgeschützte Snapshots und mit den Livedaten verknüpft. Da dies mit Links erstellt wird, benötigt ein Prüfpunkt unmittelbar nach der Erstellung keinen zusätzlichen Speicherplatz. Wenn keine Änderungen an den Livedaten vorgenommen werden, verwendet der Prüfpunkt keinen zusätzlichen Speicherplatz.
  • Dies ändert sich, wenn die Live-Daten geändert werden, während der Prüfpunkt gleich bleibt. Zu diesem Zeitpunkt gibt es eine Originalkopie der Daten im Prüfpunkt und die aktualisierte Livekopie der geänderten Daten. Dies ist völlig beabsichtigt und beabsichtigt. Aus diesem Grund gibt es reservierten Speicherplatz für die Betriebssystemkapazität.
  • Wenn jedoch die Menge oder Geschwindigkeit der Änderungsdaten drastisch und plötzlich ansteigt, kann dies zu einer ungewöhnlichen Spitze in der Größe der Betriebssystemkapazität führen und als "zu viel zu schnell" betrachtet werden
  • Die Spalte capacity.sh würde dies als Ursache anzeigen, wenn die Ausgabe über mehrere Tage verglichen wird.

Resolution

Wenn Wartungsjobs, einschließlich der automatischen Speicherbereinigung, unter hoher Avamar-Betriebssystemkapazität fehlschlagen, führen Sie die folgenden Schritte aus:

1. Erfassen Sie alle Avamar-Kapazitätsinformationen, um sich ein Bild von der Situation zu machen: Avamar: So erfassen Sie die Informationen, die zum Troubleshooting von Kapazitätsproblemen erforderlich sind.


2. Überprüfen Sie als Nächstes, wie hoch die Kapazität des Betriebssystems ist und welche Aktionen möglicherweise erforderlich sind. Im Artikel zur Datenerfassung kann dies mit dem folgenden Befehl ermittelt werden: 

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

So funktioniert Avamar, dass der angezeigte HÖCHSTE Wert für "fs-percent-full" der begrenzende Faktor für die aktuelle Betriebssystemkapazität ist. Je nach Node-Typerzeugung und -Größe kann die Anzahl der Datenpartitionen, in denen Backup- und Prüfpunktdaten gespeichert sind, variieren. Ausgehend vom Linux-Betriebssystem können dies Festplatten oder Partitionen wie "/data0*" sein, wobei "*" eine einzelne Ziffer sein kann. Die Anzahl der Datenpartitionen hängt vom Node-Typ, der Hardwaregeneration und der Größe ab (und kann nicht geändert werden).


3. Überprüfen Sie die Anzahl der gefundenen Prüfpunkte und wie lange diese überprüft wurden. Führen Sie dazu den Befehl aus:

cplist
cp.20290310080041 Mon Mar 10 08:00:41 2025   valid rol ---  nodes   4/4 stripes   5980
cp.20290310080649 Mon Mar 10 08:06:49 2025   valid --- ---  nodes   4/4 stripes   5980
 
Hinweis: Einige Prüfpunkte müssen auf jeden Fall beibehalten werden.
 
 

4. Überprüfen Sie ab "MSG_ERR_DISKFULL", ob Prüfpunktvorgänge fehlschlagen, indem Sie den folgenden Befehl ausführen:

dumpmaintlogs --types=cp --days=4 | grep "\<430"


Wenn Prüfpunkte erfolgreich abgeschlossen wurden, wird eine Ausgabe ähnlich der folgenden angezeigt:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> completed checkpoint maintenance
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance


Wenn aufgrund von MSG_ERR_DISKFULL fehlgeschlagen, wird diese Ausgabe angezeigt:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance
 
Wenn Prüfpunktvorgänge mit MSG_ERR_DISKFULL Fehlern fehlschlagen, eröffnen Sie einen Service-Request beim Dell Technologies Avamar Support-Team, andernfalls fahren Sie mit Schritt 5 fort.
 
 
5. Überprüfen Sie, ob andere Prüfpunktprobleme vorliegen:
 
Die Spalte cplist command Zeigt an, wie viele Kontrollpunkte gefunden wurden und wie zuletzt ein Kontrollpunkt validiert wurde. Wie auch im Artikel zur Datenerhebung gezeigt, verwenden Sie Avamar – So verstehen Sie die durch den Befehl cplist generierte Ausgabe, um die cplist Ausgabe.

Es sollten zwei oder drei Kontrollpunkte vorhanden sein, und mindestens einer der Prüfpunkte der letzten 24 Stunden wird als validiert mit hfscheck. Dies wäre normales Verhalten und Ausgabe von allen erfolgreich ausgeführten Jobs und normalen Kontrollpunktaufbewahrungseinstellungen.

Wenn mehr als drei Prüfpunkte oder keine validierten Prüfpunkte innerhalb der letzten 24 Stunden vorhanden sind, muss dies zuerst angegangen werden, da dies möglicherweise die einzige Möglichkeit ist, die Betriebssystemkapazität zu reduzieren. Wenn dieses Szenario auftritt, eröffnen Sie einen Service-Request bei Dell Technologies, andernfalls fahren Sie mit Schritt 6 fort.
 
 

6. Bestimmen Sie die Änderungsrate:

capacity.sh

 

Beispiel Ausgabe:

  DATE     AVAMAR NEW     #BU    SCANNED       REMOVED     MINS PASS AVAMAR NET      CHG RATE
========== ============= ==== ============= =============  ==== ==== ============= ==========
2020-02-25       1066 mb    8     302746 mb       -641 mb     0   23        425 mb      0.35%
2020-02-26       1708 mb    8     303063 mb       -518 mb     0   23       1189 mb      0.56%
2020-02-27       3592 mb    8     304360 mb       -413 mb     0   23       3178 mb      1.18%
2020-02-28       1086 mb    8     304892 mb       -372 mb     0   23        713 mb      0.36%
2020-03-01       1002 mb    8     305007 mb      -7469 mb     0   25      -6467 mb      0.33%
2020-03-02        585 mb    7     197874 mb          0 mb     0    9        585 mb      0.30%
2020-03-03        348 mb    7     199305 mb          0 mb     0   10        348 mb      0.17%
2020-03-04        775 mb    7     198834 mb         -2 mb     0   10        773 mb      0.39%
2020-03-05        380 mb    4     196394 mb         -5 mb     0   10        375 mb      0.19%
2020-03-06       1068 mb    4     159960 mb          0 mb     0    9       1067 mb      0.67%
2020-03-07        443 mb    4     197132 mb        -18 mb     0   17        424 mb      0.23%
2020-03-08        348 mb    4     197231 mb        -48 mb     0   20        300 mb      0.18%
2020-03-09        370 mb    4     196506 mb          0 mb     0    9        370 mb      0.19%
2020-03-10        349 mb    4     197292 mb        -17 mb     0   20        332 mb      0.18%
2020-03-11        974 mb    2      77159 mb          0 mb     0    0        974 mb      1.26%
=============================================================================================
 14 DAY AVG       940 mb    5     222517 mb       -634 mb     0   15        306 mb      0.42%
 30 DAY AVG      1121 mb    5     195658 mb       -771 mb     0   14        349 mb      0.59%
 60 DAY AVG       994 mb    4     128657 mb      -1165 mb     0   17       -170 mb      0.98%

Top Change Rate Clients.  Total Data Added 14103mb

     NEW DATA % OF TOTAL CHGRATE TYPE CLIENT
============= ========== ======= ====
      6803 mb     48.24   0.91%  AVA /Windows/testing/Hyper-V/hyperv1
      3218 mb     22.82   0.61%  AVA /clients/exchange1
      2932 mb     20.80   0.44%  AVA /BMR/server1
       983 mb      6.97   0.10%  AVA /Windows/testing/SQL/sql1
        97 mb      0.69   1.13%  AVA /REPLICATE/grid2.company.com/MC_BACKUPS

 


Manchmal, wenn die hohe Änderungsrate oder die Situation "zu viel zu schnell" wieder auftritt, kann dies durch eine Senkung der Gesamtwerte gemildert werden. GSAN oder Nutzerkapazität. Mit einem niedrigeren GSAN Kapazität, gibt es etwas mehr Platz für den Overhead der Betriebssystemkapazität, was auch zu weniger Änderungen am Daten-Storage-Container führt. Wenn Sie Unterstützung in diesem Szenario benötigen, öffnen Sie einen Service-Request beim Dell Technologies Avamar Support-Team, andernfalls fahren Sie mit Schritt 7 fort.

 

7. Probleme mit hohen Betriebssystemkapazitäten auf anderen Festplattenpartitionen haben verschiedene Ursachen, aber die Lösungen erfordern technischen Support. Eröffnen Sie einen Service-Request beim Dell Technologies Avamar Support-Team, andernfalls fahren Sie mit Schritt 7 fort.

 
 

Sobald die Betriebssystemkapazität behoben ist, GSAN Kapazität oder andere Avamar-Kapazitäten können überprüft werden. Weitere Informationen finden Sie unter Avamar Capacity Troubleshooting, Probleme und Fragen – alle Kapazitäten (Lösungspfad).

 

Affected Products

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