Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Rechercher les objets perdus

Contributeurs
PDF

Lorsque l'alerte objets perdus est déclenchée, vous devez examiner immédiatement. Collectez des informations sur les objets affectés et contactez le support technique.

Ce dont vous avez besoin

  • Vous devez être connecté au Grid Manager à l'aide d'un navigateur web pris en charge.

  • Vous devez disposer d'autorisations d'accès spécifiques.

  • Vous devez avoir le Passwords.txt fichier.

Description de la tâche

L'alerte objets perdus indique que StorageGRID estime qu'il n'y a pas de copie d'un objet dans la grille. Les données ont peut-être été définitivement perdues.

Recherchez immédiatement les alertes relatives à la perte d'objet. Vous devrez peut-être prendre des mesures pour éviter d'autres pertes de données. Dans certains cas, vous pourrez peut-être restaurer un objet perdu si vous prenez une action d'invite.

Étapes

  1. Sélectionnez NOEUDS.

  2. Sélectionnez Storage Node objets.

  3. Vérifiez le nombre d'objets perdus affichés dans le tableau nombres d'objets.

    Ce nombre indique le nombre total d'objets que ce nœud de grille détecte comme manquant dans l'ensemble du système StorageGRID. La valeur est la somme des compteurs d'objets perdus du composant de stockage de données dans les services LDR et DDS.

    Nœuds de stockage objet page objets perdu objet

  4. À partir d'un noeud d'administration, accédez au journal d'audit pour déterminer l'identificateur unique (UUID) de l'objet qui a déclenché l'alerte objets perdus :

    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. Entrez : cd /var/local/audit/export/

    3. Utilisez grep pour extraire les messages d'audit objet perdu (OLST). Entrez : grep OLST audit_file_name

    4. Notez la valeur UUID incluse dans le message.

      >Admin: # grep OLST audit.log
2020-02-12T19:18:54.780426 [AUDT:[CBID(UI64):0x38186FE53E3C49A5][UUID(CSTR):926026C4-00A4-449B-AC72-BCCA72DD1311]
[PATH(CSTR):"source/cats"][NOID(UI32):12288733][VOLI(UI64):3222345986][RSLT(FC32):NONE][AVER(UI32):10]
[ATIM(UI64):1581535134780426][ATYP(FC32):OLST][ANID(UI32):12448208][AMID(FC32):ILMX][ATID(UI64):7729403978647354233]]

  5. Utilisez le ObjectByUUID Commande permettant de rechercher l'objet par son identificateur (UUID), puis de déterminer si les données sont à risque.

    1. Telnet vers localhost 1402 pour accéder à la console LDR.

    2. Entrez : /proc/OBRP/ObjectByUUID UUID_value

      Dans ce premier exemple, l'objet avec UUID 926026C4-00A4-449B-AC72-BCCA72DD1311 comporte deux emplacements répertoriés.

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

      Dans le second exemple, l'objet avec UUID 926026C4-00A4-449B-AC72-BCCA72DD1311 n'a aucun emplacement répertorié.

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

    1. Examinez le résultat de /proc/OBRP/ObjectByUUID et prenez les mesures appropriées :

      Les métadonnées Conclusion

      Aucun objet trouvé ("ERREUR":" )

      Si l'objet n'est pas trouvé, le message "ERREUR":" est renvoyé.

      Si l'objet est introuvable, vous pouvez réinitialiser le nombre d'objets perdus* pour effacer l'alerte. L'absence d'objet indique que l'objet a été supprimé intentionnellement.

      Emplacements 0

      Si des emplacements sont répertoriés dans la sortie, l'alerte objets perdus peut être un faux positif.

      Vérifiez que les objets existent. Utilisez l'ID de nœud et le chemin du fichier indiqués dans la sortie pour confirmer que le fichier objet se trouve à l'emplacement indiqué.

      (La procédure pour recherche d'objets potentiellement perdus Explique comment utiliser l'ID de nœud pour trouver le nœud de stockage approprié.)

      Si les objets existent, vous pouvez réinitialiser le nombre d'objets perdus* pour effacer l'alerte.

      Emplacements = 0

      Si aucun emplacement n'est répertorié dans le résultat, l'objet est potentiellement manquant. Vous pouvez essayer recherchez et restaurez l'objet vous pouvez aussi contacter le support technique.

      L'assistance technique peut vous demander si une procédure de restauration du stockage est en cours. C'est-à-dire qu'une commande repair-Data a été émise sur un nœud de stockage, et la restauration est-elle toujours en cours ? Voir les informations sur restauration des données d'objet vers un volume de stockage.
Informations associées

Examiner les journaux d'audit