Data Domain: Lösen von Problemen mit hoher Speicherplatzauslastung oder mangelnder verfügbarer Kapazität auf Data Domain Restorern (DDRs)

 

• Dies ist der Bereich der Festplatte, in dem sich neu eingelesene Dateien/Daten befinden, und bei den meisten DDRs verbleiben die Dateien hier, bis sie durch eine Client-Backupanwendung abgelaufen/gelöscht werden
• Auf DDRs, die mit Extended Retention (ER) oder Long Term Retention (LTR) konfiguriert sind, kann der Datenverschiebungsprozess periodisch ausgeführt werden, um alte Dateien von der aktiven Stufe in die Archiv- oder Cloud-Stufen zu migrieren
• Die einzige Möglichkeit, Speicherplatz in der aktiven Stufe zurückzugewinnen, der von gelöschten/verschobenen Dateien belegt wurde, ist die Ausführung des Prozesses Clean/Automatische Speicherbereinigung

• Der aktiven Stufe steht möglicherweise nicht mehr genügend Speicherplatz zur Verfügung, sodass Warnmeldungen/Meldungen wie die folgende angezeigt werden:

• Wenn die aktive Stufe zu 100 % voll ist, können keine neuen Daten in den DDR geschrieben werden, was dazu führen kann, dass Backups/Replikationen fehlschlagen. In diesem Szenario werden Warnmeldungen/Meldungen wie die folgende angezeigt:

• Wenn die aktive Stufe voll ist, kann dies unter Umständen dazu führen, dass das Data Domain File System (DDFS) schreibgeschützt wird, so dass vorhandene Dateien nicht gelöscht werden können.

• zu erklären, warum die aktive Stufe voll werden kann
• eine Reihe einfacher Prüfungen zu beschreiben, die durchgeführt werden können, um die Ursache für eine hohe Auslastung der aktiven Stufe und entsprechende Abhilfemaßnahmen zu ermitteln

• Dieser Artikel ist nicht erschöpfend (d. h. es kann eine kleine Anzahl von Situationen geben, in denen die aktive Stufe eines DDR aus einem Grund stark ausgelastet/voll ist, der in diesem Dokument nicht behandelt wird)
• Dieser Artikel deckt keine hohe Auslastung von Archiv- oder Cloud-Stufen ab

  Die aktive Stufe eines DDR kann aus verschiedenen Gründen stärker als erwartet ausgelastet sein:

• Backupdateien/Sicherungssätze werden von Client-Backupanwendungen aufgrund falscher Aufbewahrungsrichtlinien oder einer falschen Konfiguration der Backupanwendung nicht korrekt abgelaufen/gelöscht
• Replikationsverzögerung, die dazu führt, dass eine große Menge alter Daten auf der aktiven Stufe gehalten wird, während die Replikation auf die Replikate noch aussteht
• Daten, die auf die aktive Stufe geschrieben werden, haben eine geringere Gesamtkomprimierungsrate als erwartet
• Das System wurde nicht richtig dimensioniert, d. h. es ist einfach zu klein für die Datenmenge, die darauf gespeichert werden soll
• Backups bestehen aus einer großen Anzahl sehr kleiner Dateien. Diese Dateien verbrauchen viel mehr Speicherplatz als erwartet, wenn sie ursprünglich geschrieben werden; dieser Speicherplatz sollte jedoch mit Clean/automatische Speicherbereinigung zurückgewonnen werden
• Die Datenverschiebung wird auf Systemen, die mit ER/LTR konfiguriert sind, nicht regelmäßig ausgeführt, wodurch alte Dateien, die in die Archiv-/Cloud-Stufen migriert werden sollten, auf der aktiven Stufe verbleiben
• Clean/Automatische Speicherbereinigung wird nicht regelmäßig durchgeführt
• Zu viele oder alte Mtree-Snapshots auf dem DDR verhindern, dass bei einem Clean-Vorgang Platz von gelöschten Dateien/Daten zurückgewonnen wird

Schritt 1: Bestimmen, ob ein Clean der aktiven Stufe ausgeführt werden muss

