Avamar: Schritte zum Validieren von Fehlern bei der automatischen Speicherbereinigung in Avamar
Summary: Im Folgenden sind die Schritte zum Validieren von Fehlern bei der automatischen Speicherbereinigung (Garbage Collection, GC) auf Avamar aufgeführt.
Symptoms
Was versteht man unter der automatischen Speicherbereinigung (Garbage Collection)?
Garbage Collection (GC) ist der Prozess des Löschens nicht verwendeter Blöcke aus Backups, die abgelaufen sind. Dadurch wird Kapazität auf dem Avamar Server freigegeben.
Standardmäßig wird die automatische Speicherbereinigung einmal täglich ausgeführt, beginnend zu Beginn des Wartungszeitfensters.
Häufige Fehlersymptome:
MSG_ERR_DDR_ERRORMSG_ERR_DISKFULLMSG_ERR_MISCMSG_ERR_TRYAGAINLATERMSG_ERR_BADTIMESYNC
Cause
Häufige Ursachen für GC-Ausfälle:
MSG_ERR_DDR_ERROR
- Es gibt viele grundlegende Probleme, die dazu führen können, dass GC mit
MSG_ERR_DDR_ERROR. Einige dieser Gründe sind:- Netzwerk- oder Verbindungsfehler
- Probleme mit dem Data Domain-Dateisystem
- Die Data Domain Appliance wird voll
- Ein abgelaufenes oder falsches DD Boost-Nutzerkennwort
- Es sind zu viele Prüfpunkte (Avamar) oder Snapshots (Data Domain) vorhanden. Dies ist in der Regel gekoppelt mit
hfscheckFehler, die nicht zulassen, dass alte Prüfpunkte und Snapshots "abgerollt" werden.
MSG_ERR_MISC oder MSG_ERR_TRYAGAINLATER
- Ab Avamar v.7 können Backups gleichzeitig mit der automatischen Speicherbereinigung ausgeführt werden.
- Gelegentlich kommt es zu einem Prozess namens "Index Stripe Splitting", wenn neue Daten aus Backups hinzugefügt werden.
- Da dieser Prozess der Index-Stripe-Aufteilung nicht ausgeführt werden kann, während die automatische Speicherbereinigung ausgeführt wird, wird einer der oben genannten Fehler gemeldet.
- Indexstripes in einem Raster werden in der Regel etwa im gleichen Zeitraum wie die anderen auf den verschiedenen Nodes aufgeteilt.
- Manchmal kann dies einige Tage dauern.
- Avamar funktioniert wie vorgesehen. Der Workaround besteht darin, während der GC keine Backups auszuführen.
MSG_ERR_BADTIMESYNC
- Dies ist ein seltenes Problem, das nur bei Rastern mit mehreren Nodes auftritt. Der Fehler tritt auf, wenn die Zeit zwischen einem oder mehreren Avamar-Daten-Nodes und dem Utility-Node nicht synchronisiert ist.
- Es ist wahrscheinlich, dass alle Wartungsaufgaben (GC, Prüfpunkt und
hfscheck)melden den gleichen Fehler.
Resolution
Ermitteln des aktuellsten Status der automatischen Speicherbereinigung:
Informationen über die neueste automatische Speicherbereinigung können über die CLI, AUI oder die Benutzeroberfläche des Management Console Server (MCS) angezeigt werden.
Über die CLI:

- Öffnen Sie eine SSH-Sitzung (z. B. PuTTY) auf dem Avamar Server und melden Sie sich als "admin" an. Führen Sie die folgenden Befehle aus:
status.dpn avmaint gcstatus
- Die folgenden Beispiele zeigen eine erfolgreiche Garbage Collection:
Last GC: finished Tue Jul 9 00:00:23 2024 after 00m 03s >> recovered 199.88 KB (OK) Last GC: finished Wed Jun 5 09:20:46 2024 after 00m 12s >> recovered 0.00 KB (OK)
- Wenn der Status als "OK" angezeigt wird, liegt ein potenzielles Problem mit der automatischen Speicherbereinigung vor:
Last GC: finished Mon Jun 17 09:02:41 2024 after 01m 51s >> recovered 14.98 MB (MSG_ERR_DDR_ERROR) Last GC: finished Thu Jun 13 07:06:54 2024 after 03m 41s >> recovered 0.00 KB (MSG_ERR_DISKFULL) Last GC: finished Mon Jun 10 19:04:58 2024 after 01m 01s >> recovered 0 KB (MSG_ERR_MISC) Last GC: finished Thu Jun 16:21:12 2024 after 00m 25s >> recovered 0 KB (MSG_ERR_BADTIMESYNC)
Aus der AUI:
- Überprüfen Sie den Status der letzten automatischen Speicherbereinigung. Wenn der Status als "OK" angezeigt wird, liegt ein potenzielles Problem mit der automatischen Speicherbereinigung vor.
Über die MCS-Benutzeroberfläche:
- Wenn die "letzte automatische Speicherbereinigung" ein rotes "x" aufweist, wie oben gezeigt, gibt es ein potenzielles Problem mit der automatischen Speicherbereinigung und es sind weitere Analysen erforderlich.
Wenn die automatische Speicherbereinigung aufgrund eines echten Problems weiterhin fehlschlägt (wie mit den oben beschriebenen Schritten validiert), wählen Sie die entsprechenden Optionen im Alert Response Form aus, um den Service-Request an einen Support-Mitarbeiter weiterzuleiten.
Additional Information
Bestätigen von Fehlern, sobald das Problem behoben wurde:
Über die CLI:
- Suchen Sie die unbestätigten Ereignisse wie folgt:
mccli event show --unack
- Bestätigen Sie entweder den einzelnen Code durch Eingabe der eindeutigen ID oder alle Fehlercodes:
mccli event show --id-

Aus der AUI:
- Melden Sie sich bei der AUI an und rufen Sie das Dashboard auf:
- Klicken Sie auf das Ausrufezeichen, und auf dem Bildschirm wird etwas ähnliches wie das Folgende angezeigt:
- Klicken Sie auf Unacknowledged events und der Bildschirm zeigt etwas ähnliches wie das Folgende an:
- Wählen Sie das Ereignis aus (wie oben gezeigt) und klicken Sie auf Acknowledge.
Ermitteln, wie lange der GC schon fehlschlägt:
Die einfachste Möglichkeit, zu bestimmen, wie lange GC fehlschlägt, ist die Verwendung der CLI (obwohl diese Informationen auch in der AUI- und MCS-Benutzeroberfläche verfügbar sind)
Der folgende Befehl zeigt alle Fehler bei der automatischen Speicherbereinigung der letzten 30 Tage an:
dumpmaintlogs --types=gc --days=30 |grep "failed garbage collection"
2024/05/27-16:32:18.55893 {0.0} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR
2024/05/28-16:32:37.92920 {0.0} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR
2024/05/29-16:31:51.62962 {0.0} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR
2024/05/30-16:31:55.18969 {0.0} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR
2024/06/20-01:19:09.97961 {0.0} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR
