La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Recherche et restauration d'objets potentiellement perdus

12/06/2022 Contributeurs

Il est possible de trouver et de restaurer des objets qui ont déclenché une alarme objets perdus (PERDUS) et une alerte objet perdu et que vous avez identifié comme potentiellement perdus.

Ce dont vous avez besoin

Vous devez avoir l'UUID de tout objet perdu, tel qu'il est identifié dans « enquête sur les objets perdus ».
Vous devez avoir le Passwords.txt fichier.

Description de la tâche

Vous pouvez suivre cette procédure pour rechercher les copies répliquées de l'objet perdu ailleurs dans la grille. Dans la plupart des cas, l'objet perdu est introuvable. Toutefois, dans certains cas, vous pouvez trouver et restaurer un objet répliqué perdu si vous prenez une action rapide.

Pour obtenir de l'aide sur cette procédure, contactez le support technique.

Étapes

À partir d'un nœud d'administration, recherchez dans les journaux d'audit les emplacements d'objets possibles :
1. Connectez-vous au nœud grid :
  1. Saisissez la commande suivante : ssh admin@grid_node_IP
  2. Entrez le mot de passe indiqué dans le Passwords.txt fichier.
  3. Entrez la commande suivante pour passer à la racine : su -
  4. Entrez le mot de passe indiqué dans le Passwords.txt fichier. Lorsque vous êtes connecté en tant que root, l'invite passe de $ à #.
2. Accédez au répertoire dans lequel se trouvent les journaux d'audit : cd /var/local/audit/export/
3. Utilisez grep pour extraire les messages d'audit associés à l'objet potentiellement perdu et les envoyer vers un fichier de sortie. Entrez : grep uuid-valueaudit_file_name > output_file_name
  
  Par exemple :
  Admin: # grep 926026C4-00A4-449B-AC72-BCCA72DD1311 audit.log > messages_about_lost_object.txt
4. Utilisez grep pour extraire les messages d'audit emplacement perdu (LLST) de ce fichier de sortie. Entrez : grep LLST output_file_name
  
  Par exemple :
  Admin: # grep LLST messages_about_lost_objects.txt
  Un message d'audit LLST ressemble à cet exemple de message.
  [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. Recherchez le champ PCLD et LE champ NOID dans le message LLST.
  
  Le cas échéant, la valeur de PCLD correspond au chemin complet du disque vers la copie de l'objet répliqué manquante. La valeur de NOID est l'ID de nœud du LDR dans lequel une copie de l'objet peut être trouvée.
  
  Si vous trouvez un emplacement d'objet, vous pourrez peut-être restaurer l'objet.
6. Recherchez le nœud de stockage pour cet ID de nœud LDR.
  
  Il existe deux façons d'utiliser l'ID de nœud pour trouver le nœud de stockage :
  - Dans le Gestionnaire de grille, sélectionnez SUPPORT Outils topologie de grille. Sélectionnez ensuite Data Center Storage Node LDR. L'ID de nœud LDR se trouve dans le tableau Node information. Vérifiez les informations pour chaque nœud de stockage jusqu'à ce que vous trouviez celui qui héberge ce LDR.
  - Téléchargez et décompressez le pack de récupération pour la grille. Il y a un répertoire \docs dans LEDIT package. Si vous ouvrez le fichier index.html, le récapitulatif des serveurs affiche tous les ID de nœud de tous les nœuds de la grille.
Déterminez si l'objet existe sur le nœud de stockage indiqué dans le message d'audit :
1. Connectez-vous au nœud grid :
  1. Saisissez la commande suivante : ssh admin@grid_node_IP
  2. Entrez le mot de passe indiqué dans le Passwords.txt fichier.
  3. Entrez la commande suivante pour passer à la racine : su -
  4. Entrez le mot de passe indiqué dans le Passwords.txt fichier.

Lorsque vous êtes connecté en tant que root, l'invite passe de $ à #.

Déterminez si le chemin du fichier de l'objet existe.

Pour le chemin du fichier de l'objet, utilisez la valeur PCLD du message d'audit LLST.

Par exemple, entrez :

ls '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6'

Remarque : placez toujours le chemin du fichier d'objet entre guillemets dans des commandes pour échapper à tout caractère spécial.

Si le chemin d'accès à l'objet est introuvable, il est perdu et ne peut pas être restauré à l'aide de cette procédure. Contactez l'assistance technique.
Si le chemin d'accès à l'objet est trouvé, passez à l'étape Restaurez l'objet sur StorageGRID. Vous pouvez essayer de restaurer à nouveau l'objet trouvé dans StorageGRID.
1. si le chemin d'accès à l'objet a été trouvé, essayez de restaurer l'objet dans StorageGRID :
  1. À partir du même nœud de stockage, modifiez la propriété du fichier objet afin qu'il puisse être géré par StorageGRID. Entrez : chown ldr-user:bycast 'file_path_of_object'
  2. Telnet vers localhost 1402 pour accéder à la console LDR. Entrez : telnet 0 1402
  3. Entrez : cd /proc/STOR
  4. Entrez : Object_Found 'file_path_of_object'
    
    Par exemple, entrez :
    
    Object_Found '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6'
    
    Émission du Object\_Found commande informe la grille de l'emplacement de l'objet. Il déclenche également la règle ILM active, qui crée des copies supplémentaires, comme spécifié dans la règle.
    
    Remarque : si le noeud de stockage sur lequel vous avez trouvé l'objet est hors ligne, vous pouvez copier l'objet sur n'importe quel noeud de stockage en ligne. Placez l'objet dans un répertoire /var/local/rangedb du noeud de stockage en ligne. Ensuite, émettez le Object\_Found commande utilisant ce chemin de fichier pour l'objet.
    
    Si l'objet ne peut pas être restauré, le Object\_Found échec de la commande. Contactez l'assistance technique.
    
    Si l'objet a été restauré avec succès dans StorageGRID, un message de réussite s'affiche. Par exemple :
    
    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'
    
    Passez à l'étape Vérifiez que de nouveaux emplacements ont été créés
  5. si l'objet a été restauré avec succès dans StorageGRID, vérifiez que de nouveaux emplacements ont été créés.
    
    Entrez : cd /proc/OBRP
    
    Entrez : ObjectByUUID UUID_value

L'exemple suivant montre qu'il existe deux emplacements pour l'objet avec l'UUID 926026C4-00A4-449B-AC72-BCCA72DD1311.

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"
        }
    ]
}

Se déconnecter de la console LDR. Entrez : exit
1. À partir d'un nœud d'administration, recherchez dans les journaux d'audit le message d'audit ORLM correspondant à cet objet pour vous assurer que la gestion du cycle de vie des informations (ILM) a placé des copies, si nécessaire.
Connectez-vous au nœud grid :
1. Saisissez la commande suivante : ssh admin@grid_node_IP
2. Entrez le mot de passe indiqué dans le Passwords.txt fichier.
3. Entrez la commande suivante pour passer à la racine : su -
4. Entrez le mot de passe indiqué dans le Passwords.txt fichier. Lorsque vous êtes connecté en tant que root, l'invite passe de $ à #.
Accédez au répertoire dans lequel se trouvent les journaux d'audit : cd /var/local/audit/export/
Utilisez grep pour extraire les messages d'audit associés à l'objet dans un fichier de sortie. Entrez : grep uuid-valueaudit_file_name > output_file_name

Par exemple :
```
Admin: # grep 926026C4-00A4-449B-AC72-BCCA72DD1311 audit.log > messages_about_restored_object.txt
```

Utilisez grep pour extraire les messages d'audit règles objet met (ORLM) de ce fichier de sortie. Entrez : grep ORLM output_file_name

Par exemple :

Admin: # grep ORLM messages_about_restored_object.txt

Un message d'audit ORLM ressemble à cet exemple de message.

[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]]

Recherchez le champ EMPLACEMENTS dans le message d'audit.

Le cas échéant, la valeur de CLDI dans LES EMPLACEMENTS est l'ID de nœud et l'ID de volume sur lequel une copie d'objet a été créée. Ce message indique que la ILM a été appliquée et que deux copies d'objet ont été créées à deux emplacements dans la grille. . Réinitialisez le nombre d'objets perdus dans le Grid Manager.

Informations associées

Rechercher les objets perdus

Réinitialiser le nombre d'objets perdus et manquants

Examiner les journaux d'audit

Recherche et restauration d'objets potentiellement perdus

Creating your file...