Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Suche nach und Wiederherstellung möglicherweise verlorenen Objekten

01/03/2023 Beitragende

PDFs

Möglicherweise können Objekte gefunden und wiederhergestellt werden, die einen Alarm „Lost Objects“ (LOST Objects – LOST) und einen „Object Lost*“-Alarm ausgelöst haben und die Sie als „potentiell verloren“ identifiziert haben.

Was Sie benötigen

Sie müssen über die UUID eines verlorenen Objekts verfügen, wie in „Untersuchung verlorener Objekte“ angegeben.
Sie müssen die haben Passwords.txt Datei:

Über diese Aufgabe

Im Anschluss an dieses Verfahren können Sie sich nach replizierten Kopien des verlorenen Objekts an einer anderen Stelle im Grid suchen. In den meisten Fällen wird das verlorene Objekt nicht gefunden. In einigen Fällen können Sie jedoch ein verlorenes repliziertes Objekt finden und wiederherstellen, wenn Sie umgehend Maßnahmen ergreifen.

Wenden Sie sich an den technischen Support, wenn Sie Hilfe bei diesem Verfahren benötigen.

Schritte

Suchen Sie in einem Admin-Knoten die Prüfprotokolle nach möglichen Objektspeichern:
1. Melden Sie sich beim Grid-Node an:
  1. Geben Sie den folgenden Befehl ein: ssh admin@grid_node_IP
  2. Geben Sie das im aufgeführte Passwort ein Passwords.txt Datei:
  3. Geben Sie den folgenden Befehl ein, um zum Root zu wechseln: su -
  4. Geben Sie das im aufgeführte Passwort ein Passwords.txt Datei: Wenn Sie als root angemeldet sind, ändert sich die Eingabeaufforderung von $ Bis #.
2. Wechseln Sie in das Verzeichnis, in dem sich die Audit-Protokolle befinden: cd /var/local/audit/export/
3. Verwenden Sie grep, um die mit dem potenziell verlorenen Objekt verknüpften Audit-Nachrichten zu extrahieren und sie an eine Ausgabedatei zu senden. Geben Sie Ein: grep uuid-valueaudit_file_name > output_file_name
  
  Beispiel:
  Admin: # grep 926026C4-00A4-449B-AC72-BCCA72DD1311 audit.log > messages_about_lost_object.txt
4. Verwenden Sie grep, um die Meldungen zum Lost Location (LLST) aus dieser Ausgabedatei zu extrahieren. Geben Sie Ein: grep LLST output_file_name
  
  Beispiel:
  Admin: # grep LLST messages_about_lost_objects.txt
  Eine LLST-Überwachungsmeldung sieht wie diese Beispielmeldung aus.
  [AUDT:\[NOID$UI32$:12448208\][CBIL(UI64):0x38186FE53E3C49A5] [UUID(CSTR):"926026C4-00A4-449B-AC72-BCCA72DD1311"][LTYP(FC32):CLDI] [PCLD$CSTR$:"/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%\#3tN6"\] [TSRC(FC32):SYST][RSLT(FC32):NONE][AVER(UI32):10][ATIM(UI64): 1581535134379225][ATYP(FC32):LLST][ANID(UI32):12448208][AMID(FC32):CLSM] [ATID(UI64):7086871083190743409]]
5. Suchen Sie in der LLST-Meldung das Feld PCLD und das Feld NOID.
  
  Falls vorhanden, ist der Wert von PCLD der vollständige Pfad auf der Festplatte zur fehlenden replizierten Objektkopie. Der Wert von NOID ist die Knoten-id des LDR, wo eine Kopie des Objekts gefunden werden kann.
  
  Wenn Sie einen Speicherort für ein Objekt finden, kann das Objekt möglicherweise wiederhergestellt werden.
6. Suchen Sie den Speicherknoten für diese LDR-Knoten-ID.
  
  Es gibt zwei Möglichkeiten, die Node-ID zum Suchen des Storage Node zu verwenden:
  - Wählen Sie im Grid Manager die Option Support > Tools > Grid Topology aus. Wählen Sie dann Data Center > Storage Node > LDR aus. Die LDR-Knoten-ID befindet sich in der Node-Informationstabelle. Überprüfen Sie die Informationen für jeden Speicherknoten, bis Sie den gefunden haben, der dieses LDR hostet.
  - Laden Sie das Wiederherstellungspaket für das Grid herunter und entpacken Sie es. Das PAKET enthält ein Verzeichnis \docs. Wenn Sie die Datei index.html öffnen, zeigt die Serverübersicht alle Knoten-IDs für alle Grid-Knoten an.