Das Data Domain-Betriebssystem (DDOS) versucht, einen Zähler mit dem Namen "Cleanable gib" für die aktive Stufe aufrechtzuerhalten. Hierbei handelt es sich um eine Schätzung der Menge des physischen Speicherplatzes (post-comp), der potenziell auf der aktiven Stufe durch Ausführen von Clean/automatischen Speicherbereinigung zurückgewonnen werden kann. Dieser Zähler wird durch die Befehle 'filesys show space'/'df' angezeigt:
 
Wenn eines der Folgenden gilt:

• Der Wert für 'Cleanable GiB' ist groß.
• DDFS ist zu 100 % voll (und daher schreibgeschützt)

Clean sollte durchgeführt werden, bevor Sie mit weiteren Schritten in diesem Dokument fortfahren können. Zum Starten von Clean muss der Befehl 'filesys clean start' verwendet werden, d. h.:
 
Um zu bestätigen, dass Clean wie erwartet gestartet wurde, kann der Befehl 'filesys status' verwendet werden, d. h.:
 
Hinweis:

• Wenn Clean nicht gestartet werden kann, wenden Sie sich an ihren vertraglich festgelegten Supportanbieter, um weitere Unterstützung zu erhalten. Dies kann darauf hinweisen, dass im System ein 'missing segment error' aufgetreten ist, der eine Deaktivierung von Clean verursacht
• Wenn Clean bereits ausgeführt wird, wird die folgende Meldung angezeigt, wenn versucht wird, den Vorgang zu starten:

• Es wird kein Speicherplatz in der aktiven Stufe freigegeben/zurückgewonnen, bis die Kopie-Phase im Clean-Vorgang erreicht ist (standardmäßig Phase 9 in DDOS 5.4.x und früher, Phase 11 in DDOS 5.5.x und höher). Weitere Informationen zu den von Clean verwendeten Phasen finden Sie unter: https://support.emc.com/kb/446734
• Clean kann die Menge an Speicherplatz, der durch 'Cleanable GiB' angezeigt wird, nicht zurückgewinnen, da dieser Wert im Wesentlichen eine Schätzung ist. Weitere Informationen zu diesem Thema finden Sie unter: https://support.emc.com/kb/485637
• Clean kann möglicherweise nicht den gesamten potenziellen Speicherplatz in einem einzigen Durchlauf zurückgewinnen. Dies liegt daran, dass Clean auf DDRs mit sehr großen Datensätzen den Teil des Dateisystems bearbeitet, der die meisten überflüssigen Daten enthält (d. h. um den besten Ertrag an freiem Speicherplatz für die Zeit zu erzielen, die für den Clean-Durchgang benötigt wird). In einigen Szenarien muss Clean unter Umständen mehrmals ausgeführt werden, bevor der gesamte potenzielle Speicherplatz zurückgewonnen ist
• Wenn der Wert für 'Cleanable GiB' sehr groß war, kann dies darauf hindeuten, dass Clean nicht in regelmäßigen Abständen ausgeführt wurde. Überprüfen Sie, ob ein Zeitplan für Clean festgelegt wurde:

Wenn der Clean-Vorgang abgeschlossen ist, verwenden Sie die Befehle 'filesys show space'/'df', um festzustellen, ob die Nutzungsprobleme behoben wurden. Wenn die Auslastung weiterhin hoch ist, fahren Sie mit den verbleibenden Schritten in diesem Artikel fort.

Schritt 2: Auf große Mengen an Replikationsverzögerung gegen Quellreplikationskontexte prüfen

Das Design der nativen Data Domain-Replikation basiert auf dem Konzept der 'Replikationskontexte'. Zum Beispiel, wenn Daten zwischen Systemen repliziert werden müssen:

• Replikationskontexte werden auf Quell- und Ziel-DDRs erstellt.
• Die Kontexte werden initialisiert.
• Nach Abschluss der Initialisierung sendet die Replikation periodisch Aktualisierungen/Deltas von der Quelle zum Ziel, um die Daten auf den Systemen synchron zu halten.

Wenn ein Quell-Replikationskontext verzögert wird, kann dies dazu führen, dass alte Daten auf der Festplatte des Quellsystems gehalten werden (beachten Sie, dass verzögerte Replikationskontexte keine übermäßige Auslastung auf dem Zielsystem verursachen können):

• Verzeichnisreplikationskontexte (werden verwendet, wenn ein einzelner Verzeichnisbaum unter /data/col1/backup zwischen Systemen repliziert wird):

