Por qué una reconstrucción RAID se reinicia después de que un disco se desconecta

Una reconstrucción puede reiniciarse después de que otro disco se desconecte porque el conjunto de miembros confiables del arreglo cambió nuevamente. El controlador puede descartar el progreso parcial y regenerar la redundancia desde un nuevo punto de consistencia.

Una desconexión breve no es inofensiva durante la operación degradada. La respuesta correcta es identificar qué miembro con número de serie se desconectó, preservar los registros, confirmar que el arreglo aún tiene suficientes copias válidas y dejar de experimentar con cables o compartimentos hasta entender el estado actual de recuperación.

La Segunda Desconexión Crea Un Nuevo Evento de Recuperación

Una reconstrucción se basa en un conjunto específico de miembros fuente y un disco objetivo. Si otro miembro fuente desaparece, aunque sea brevemente, el arreglo ya no puede asumir que cada bloque ya escrito en el objetivo coincide con el conjunto activo actual. Las escrituras también pueden haber continuado mientras ese miembro estaba ausente.

Los controladores manejan esto de manera diferente. Algunos reanudan desde un mapa de bits o punto de control; otros reinician una reconstrucción completa. La discusión sobre la reconstrucción tras reconectar un disco muestra por qué quitar un miembro cambia el estado de tolerancia a fallos incluso cuando el disco aún contiene la mayor parte de los datos antiguos.

Los Metadatos Sucios Pueden Hacer Que Un Miembro Antiguo Parezca Obsoleto

Los miembros del RAID normalmente almacenan metadatos del arreglo que identifican su rol e historial de eventos. Cuando un disco desaparece mientras continúan las escrituras, su contenido se vuelve más antiguo que el arreglo activo. Reconectarlo no hace que esas escrituras perdidas desaparezcan, por lo que el controlador debe reconciliar o sobrescribir las regiones obsoletas.

Un miembro de RAID retirado temporalmente puede ser reconocido por sus metadatos, pero la implementación aún decide si puede reincorporarse directamente o necesita sincronización. No asuma que volver al mismo compartimento preserva la confianza.

Por qué el progreso puede volver a cero

El porcentaje a menudo describe la pasada de recuperación actual, no un registro permanente de todos los bloques copiados alguna vez. Si un miembro fuente cambia de estado, el objetivo se reasigna o el controlador reensambla el arreglo, la operación mostrada puede reiniciarse desde cero incluso si algunos bloques objetivo ya coinciden.

En RAID por software, un nuevo evento degradado puede requerir una resincronización completa. Una segunda reconstrucción completa documentada de RAID1 demuestra que una vez que un arreglo md entra en estado degradado, puede sincronizar todo el miembro en lugar de confiar en un estado parcial anterior.

No retire otro disco para probar la teoría

Durante una reconstrucción, cada fuente restante es parte del único camino para reconstruir los datos faltantes. Retirar otro miembro para identificación puede exceder la tolerancia a fallos del nivel RAID o crear versiones de datos en competencia. Ubique los discos por número de serie e indicadores de la carcasa, no por remoción de prueba.

Detenga los experimentos de intercambio en caliente hasta que el arreglo esté saludable o copiado a un almacenamiento seguro. Si se sospecha de un cable o bahía, primero recopile el registro de eventos y planifique un cambio controlado único con el sistema en estado de quietud cuando el hardware no soporte explícitamente el servicio en línea.

Verifique si la reconstrucción realmente se reinició

Compare más que el porcentaje. Registre el nombre de la operación, número de serie objetivo, cantidad de miembros fuente, número de evento o generación, bloques procesados, velocidad actual y tiempo estimado de finalización. Un controlador puede cambiar de reconstrucción a inicialización de paridad, verificación o comprobación de consistencia en segundo plano.

Si el conjunto de miembros cambió, trate el nuevo porcentaje como un evento nuevo. Si solo se reinició la interfaz mientras los contadores continúan, puede ser un problema de visualización en lugar de una pérdida de progreso.

Cuando un reinicio es menos importante que la caída de un disco

Un reinicio planificado no invalida necesariamente una reconstrucción gestionada por el controlador. Muchos controladores persisten suficiente estado para reanudar de forma segura. El evento más grave es perder otro disco fuente o introducir una configuración externa durante o después del reinicio.

Un reinicio durante una reconstrucción puede ser recuperable, pero la conclusión segura depende del estado del controlador después del arranque. Nunca inicialice o importe una configuración externa solo porque el porcentaje se reinició.

Qué Hacer Inmediatamente

1. Pausa las escrituras no esenciales y capture los registros del arreglo, la carcasa y el sistema operativo.
2. Mapee cada miembro activo, faltante, en reconstrucción y de repuesto a un número de serie físico.
3. Confirme que el nivel RAID aún tiene suficientes miembros fuente válidos para reconstruir los datos.
4. Revise los contadores SMART y de errores de enlace en el disco que se desconectó y su ruta de conexión.
5. Deje que una reconstrucción estable se ejecute sin experimentos adicionales con cables, bahías, reinicios o cargas de trabajo.

Si otra fuente reporta sectores ilegibles o desconexiones repetidas, priorice copiar datos irremplazables o hacer imágenes de los miembros en lugar de forzar repetidamente una reconstrucción.

Preguntas Frecuentes

¿Reconectar el mismo disco siempre reiniciará la reconstrucción?

No. Algunos controladores pueden reincorporarlo o reanudar desde un mapa de bits. Otros consideran que el miembro está obsoleto y comienzan la sincronización nuevamente. El registro de eventos y los datos de generación del miembro deciden qué caso ocurrió.

¿Un porcentaje reiniciado significa que el nuevo disco fue borrado de nuevo?

No necesariamente. Puede significar que el controlador inició una nueva pasada o cambió el tipo de operación. No infiera pérdida de datos solo por el porcentaje; inspeccione la identidad del objetivo y los mensajes de evento.

¿Puedo seguir usando aplicaciones durante la reconstrucción reiniciada?

Se puede soportar un uso ligero, pero reduzca las escrituras evitables y los trabajos sensibles a la latencia. El arreglo ya ha mostrado un segundo evento de conectividad, por lo que la estabilidad y la protección de datos tienen prioridad sobre el rendimiento normal.

La Respuesta Práctica

Una reconstrucción se reinicia porque las suposiciones de consistencia cambiaron cuando otro miembro se desconectó. Estabilice la ruta del hardware, verifique el conjunto de origen y permita una recuperación ininterrumpida en lugar de probar el arreglo mientras está degradado.