Para evaluar una pérdida de acceso, identificamos qué componentes de cada objeto siguen disponibles y cómo se distribuyeron. La versión, la arquitectura y la política de almacenamiento ayudan a interpretar la redundancia y el estado del clúster.
En Nekiori evaluamos unidades dañadas con herramientas de laboratorio. Si faltan dispositivos o un host está fuera de servicio, revisamos qué componentes, metadatos y copias siguen disponibles para establecer el alcance del caso.
Revisamos los objetos, sus componentes y la política de almacenamiento, incluidos el nivel de tolerancia a fallas (FTT) y la distribución entre hosts o dominios de falla. También examinamos los identificadores de objetos, los eventos del clúster y los cambios de configuración.
Si existe cifrado, coordinamos con el responsable de TI el acceso autorizado a las claves que puedan ser necesarias. La versión, la redundancia y el estado de los dispositivos determinan qué información es recuperable.
- OSAArquitectura original. Utiliza grupos de discos por host con un dispositivo de caché y unidades de capacidad.
- ESAArquitectura Express. Utiliza un pool de almacenamiento por host, sin un dispositivo dedicado de caché por grupo de discos.
- Topología del clústerEvaluamos clústeres estándar, de dos nodos o extendidos, considerando dominios de falla y el testigo cuando corresponda.
Indícanos la versión y la arquitectura si las conoces. Revisamos cada configuración según los antecedentes y dispositivos disponibles.
Estos avisos son referencias verificadas. Su significado depende del modelo, la versión y la configuración; un mensaje por sí solo no determina la causa ni qué datos pueden recuperarse.
-
Inaccessible · Objeto inaccesible
vSAN · Según versión y política de almacenamiento
No hay una combinación disponible de componentes que permita acceder al objeto. Hay que revisar sus hosts, unidades y distribución.
Evita recrear el datastore o borrar grupos de discos. Evaluamos los componentes disponibles y la organización de los objetos.
-
Reduced Availability · Disponibilidad reducida
vSAN OSA y ESA · Según versión
El objeto tiene menor protección que la requerida. No significa necesariamente que ya sea inaccesible.
Conserva los registros de vCenter y los cambios de hosts. Si se perdió acceso, analizamos los componentes y su estado.
-
ABSENT / Resynchronizing · Componentes ausentes o resincronizando
vSAN · Según versión y causa
Pueden aparecer tras una pérdida de conectividad, mantenimiento o falla de un host. Una resincronización detenida requiere revisar la causa, no solo su porcentaje.
Anota la secuencia y evita retirar más componentes por prueba. Diagnosticamos las unidades y las capas virtuales cuando corresponde.
En Nekiori evaluamos las unidades, incluidas las dañadas, y utilizamos herramientas de laboratorio y desarrollos propios para definir la recuperación. Comparte el mensaje completo y los cambios realizados.
- Revisamos el incidente y coordinamos la recepción. Identificamos hosts, objetos afectados, políticas y cambios recientes para definir qué dispositivos o antecedentes necesitamos.
- Evaluamos los medios. Trabajamos con las unidades dañadas y, cuando su estado lo permite, obtenemos imágenes para analizar copias.
- Relacionamos los componentes de cada objeto. Interpretamos la estructura y los metadatos disponibles para extraer los discos virtuales y archivos que puedan recuperarse.
- Revisamos la información recuperada y coordinamos su entrega. Acordamos con tu equipo de TI el medio de entrega de los datos obtenidos.
Puedes consultar aunque desconozcas la configuración exacta. Si ya los tienes, comparte estos antecedentes con el responsable del caso:
- Versiones de ESXi, vCenter y vSAN; arquitectura OSA o ESA.
- Hosts afectados, número de dispositivos por host y unidades reemplazadas.
- Máquinas virtuales, discos VMDK u objetos afectados y, si los conoces, sus UUID.
- Políticas de almacenamiento, dominios de falla y eventos de vCenter o Skyline Health.
- Registros disponibles, cambios realizados, estado de los respaldos y existencia de cifrado.
1. Evita nuevas escrituras
Coordina con TI las tareas que escriben sobre el datastore afectado y conserva los respaldos existentes.
2. Conserva la configuración actual
Evita recrear grupos de discos o pools, reclamar dispositivos para otro clúster o inicializarlos.
3. Conserva los objetos afectados
Evita borrar objetos inaccesibles, recrear discos virtuales o forzar resincronizaciones mientras se evalúa el incidente.
4. Identifica cada dispositivo
Registra su host, bahía y función. Conserva las unidades retiradas, incluidas las de caché en OSA.
5. Guarda los eventos y registros
Conserva las alertas, las políticas y los cambios recientes. Coordina la entrega de información con tu equipo de TI.
6. Coordina antes de retirar o reiniciar
Consulta con el responsable del clúster antes de retirar medios, poner hosts en mantenimiento o realizar apagados forzados.
Sí. Revisamos las unidades y los componentes que permanecen disponibles. La política de almacenamiento, la redundancia y el estado de los medios orientan las opciones de recuperación.
El estado indica que el clúster no puede acceder al objeto. El diagnóstico permite distinguir una interrupción de conectividad de un problema en los medios o en los componentes que forman el objeto.
Coordina primero con Nekiori y con el responsable del clúster. Conserva los dispositivos identificados por host y bahía, incluidas las unidades retiradas y las de caché si tu sistema usa OSA.
Los antecedentes sirven para orientar la evaluación. El procedimiento, el presupuesto definitivo y los plazos se determinan tras el diagnóstico en laboratorio.
Sí. Nekiori cuenta con un contrato de servicio y, si tu empresa lo requiere, puedes solicitar además un acuerdo de confidencialidad (NDA). Coméntanos este requisito al coordinar la evaluación.
Arquitecturas vSAN OSA y ESA · VMware · Objetos vSAN inaccesibles · Broadcom
Consulta también nuestros servicios de recuperación de datos SAN y recuperación de servidores.