•  Mtree-Replikationskontexte (werden verwendet, wenn ein anderer Mtree als /data/col1/backup zwischen Systemen repliziert wird):

• Erfassungsreplikationskontexte (werden verwendet, wenn der gesamte Inhalt eines DDR auf ein anderes System repliziert wird):

 Um festzustellen, ob die Replikationskontexte verzögert werden, sollten folgende Schritte durchgeführt werden:

• Ermitteln Sie den Hostnamen des aktuellen Systems:

• Bestimmen Sie das Datum/die Uhrzeit auf dem aktuellen System:

• Listen Sie die auf dem System konfigurierten Replikationskontexte zusammen mit ihrer 'synced as of time' auf. Beachten Sie, dass es sich um Kontexte handelt, in denen das 'Ziel' nicht den Hostnamen des aktuellen Systems enthält (was darauf hinweist, dass das aktuelle System die Quelle ist) und die 'synced as of time' erheblich alt ist:

Kontexte, für die das aktuelle System die Quelle ist und die erhebliche Verzögerungen oder Kontexte anzeigen, die nicht mehr benötigt werden, sollten unterbrochen werden. Dies kann durch Ausführen des folgenden Befehls auf dem Quell- und Zielsystem durchgeführt werden:
 
Um beispielsweise die oben gezeigten 'interesting' Kontexte aufzuheben, werden die folgenden Befehle auf Quelle und Ziel ausgeführt:
 
Hinweis:

• Sobald Kontexte unterbrochen sind, muss ein Clean der aktiven Stufe durchgeführt werden, um potenziellen Speicherplatz in der aktiven Stufe zurückzugewinnen.
• Bei Verwendung der Mtree-Replikation können nach dem Unterbrechen der Kontexte Mtree-Replikations-Snapshots auf der Festplatte verbleiben. Stellen Sie sicher, dass Schritt 5 befolgt wird, um alle überflüssigen Snapshots vor der Ausführung von Clean zu löschen.
• Wenn der Quell-/Ziel-Mtree so konfiguriert ist, dass Daten in Archiv- oder Cloud-Stufen migriert werden, ist Vorsicht geboten, wenn entsprechende Mtree-Replikationskontexte unterbrochen werden, da diese Kontexte in Zukunft möglicherweise nicht mehr neu erstellt/initialisiert werden können. Der Grund dafür ist, dass bei der Initialisierung eines Mtree-Replikationskontexts ein Mtree-Snapshot auf dem Quellsystem erstellt wird, der Details zu allen Dateien im Mtree enthält (unabhängig von der Stufe). Dieser Snapshot wird dann vollständig auf die aktive Stufe des Ziels repliziert. Wenn die aktive Stufe des Ziels nicht über genügend freien Speicherplatz verfügt, um alle Mtree-Daten von der Quelle zu übernehmen, kann die Initialisierung nicht abgeschlossen werden. Für weitere Informationen zu diesem Problem wenden Sie sich bitte an Ihren vertraglich gebundenen Supportanbieter
• Wenn ein Erfassungsreplikationskontext unterbrochen wird, kann der Kontext nicht neu erstellt/initialisiert werden, ohne dass zuerst die Instanz von DDFS auf dem Ziel-DDR zerstört wird (und alle Daten auf diesem System verloren gehen). Infolgedessen kann eine anschließende Initialisierung erhebliche Zeit/Netzwerkbandbreite in Anspruch nehmen, da alle Daten von der Quelle erneut physisch zum Ziel repliziert werden müssen

Schritt 3: Prüfen auf nicht mehr benötigte Mtrees

Der Inhalt von DDFS ist logisch in Mtrees unterteilt. Es ist üblich, dass einzelne Backupanwendungen/Clients in einzelne Mtrees schreiben. Wenn eine Backupanwendung außer Betrieb genommen wird, kann sie keine Daten mehr in den DDR schreiben bzw. aus diesem löschen, wodurch alte/überflüssige Mtrees auf dem System verbleiben können. Die Daten in diesen Mtrees bleiben auf unbestimmte Zeit bestehen und belegen Speicherplatz auf der Festplatte des DDR. Folglich sollten solche überflüssigen Mtrees gelöscht werden. Zum Beispiel:

