Skip to main content
Hay disponible una nueva versión de este producto.
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Investigar los objetos perdidos

Colaboradores
PDF

Cuando se activa la alerta objetos perdidos, debe investigar inmediatamente. Recopile información sobre los objetos afectados y póngase en contacto con el soporte técnico.

Lo que necesitará

  • Debe iniciar sesión en Grid Manager mediante un navegador web compatible.

  • Debe tener permisos de acceso específicos.

  • Debe tener la Passwords.txt archivo.

Acerca de esta tarea

La alerta * objetos perdidos* indica que StorageGRID cree que no hay copias de un objeto en la cuadrícula. Es posible que los datos se hayan perdido de forma permanente.

Investigar las alertas de objetos perdidos de inmediato. Es posible que deba tomar medidas para evitar la pérdida de datos adicional. En algunos casos, es posible que pueda restaurar un objeto perdido si realiza una acción rápida.

Pasos

  1. Seleccione NODES.

  2. Seleccione Storage Node > Objects.

  3. Revise el número de objetos perdidos que se muestra en la tabla recuentos de objetos.

    Este número indica el número total de objetos que este nodo de cuadrícula detecta como no recibidos de todo el sistema StorageGRID. El valor es la suma de los contadores de objetos perdidos del componente almacén de datos dentro de los servicios LDR y DDS.

    Nodos de almacenamiento objeto Página de objeto perdido

  4. Desde un nodo de administración, acceda al registro de auditoría para determinar el identificador único (UUID) del objeto que activó la alerta objetos perdidos:

    1. Inicie sesión en el nodo de grid:

      1. Introduzca el siguiente comando: ssh admin@grid_node_IP

      2. Introduzca la contraseña que aparece en Passwords.txt archivo.

      3. Introduzca el siguiente comando para cambiar a la raíz: su -

      4. Introduzca la contraseña que aparece en Passwords.txt archivo. Cuando ha iniciado sesión como root, el símbolo del sistema cambia de $ para #.

    2. Cambie al directorio donde se encuentran los registros de auditoría. Introduzca: cd /var/local/audit/export/

    3. Utilice grep para extraer los mensajes de auditoría de objetos perdidos (OLST). Introduzca: grep OLST audit_file_name

    4. Observe el valor de UUID incluido en el mensaje.

      >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. Utilice la ObjectByUUID Comando para encontrar el objeto mediante su identificador (UUID) y, a continuación, determinar si los datos están en riesgo.

    1. Telnet a localhost 1402 para acceder a la consola LDR.

    2. Introduzca: /proc/OBRP/ObjectByUUID UUID_value

      En este primer ejemplo, el objeto con UUID 926026C4-00A4-449B-AC72-BCCA72DD1311 tiene dos ubicaciones en la lista.

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

      En el segundo ejemplo, el objeto con UUID 926026C4-00A4-449B-AC72-BCCA72DD1311 no tiene ninguna ubicación en la lista.

    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. Revise el resultado de /proc/OBRP/ObjectByUUID y realice la acción correspondiente:

      Metadatos Conclusión

      No se ha encontrado ningún objeto ("ERROR":"" )

      Si no se encuentra el objeto, se devuelve el mensaje "ERROR":".

      Si no se encuentra el objeto, puede restablecer el recuento de objetos perdidos para borrar la alerta. La falta de un objeto indica que el objeto se ha eliminado intencionalmente.

      Ubicaciones > 0

      Si hay ubicaciones enumeradas en la salida, la alerta objetos perdidos podría ser un falso positivo.

      Confirme que los objetos existen. Utilice el Id. De nodo y la ruta de archivo que aparecen en la salida para confirmar que el archivo de objeto está en la ubicación de la lista.

      (Procedimiento para buscando objetos potencialmente perdidos Explica cómo usar el ID de nodo para encontrar el nodo de almacenamiento correcto.)

      Si los objetos existen, puede restablecer el recuento de objetos perdidos para borrar la alerta.

      Ubicaciones = 0

      Si no hay ninguna ubicación en la salida, el objeto puede faltar. Puede intentar busque y restaure el objeto usted mismo o puede ponerse en contacto con el soporte técnico.

      Es posible que el soporte técnico le solicite determinar si hay un procedimiento de recuperación del almacenamiento en curso. Es decir, ¿se ha emitido un comando repair-data en cualquier nodo de almacenamiento y la recuperación sigue en curso? Consulte la información acerca de restaurar datos de objeto en un volumen de almacenamiento.
Información relacionada

Revisar los registros de auditoría