Llame a una reconstrucción RAID detenida solo cuando los bloques procesados dejen de aumentar en múltiples revisiones y los registros no muestren pausa intencional, limitación de prioridad, fase en cola o reintento recuperable. El tiempo transcurrido por sí solo no es suficiente.
Los arreglos grandes pueden pasar horas en una región lenta, cambiar la velocidad bruscamente bajo carga de aplicación o pausar entre reconstrucción y verificación. Establezca movimiento con contadores y registros antes de intervenir, porque detener o reensamblar un arreglo puede crear más riesgo que esperar.
Use la Diferencia de Progreso, No un Solo Porcentaje
Registre el conteo exacto de bloques procesados, porcentaje, velocidad y tiempo estimado de finalización en intervalos fijos. Una reconstrucción avanza cuando el conteo de bloques aumenta, incluso si el porcentaje redondeado permanece igual. En arreglos de varios terabytes, una décima de porcentaje mostrada puede representar una gran cantidad de trabajo.
Revise el controlador o sistema operativo desde la misma interfaz cada vez. Diferentes paneles pueden almacenar en caché el estado o reportar fases distintas. Una barra de progreso que parece congelada mientras los contadores de bloques avanzan es un problema de monitoreo, no una reconstrucción detenida.
Estime una Línea Base Local en Lugar de un Tiempo de Espera Universal
No existe un número seguro único de horas. El tiempo de reconstrucción depende de la capacidad usada, la configuración RAID, la velocidad del disco, errores, política del controlador, carga en segundo plano y si la implementación copia todos los bloques o solo las regiones asignadas.
Use la primera hora estable para estimar un rango aproximado y luego compare intervalos posteriores. Una tasa de resincronización mdadm muy lenta puede deberse a la carga de trabajo, alineación, comportamiento del enlace o un disco con problemas; el diagnóstico correcto requiere más que solo aumentar un límite de velocidad.
Busque una Pausa Intencional o una Nueva Fase
Algunos sistemas limitan la recuperación para proteger la E/S en primer plano, pausan las comprobaciones durante el resilver, esperan la asignación de un repuesto o transicionan de la reconstrucción a la inicialización de paridad o verificación de consistencia. La etiqueta puede permanecer como “reconstruyendo” mientras la tarea activa cambia.
Revise el mantenimiento programado, configuraciones de energía, límites de temperatura, prioridad de reconstrucción y tráfico de aplicaciones. Si la velocidad aumenta cuando la carga en primer plano disminuye, el arreglo está limitado por recursos y no está atascado.
Errores de lectura repetidos crean un estancamiento real
Una unidad fuente puede pasar mucho tiempo reintentando un sector débil, causando que el rendimiento colapse cerca del mismo rango de bloques. Si el controlador finalmente reporta una lectura irrecuperable, la reconstrucción puede abortar porque la redundancia no puede reconstruir esa región.
Una reconstrucción detenida por errores de lectura demuestra por qué importa el último bloque exitoso y el error del kernel inmediatamente después. No reinicie repetidamente una recuperación que falla en la misma dirección sin proteger los datos y examinar el miembro fuente.
Una velocidad cero con actividad en el registro puede estar reintentando
Una velocidad mostrada de cero puede ocurrir durante reintentos de comandos, reinicios de dispositivos, recuperación de errores, actualizaciones de metadatos o una pausa temporal. Observe el tiempo de ocupación del disco, la profundidad de la cola, eventos del controlador y mensajes del kernel. Reinicios o tiempos de espera repetidos no son un progreso saludable.
Una recuperación que se interrumpe repetidamente también muestra que no toda detención tiene una falla SMART obvia. Capture el punto exacto y todos los registros en lugar de asumir que un disco nuevo o una configuración de mayor velocidad lo resolverán.
Usar una Tabla de Decisión de Estancamiento Práctica
| Observación en dos o más intervalos | Interpretación | Acción |
|---|---|---|
| Aumento de bloques procesados | Lento pero avanzando | Continuar monitoreando |
| Porcentaje sin cambios, aumento de bloques | Mostrar redondeo | Esperar |
| Bloques sin cambios, la tarea indica pausa | Retención intencional | Encontrar pausa o motivo de política |
| Bloques sin cambios, reintentos/reinicios repetidos | Problema de hardware o ruta | Reducir escrituras; inspeccionar fuente y conexión |
| Se detiene en el mismo bloque después del reinicio | Región ilegible persistente | Proteger datos; detener reintentos ciegos |
| 99.9% con fase de seguimiento activa | Finalización o trabajo de metadatos | Verificar etiqueta de operación y registros |
Requiera evidencia de al menos dos señales independientes antes de declarar la reconstrucción detenida: ausencia de movimiento en los contadores más un error, estado abortado o punto de detención idéntico persistente.
Qué Hacer Antes de Reiniciar Algo
- Guarde detalles del arreglo, números de serie de los miembros, contadores de bloques procesados y el registro completo de eventos.
- Reduzca la E/S de aplicaciones no esenciales y confirme que los discos objetivo y fuente sigan detectados.
- Revise los indicadores SMART del medio y los contadores de reinicio de enlace o CRC en cada fuente activa.
- Confirme que no haya estado en pausa, límite de temperatura, política de prioridad o fase de verificación en cola.
- Escale a respaldo, imagen o recuperación cuando el mismo rango ilegible detenga intentos repetidos.
No use comandos de detener, ensamblar, forzar en línea o limpiar metadatos hasta conocer el estado del arreglo y la implementación exacta.
Compare el Progreso Durante un Intervalo Tranquilo
Una prueba útil de detención necesita una ventana de observación controlada. Pausa transferencias grandes y trabajos programados, luego registre los contadores al inicio y al final del intervalo. Esto separa la contención en primer plano de un proceso de recuperación que no puede avanzar por sí solo.
Si el progreso se reanuda cuando la carga disminuye, elija una prioridad de mantenimiento más baja o un horario más tranquilo. Si los contadores permanecen fijos y el mismo error se repite, esperar más sin investigar aporta poca información.
Preguntas Frecuentes
¿El 99.9 por ciento durante una hora está automáticamente detenido?
No. Las actualizaciones finales de metadatos o una fase de verificación pueden tomar tiempo. Confirme si los bloques procesados, las escrituras del dispositivo o el estado de la operación aún cambian antes de intervenir.
¿Debo aumentar el límite de velocidad de reconstrucción?
Solo después de probar que los discos están saludables y que la política de E/S en primer plano es el cuello de botella. Un límite más alto puede empeorar la latencia de la aplicación y aumentar la presión sobre una unidad fuente marginal.
¿Cuándo debo dejar de esperar?
Deje de tratarlo como normal cuando los contadores permanezcan sin cambios tras revisiones repetidas y los registros muestren un aborto, reinicio recurrente del dispositivo, lectura irrecuperable o fallo en el mismo rango de bloques.
La Definición Operativa de Detención
Una reconstrucción se detiene cuando el trabajo medible se ha detenido y el sistema no puede explicar la pausa como política, carga o una nueva fase. Use contadores y evidencia de errores, no ansiedad ni tiempo de reloj.
Soporte y Consejos
Más para leer

¿Por qué un arreglo RAID se vuelve inactivo después de una pérdida de energía?
Un arreglo inactivo a menudo significa que se encontraron metadatos, pero el sistema no tenía suficiente confianza o miembros para iniciarlo de forma segura...

¿Cuáles son los riesgos de forzar la reconexión de un miembro RAID que falta?
Las opciones de fuerza pueden omitir las comprobaciones de seguridad relacionadas con metadatos obsoletos, paridad sucia, escrituras faltantes o grupos activos; inspeccione y preserve...

Cómo distinguir un cable SATA defectuoso de un disco NAS que está fallando
Realice un seguimiento de si los errores siguen al disco o permanecen en la ruta SATA, y separe los contadores de transporte de la...