• Besorgen Sie sich eine Liste der Mtrees auf dem System:

• Alle Mtrees, die nicht mehr benötigt werden, sollten mit dem Befehl 'mtree delete' gelöscht werden, d. h.:

• Speicherplatz, der vom gelöschten Mtree auf der Festplatte verbraucht wird, wird bei der nächsten Ausführung von Clean/Automatische Speicherbereinigung auf der aktiven Stufe zurückgewonnen.

Hinweis:

• Bei Mtrees, die Ziele für die Mtree-Replikation sind (d. h. in der Ausgabe von 'mtree list' den Status RO/RD haben), sollte der entsprechende Replikationskontext unterbrochen werden, bevor der Mtree gelöscht wird
• Mtrees, die als logische DDBoost-Speichereinheiten (LSUs) oder als Pools für virtuelle Bandbibliotheken (VTLs) verwendet werden, können möglicherweise nicht über den Befehl 'mtree delete' gelöscht werden. Weitere Einzelheiten zum Löschen solcher Mtrees finden Sie im Data Domain-Administrationshandbuch
• Mtrees, für die eine Aufbewahrungssperre konfiguriert ist (d. h. einen Status von RLCE oder RLGE haben), können nicht gelöscht werden. Stattdessen müssen einzelne Dateien innerhalb des Mtree die Aufbewahrungssperre aufheben und einzeln gelöscht werden. Weitere Einzelheiten finden Sie im Data Domain-Administrationshandbuch

Schritt 4: Überprüfen auf alte/überflüssige Mtree-Snapshots

Ein Data Domain-Snapshot stellt einen Point-in-Time-Snapshot des entsprechenden Mtree dar. Daraus folgt:

• Alle Dateien, die zum Zeitpunkt der Erstellung des Snapshots im Mtree vorhanden sind, werden vom Snapshot referenziert
• Obwohl der Snapshot weiterhin vorhanden ist, selbst wenn diese Dateien entfernt/gelöscht werden, kann Clean keinen physischen Speicherplatz zurückgewinnen, den sie auf der Festplatte belegen. Dies liegt daran, dass die Daten auf dem System bleiben müssen, falls später auf die Kopie der Datei im Snapshot zugegriffen wird.

Um festzustellen, ob irgendwelche Mtrees alte/überflüssige Snapshots haben, sollten die folgenden Schritte durchgeführt werden:

• Ermitteln Sie eine Liste der Mtrees auf dem System mit dem Befehl 'mtree list', wie in Schritt 3 gezeigt
• Listen Sie mit dem Befehl 'snapshot list' die Snapshots auf, die für jeden Mtree existieren:

• Wenn Snapshots vorhanden sind, verwenden Sie die Ausgabe von 'snapshot list mtree [mtree name]', um Snapshots zu bestimmen, die:

• Wenn der Befehl 'snapshot list' erneut ausgeführt wird, werden diese Snapshots jetzt als 'expired' aufgeführt:

Hinweis:

• Es ist nicht möglich, festzustellen, wie viele physische Daten ein einzelner Snapshot oder ein Satz von Snapshots auf der Festplatte enthält. Der einzige Wert für 'space', der einem Snapshot zugeordnet ist, ist ein Hinweis auf die vorkomprimierte (logische) Größe des Mtree, als der Snapshot erstellt wurde (wie in der obigen Ausgabe gezeigt)
• Snapshots mit dem Namen 'REPL-MTREE-AUTO-YYYY-MM-DD-HH-MM-SS' werden von der Mtree-Replikation verwaltet und sollten unter normalen Umständen nicht manuell gelöscht werden müssen (die Replikation löscht diese Snapshots automatisch, wenn sie nicht mehr benötigt werden). Wenn solche Snapshots sehr alt sind, deutet dies darauf hin, dass der entsprechende Replikationskontext wahrscheinlich eine erhebliche Verzögerung aufweist (wie in Schritt 2 beschrieben)
• Snapshots mit dem Namen 'REPL-MTREE-RESYNC-RESERVE-YYYY-MM-DD-HH-MM-SS' werden von der Mtree-Replikation erstellt, wenn ein Mtree-Replikationskontext defekt ist. Sie dienen dazu, eine vollständige Neusynchronisierung der Replikationsdaten zu vermeiden, wenn der defekte Kontext später wiederhergestellt wird (z. B. wenn der Kontext irrtümlich unterbrochen wurde). Wenn die Replikation nicht wiederhergestellt wird, können diese Kontexte wie oben beschrieben manuell abgelaufen werden
• Abgelaufene Snapshots bleiben bis zur nächsten Ausführung von Clean/automatische Speicherbereinigung auf dem System erhalten. Zu diesem Zeitpunkt werden sie physisch gelöscht und aus der Ausgabe von 'snapshot list mtree [Mtree-Name]' entfernt - Clean kann dann den von diesen Snapshots belegten Speicherplatz auf der Festplatte zurückgewinnen