Stellen Sie fest, ob das Objekt auf dem in der Meldung „Audit“ angegebenen Speicherknoten vorhanden ist:
1. Melden Sie sich beim Grid-Node an:
  1. Geben Sie den folgenden Befehl ein: ssh admin@grid_node_IP
  2. Geben Sie das im aufgeführte Passwort ein Passwords.txt Datei:
  3. Geben Sie den folgenden Befehl ein, um zum Root zu wechseln: su -
  4. Geben Sie das im aufgeführte Passwort ein Passwords.txt Datei:
    
    Wenn Sie als root angemeldet sind, ändert sich die Eingabeaufforderung von $ Bis #.
2. Stellen Sie fest, ob der Dateipfad für das Objekt vorhanden ist.
  
  Verwenden Sie für den Dateipfad des Objekts den Wert von PCLD aus der LLST-Überwachungsmeldung.
  
  Geben Sie beispielsweise Folgendes ein:
  ls '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6'
  Hinweis: Fügen Sie den Objektdateipfad immer in einzelne Anführungszeichen, um Sonderzeichen zu entkommen.
  - Wenn der Objektpfad nicht gefunden wurde, geht das Objekt verloren und kann mit diesem Verfahren nicht wiederhergestellt werden. Wenden Sie sich an den technischen Support.
  - Wenn der Objektpfad gefunden wurde, fahren Sie mit Schritt fort Stellen Sie das Objekt in StorageGRID wieder her. Sie können versuchen, das gefundene Objekt wieder in StorageGRID wiederherzustellen.

Wenn der Objektpfad gefunden wurde, versuchen Sie, das Objekt in StorageGRID wiederherzustellen:
1. Ändern Sie vom gleichen Speicherknoten aus die Eigentumsrechte an der Objektdatei, so dass sie von StorageGRID gemanagt werden kann. Geben Sie Ein: chown ldr-user:bycast 'file_path_of_object'
2. Telnet für localhost 1402 für den Zugriff auf die LDR-Konsole. Geben Sie Ein: telnet 0 1402
3. Geben Sie Ein: cd /proc/STOR
4. Geben Sie Ein: Object_Found 'file_path_of_object'
  
  Geben Sie beispielsweise Folgendes ein:
  Object_Found '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6'
  Ausstellen der Object\_Found Durch den Befehl wird das Raster des Speicherorts des Objekts benachrichtigt. Zudem wird die aktive ILM-Richtlinie ausgelöst, die zusätzliche Kopien gemäß den Angaben in der Richtlinie erstellt.
  
  Hinweis: Wenn der Speicherknoten, in dem Sie das Objekt gefunden haben, offline ist, können Sie das Objekt auf einen beliebigen Speicherknoten kopieren, der online ist. Platzieren Sie das Objekt in einem beliebigen /var/local/rangedb-Verzeichnis des Online-Storage-Node. Geben Sie dann den aus Object\_Found Befehl mit diesem Dateipfad zum Objekt.
  - Wenn das Objekt nicht wiederhergestellt werden kann, wird das angezeigt Object\_Found Befehl schlägt fehl. Wenden Sie sich an den technischen Support.
  - Wenn das Objekt erfolgreich in StorageGRID wiederhergestellt wurde, wird eine Erfolgsmeldung angezeigt. Beispiel:
    
    ade 12448208: /proc/STOR > Object_Found '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6' ade 12448208: /proc/STOR > Object found succeeded. First packet of file was valid. Extracted key: 38186FE53E3C49A5 Renamed '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6' to '/var/local/rangedb/1/p/17/11/00rH0%DkRt78Ila#3udu'
    
    Mit Schritt fortfahren Überprüfen Sie, ob neue Standorte erstellt wurden

Wenn das Objekt erfolgreich in StorageGRID wiederhergestellt wurde, vergewissern Sie sich, dass neue Speicherorte erstellt wurden.

Geben Sie Ein: cd /proc/OBRP
Geben Sie Ein: ObjectByUUID UUID_value

Das folgende Beispiel zeigt, dass es zwei Standorte für das Objekt mit UUID 926026C4-00A4-449B-AC72-BCCA72DD1311 gibt.

ade 12448208: /proc/OBRP > ObjectByUUID 926026C4-00A4-449B-AC72-BCCA72DD1311

