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 objetos perdidos

02/20/2023 Colaboradores

PDF

Cuando se activan la alerta objetos perdidos y la alarma legado PERDIDO (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 explorador compatible.
Debe tener permisos de acceso específicos.
Debe tener la Passwords.txt archivo.

Acerca de esta tarea

La alerta * objetos perdidos* y la alarma PERDIDA indican 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.

Investigue inmediatamente las alarmas o alertas de objetos perdidos. 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.

El número de objetos perdidos se puede ver en el Gestor de grid.

Pasos

Seleccione Nodes.
Seleccione Storage Node > Objects.
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.
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 y la alarma PERDIDA:
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]]

Utilice la ObjectByUUID Comando para encontrar el objeto mediante su identificador (UUID) y, a continuación, determinar si los datos están en riesgo.

Telnet a localhost 1402 para acceder a la consola LDR.

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

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, es seguro ignorar la alarma. La falta de un objeto indica que el objeto se ha eliminado intencionalmente.
Ubicaciones > 0	Si hay ubicaciones enumeradas en la salida, la alarma objetos perdidos puede 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. (El procedimiento para buscar objetos potencialmente perdidos explica cómo usar el ID de nodo para encontrar el nodo de almacenamiento correcto). "Buscar y restaurar objetos potencialmente perdidos" Si los objetos existen, puede restablecer el recuento de objetos perdidos para borrar la alarma y la alerta.
Ubicaciones = 0	Si no hay ninguna ubicación en la salida, el objeto puede faltar. Puede intentar encontrar y restaurar el objeto por su cuenta, o bien ponerse en contacto con el soporte técnico. "Buscar y restaurar objetos potencialmente perdidos" 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 sobre cómo restaurar datos de objeto en un volumen de almacenamiento en las instrucciones de recuperación y mantenimiento.

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, es seguro ignorar la alarma. La falta de un objeto indica que el objeto se ha eliminado intencionalmente.

Ubicaciones > 0

Si hay ubicaciones enumeradas en la salida, la alarma objetos perdidos puede 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.

(El procedimiento para buscar objetos potencialmente perdidos explica cómo usar el ID de nodo para encontrar el nodo de almacenamiento correcto).

"Buscar y restaurar objetos potencialmente perdidos"

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

Ubicaciones = 0

Si no hay ninguna ubicación en la salida, el objeto puede faltar. Puede intentar encontrar y restaurar el objeto por su cuenta, o bien ponerse en contacto con el soporte técnico.

"Buscar y restaurar objetos potencialmente perdidos"

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 sobre cómo restaurar datos de objeto en un volumen de almacenamiento en las instrucciones de recuperación y mantenimiento.

Información relacionada

"Mantener recuperar"

"Revisar los registros de auditoría"

Investigar objetos perdidos

Creating your file...