Schritt 5:Prüfen auf eine unerwartete Anzahl alter Dateien im System

Autosupports vom DDR enthalten Histogramme, die eine Aufschlüsselung der Dateien auf dem DDR nach Alter anzeigen, z. B.:
 
Dies kann nützlich sein, um festzustellen, ob es Dateien auf dem System gibt, die nicht wie erwartet von der Client-Backupanwendung abgelaufen/gelöscht wurden. Wenn z. B. von einer Backupanwendung, bei der die maximale Aufbewahrungszeit für eine Datei 6 Monate beträgt, in das obige System geschrieben wird, ist sofort ersichtlich, dass die Backupanwendung Dateien nicht wie erwartet abläuft/löscht, da sich ca. 80.000 Dateien, die älter als 6 Monate sind, auf dem DDR befinden.

Hinweis:

• Es liegt in der Verantwortung der Backupanwendung, alle Dateien zu löschen bzw. ablaufen zu lassen
• Ein DDR wird Dateien nie automatisch ablaufen/löschen. Wenn die Backupanwendung nicht explizit zum Löschen einer Datei aufgefordert wird, bleibt die Datei auf dem DDR-Speicher bestehen und belegt auf unbestimmte Dauer Platz

Daher sollten Probleme wie dieses zunächst vom Support-Team des Herstellers der Backupanwendung untersucht werden.

Bei Bedarf kann der erforderliche Data Domain-Support zusätzliche Berichte bereitstellen, die:

• den Namen/die Änderungszeit aller Dateien in einem DDR nach Alter sortiert angeben (sodass der Name/Speicherort der alten Daten ermittelt werden kann)
• Histogramme des Dateialters in separate Berichte für die aktive/Archivierungs-/Cloud-Stufe aufteilen (wobei die ER/LTR-Funktionen aktiviert sind)

Gehen Sie folgendermaßen vor:

• Sammeln Sie Beweise wie im Abschnitt "Sammeln von sfs_dump" im Abschnitt "Hinweise" in diesem Dokument beschrieben
• Eröffnen Sie einen Service-Request bei Ihrem vertraglich gebundenen Supportanbieter

Nach dem Löschen alter/überflüssiger Dateien muss Clean/automatische Speicherbereinigung für die aktiven Stufe durchgeführt werden, um physischen Speicherplatz auf der aktiven Stufe zurückzugewinnen

Schritt 6 - Prüfen auf Backups, die eine große Anzahl kleiner Dateien enthalten

Aufgrund des Designs von DDFS können kleine Dateien (im Wesentlichen alle Dateien, die kleiner als ca. 10 MB sind) übermäßig viel Speicherplatz verbrauchen, wenn sie anfänglich in den DDR geschrieben werden. Dies liegt an der "SISL"-Architektur (Stream Informed Segment Layout), die bewirkt, dass kleine Dateien mehrere einzelne 4,5-MB-Blöcke auf der Festplatte belegen. Beispielsweise kann eine 4 KB große Datei beim ersten Schreiben bis zu 9 MB physischen Speicherplatz verbrauchen.

Dieser übermäßige Speicherplatz wird später beim Ausführen von Clean/automatische Speicherbereinigung zurückgewonnen (da die Daten von kleinen Dateien dann in einer kleineren Anzahl von 4,5-MB-Blöcken zusammengefasst werden), kann aber dazu führen, dass kleinere Modelle von DDR eine übermäßige Auslastung aufweisen und sich füllen, wenn solche Backups ausgeführt werden.

Autosupports enthalten Histogramme von Dateien, aufgeschlüsselt nach Größe, z. B.:
 