{
    "TYPE(Object Type)": "Data object",
    "CHND(Content handle)": "926026C4-00A4-449B-AC72-BCCA72DD1311",
    "NAME": "cats",
    "CBID": "0x38186FE53E3C49A5",
    "PHND(Parent handle, UUID)": "221CABD0-4D9D-11EA-89C3-ACBB00BB82DD",
    "PPTH(Parent path)": "source",
    "META": {
        "BASE(Protocol metadata)": {
            "PAWS(S3 protocol version)": "2",
            "ACCT(S3 account ID)": "44084621669730638018",
            "*ctp(HTTP content MIME type)": "binary/octet-stream"
        },
        "BYCB(System metadata)": {
            "CSIZ(Plaintext object size)": "5242880",
            "SHSH(Supplementary Plaintext hash)": "MD5D 0xBAC2A2617C1DFF7E959A76731E6EAF5E",
            "BSIZ(Content block size)": "5252084",
            "CVER(Content block version)": "196612",
            "CTME(Object store begin timestamp)": "2020-02-12T19:16:10.983000",
            "MTME(Object store modified timestamp)": "2020-02-12T19:16:10.983000",
            "ITME": "1581534970983000"
        },
        "CMSM": {
            "LATM(Object last access time)": "2020-02-12T19:16:10.983000"
        },
        "AWS3": {
            "LOCC": "us-east-1"
        }
    },
    "CLCO\(Locations\)": \[
        \{
            "Location Type": "CLDI\(Location online\)",
            "NOID\(Node ID\)": "12448208",
            "VOLI\(Volume ID\)": "3222345473",
            "Object File Path": "/var/local/rangedb/1/p/17/11/00rH0%DkRt78Ila\#3udu",
            "LTIM\(Location timestamp\)": "2020-02-12T19:36:17.880569"
        \},
        \{
            "Location Type": "CLDI\(Location online\)",
            "NOID\(Node ID\)": "12288733",
            "VOLI\(Volume ID\)": "3222345984",
            "Object File Path": "/var/local/rangedb/0/p/19/11/00rH0%DkRt78Rrb\#3s;L",
            "LTIM\(Location timestamp\)": "2020-02-12T19:36:17.934425"
        }
    ]
}

Melden Sie sich von der LDR-Konsole ab. Geben Sie Ein: exit

Durchsuchen Sie von einem Admin-Node aus die Prüfprotokolle für die ORLM-Überwachungsmeldung für dieses Objekt, um zu bestätigen, dass Information Lifecycle Management (ILM) Kopien nach Bedarf platziert hat.
1. Melden Sie sich beim Grid-Node an:
  1. Geben Sie den folgenden Befehl ein: ssh admin@grid_node_IP
  2. Geben Sie das im aufgeführte Passwort ein Passwords.txt Datei:
  3. Geben Sie den folgenden Befehl ein, um zum Root zu wechseln: su -
  4. Geben Sie das im aufgeführte Passwort ein Passwords.txt Datei: Wenn Sie als root angemeldet sind, ändert sich die Eingabeaufforderung von $ Bis #.
2. Wechseln Sie in das Verzeichnis, in dem sich die Audit-Protokolle befinden: cd /var/local/audit/export/
3. Verwenden Sie grep, um die mit dem Objekt verknüpften Überwachungsmeldungen in eine Ausgabedatei zu extrahieren. Geben Sie Ein: grep uuid-valueaudit_file_name > output_file_name
  
  Beispiel:
  Admin: # grep 926026C4-00A4-449B-AC72-BCCA72DD1311 audit.log > messages_about_restored_object.txt
4. Verwenden Sie grep, um die ORLM-Audit-Meldungen (Object Rules met) aus dieser Ausgabedatei zu extrahieren. Geben Sie Ein: grep ORLM output_file_name
  
  Beispiel:
  Admin: # grep ORLM messages_about_restored_object.txt
  Eine ORLM-Überwachungsmeldung sieht wie diese Beispielmeldung aus.
```
[AUDT:[CBID(UI64):0x38186FE53E3C49A5][RULE(CSTR):"Make 2 Copies"]
[STAT(FC32):DONE][CSIZ(UI64):0][UUID(CSTR):"926026C4-00A4-449B-AC72-BCCA72DD1311"]
[LOCS(CSTR):"**CLDI 12828634 2148730112**, CLDI 12745543 2147552014"]
[RSLT(FC32):SUCS][AVER(UI32):10][ATYP(FC32):ORLM][ATIM(UI64):1563398230669]
[ATID(UI64):15494889725796157557][ANID(UI32):13100453][AMID(FC32):BCMS]]
```
1. Suchen Sie das FELD LOKS in der Überwachungsmeldung.
  
  Wenn vorhanden, ist der Wert von CLDI in LOCS die Node-ID und die Volume-ID, in der eine Objektkopie erstellt wurde. Diese Meldung zeigt, dass das ILM angewendet wurde und dass an zwei Standorten im Grid zwei Objektkopien erstellt wurden.
2. Setzen Sie die Anzahl der verlorenen Objekte im Grid Manager zurück.

Verwandte Informationen

"Untersuchung verlorener Objekte"

"Bestätigen der Speicherorte von Objektdaten"

"Zurücksetzen verlorener und fehlender Objektanzahl"

"Prüfung von Audit-Protokollen"

Suche nach und Wiederherstellung möglicherweise verlorenen Objekten

Creating your file...