Wenn es Anzeichen dafür gibt, dass Backups eine sehr große Anzahl kleiner Dateien schreiben, kann das System zwischen jedem Aufruf von Clean/automatische Speicherbereinigung durch eine erhebliche vorübergehende Erhöhung der Auslastung beeinträchtigt werden. In diesem Fall ist es besser, die Backupmethode so zu ändern, dass alle kleinen Dateien in ein einziges größeres Archiv (z. B. eine tar-Datei) aufgenommen werden, bevor sie auf den DDR geschrieben werden. Beachten Sie, dass ein solches Archiv nicht komprimiert oder verschlüsselt werden sollte (da dies die Komprimierungs-/Deduplizierungsrate dieser Daten beeinträchtigt).

Schritt 7: Überprüfen, ob die Deduplizierungsrate niedriger als erwartet ist

Der Hauptzweck eines DDR ist die Deduplizierung und Komprimierung der vom Gerät aufgenommenen Daten. Das Deduplizierungs-/Komprimierungsverhältnis hängt stark vom Anwendungsfall des Systems und der Art der darin enthaltenen Daten ab. In vielen Fällen gibt es jedoch ein "erwartetes" Gesamtkomprimierungsverhältnis, das auf den Ergebnissen von Proof-of-Concept-Tests oder Ähnlichem basiert. Um die aktuelle Gesamtkomprimierungsrate des Systems zu ermitteln (und damit, ob sie den Erwartungen entspricht), kann der Befehl 'filesys show compression' verwendet werden. Zum Beispiel:
 
Im obigen Beispiel erreicht das System ein Gesamtkomprimierungsverhältnis von 65,3x für die aktive Stufe (was sehr gut ist). Wenn dieser Wert hingegen zeigt, dass das allgemeine Komprimierungsverhältnis die Erwartungen nicht erfüllt, sind wahrscheinlich weitere Ermittlungen erforderlich. Beachten Sie, dass die Untersuchung einer niedrigeren Komprimierungsrate als erwartet ein komplexes Thema ist, das viele Ursachen haben kann. Weitere Informationen zur weiteren Untersuchung finden Sie im folgenden Artikel: https://support.emc.com/kb/487055

Schritt 8: Überprüfen, ob das System eine Quelle für die Erfassungsreplikation ist

Wenn bei der Erfassungsreplikation das Quellsystem physisch größer als das Ziel ist, wird die Größe des Quellsystems künstlich begrenzt, um der des Ziels zu entsprechen (d. h. es gibt einen Bereich auf der Festplatte der Quelle, der als unbrauchbar markiert wird). Der Grund dafür ist, dass bei der Erfassungsreplikation das Ziel eine Blockebenen-Kopie der Quelle sein muss. Wenn die Quelle jedoch physisch größer als das Ziel ist, besteht die Möglichkeit, dass zu viele Daten auf die Quelle geschrieben werden, die dann nicht auf das Ziel repliziert werden können (da es bereits voll ist). Dieses Szenario lässt sich vermeiden, indem die Größe der Quelle auf die des Ziels begrenzt wird.

• Überprüfen Sie mithilfe der Befehle aus Schritt 2, ob das System eine Quelle für die Erfassungsreplikation ist. Führen Sie dazu 'replication status' aus und ermitteln Sie, ob es Replikationskontexte gibt, die mit 'col://' beginnen (was auf Erfassungsreplikation hinweist), die NICHT den Hostnamen des lokalen Systems im Ziel enthalten (was bedeutet, dass dieses System eine Quelle für den Replikationskontext sein muss)
• Wenn das System eine Quelle für die Erfassungsreplikation ist, prüfen Sie die Größe der aktiven Stufe jedes Systems, indem Sie sich bei beiden anmelden und den Befehl 'filesys show space' ausführen. Vergleichen Sie die Größe 'post-comp' der aktiven Stufe auf allen
• Wenn die Quelle deutlich größer als das Ziel ist, wird die Größe der aktiven Stufe künstlich eingeschränkt.
• Damit der gesamte Speicherplatz auf der Quelle für Daten genutzt werden kann, sollte Folgendes durchgeführt werden:

Schritt 9: Überprüfen, ob die Datenverschiebung regelmäßig ausgeführt wird

Wenn der DDR entweder mit Extended Retention (ER) oder Long Term Retention (LTR) konfiguriert ist, wird eine zweite Stufe von Speicher angehängt (Archiv-Stufe für ER oder Cloud-Stufe für LTR). In diesem Szenario werden Datenverschiebungsrichtlinien wahrscheinlich für Mtrees konfiguriert, um ältere/unveränderte Daten, die eine langfristige Aufbewahrung erfordern, aus der aktiven Stufe in die alternative Speicherstufe zu migrieren, damit der von diesen Dateien in der aktiven Stufe belegte Speicherplatz durch Clean/automatische Speicherbereinigung physisch zurückgewonnen werden kann. Wenn die Datenverschiebungsrichtlinien falsch konfiguriert sind oder der Datenverschiebungsprozess nicht regelmäßig ausgeführt wird, verbleiben alte Daten länger als erwartet in der aktiven Stufe und verbrauchen weiterhin physischen Speicherplatz auf der Festplatte.

• Überprüfen Sie zunächst, ob das System für ER oder LTR konfiguriert ist, indem Sie 'filesys show space' ausführen und auf das Vorhandensein einer Archiv- oder Cloud-Stufe prüfen. Beachten Sie, dass diese alternativen Speicherstufen eine Post-Comp-Größe von > 0 GB haben müssen, um nutzbar zu sein:

• Wenn das System mit ER/LTR konfiguriert ist, überprüfen Sie die Datenverschiebungsrichtlinien anhand der Mtrees, um sicherzustellen, dass diese wie erwartet sind und so eingestellt sind, dass alte Daten auf die alternative Speicherstufe verschoben werden:

• Wenn das System mit ER/LTR konfiguriert ist, prüfen Sie, ob die Datenverschiebung so geplant ist, dass sie in regelmäßigen Abständen ausgeführt wird, um Dateien/Daten physisch von der aktiven Stufe in den alternativen Speicher zu migrieren:

• Wenn das System für ER/LTR überprüfen Sie den Zeitpunkt der letzten Ausführung der Datenverschiebung:

• Sobald die Datenverschiebung abgeschlossen ist, sollte 'active tier clean' ausgeführt werden (möglicherweise ist dieser Befehl so konfiguriert, dass er nach Abschluss der Datenverschiebung automatisch startet), um sicherzustellen, dass der von den migrierten Dateien belegte Speicherplatz in der aktiven Stufe physisch freigegeben wird:

Schritt 10: Zusätzlichen Speicher zur aktiven Stufe hinzufügen

Wenn alle vorherigen Schritte durchgeführt wurden, die aktive Stufe bis zum Abschluss bereinigt wurde, jedoch immer noch nicht genügend Speicherplatz auf der aktiven Stufe verfügbar ist, wurde das System wahrscheinlich nicht richtig für die Arbeitslast ausgelegt, die es erhält. In diesem Fall sollte eine der folgenden Maßnahmen durchgeführt werden:

• Reduzieren Sie die Arbeitslast, die das System bewältigen muss. Zum Beispiel:

• Fügen Sie der aktiven Stufe des Systems zusätzlichen Speicher hinzu und erweitern Sie seine Größe:

Der Data Domain-Support kann eine Reihe von Berichten erzeugen, die folgende Informationen enthalten:

• Eine Liste aller Dateien auf einer bestimmten Stufe (d. h. aktiv/Archiv/Cloud), sortiert nach Alter
• Geschätzte Größe und Komprimierungsverhältnis nach mtree/major-Verzeichnisstruktur
• Eine Liste aller Dateien in einem bestimmten Mtree, sortiert nach Alter
• und so weiter

Um dies zu ermöglichen, sollten die folgenden Informationen erfasst werden:

• Ein neues Support-Paket vom DDR. Weitere Informationen finden Sie unter: https://support.EMC.com/kb/323283
• Die Ausgabe von "sfs_dump" oder "sfs_dump-c":

• Ein Bericht zum Speicherort der Datei (erforderlich, wenn das System für ER oder LTR konfiguriert ist):

Wenden Sie sich an ihren vertraglich festgelegten Supportanbieter, um Unterstützung bei der Erfassung der oben genannten Angaben oder einem der Schritte in diesem Archiv zu erhalten.