Había creado dos particiones HDD de 2TB ( /dev/sdb1y /dev/sdc1) en una matriz RAID 1 llamada /dev/md0usando mdadmUbuntu 12.04 LTS Precise Pangolin.
El comando sudo mdadm --detail /dev/md0utilizado para indicar ambas unidades como sincronización activa .
Luego, para probar, fallé /dev/sdb1, lo eliminé y luego lo agregué nuevamente con el comandosudo mdadm /dev/md0 --add /dev/sdb1
watch cat /proc/mdstat mostró una barra de progreso de la reconstrucción de la matriz, pero no pasaría horas viéndola, así que supuse que el software sabía lo que estaba haciendo.
Una vez que la barra de progreso ya no se muestra, cat /proc/mdstataparece:
md0 : active raid1 sdb1[2](S) sdc1[1]
1953511288 blocks super 1.2 [2/1] [U_]
Y sudo mdadm --detail /dev/md0muestra:
/dev/md0:
Version : 1.2
Creation Time : Sun May 27 11:26:05 2012
Raid Level : raid1
Array Size : 1953511288 (1863.01 GiB 2000.40 GB)
Used Dev Size : 1953511288 (1863.01 GiB 2000.40 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Mon May 28 11:16:49 2012
State : clean, degraded
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
Name : Deltique:0 (local to host Deltique)
UUID : 49733c26:dd5f67b5:13741fb7:c568bd04
Events : 32365
Number Major Minor RaidDevice State
1 8 33 0 active sync /dev/sdc1
1 0 0 1 removed
2 8 17 - spare /dev/sdb1
Me han dicho que mdadm reemplaza automáticamente las unidades eliminadas con repuestos, pero /dev/sdb1no se mueve a la posición esperada, RaidDevice 1.
ACTUALIZACIÓN (30 de mayo de 2012): una badblocksprueba destructiva de lectura y escritura de todo /dev/sdbno arrojó errores como se esperaba; Ambos discos duros son nuevos.
A partir de la última edición, ensamblé la matriz con este comando:
sudo mdadm --assemble --force --no-degraded /dev/md0 /dev/sdb1 /dev/sdc1
El resultado fue:
mdadm: /dev/md0 has been started with 1 drive (out of 2) and 1 rebuilding.
La reconstrucción parece que progresa normalmente:
md0 : active raid1 sdc1[1] sdb1[2]
1953511288 blocks super 1.2 [2/1] [U_]
[>....................] recovery = 0.6% (13261504/1953511288) finish=2299.7min speed=14060K/sec
unused devices: <none>
Ahora estoy esperando esta reconstrucción, pero espero /dev/sdb1convertirme en un repuesto como las cinco o seis veces que he intentado reconstruir antes.
ACTUALIZACIÓN (31 de mayo de 2012): Sí, todavía es un repuesto. Ugh!
ACTUALIZACIÓN (01 de junio de 2012): Estoy probando el comando sugerido de Adrian Kelly :
sudo mdadm --assemble --update=resync /dev/md0 /dev/sdb1 /dev/sdc1
Esperando la reconstrucción ahora ...
ACTUALIZACIÓN (02 de junio de 2012): No, sigue siendo un repuesto ...
ACTUALIZACIÓN (04 junio 2012): PB trajo una preocupación de que pasé por alto: tal vez /dev/sdc1se produzcan errores de E / S . No me había molestado en comprobarlo /dev/sdc1porque parecía estar funcionando bien y era nuevo, pero los errores de E / S hacia el final de la unidad son una posibilidad racional.
Compré estos discos duros a la venta, por lo que no sería sorprendente que uno de ellos ya esté fallando. Además, ninguno de ellos tiene soporte para SMART , así que no es de extrañar que fueran tan baratos ...
Aquí está el procedimiento de recuperación de datos que acabo de inventar y estoy siguiendo:
sudo mdadm /dev/md0 --fail /dev/sdb1para que pueda sacar/dev/sdb1.sudo mdadm /dev/md0 --remove /dev/sdb1para eliminar/dev/sdb1de la matriz./dev/sdc1está montado en/media/DtkBk- Formatear
/dev/sdb1como ext4. - Monte
/dev/sdb1a/media/DtkBkTemp. cd /mediapara trabajar en esa área.sudo chown deltik DtkBkTemppara darmedeltikderechos (nombre de usuario ) a la partición.- Copie todos los archivos y directorios:
sudo rsync -avzHXShP DtkBk/* DtkBkTemp
ACTUALIZACIÓN (06 de junio de 2012): Hice una badblocksprueba destructiva de modo de escritura /dev/sdc, siguiendo los siguientes procedimientos:
sudo umount /media/DtkBkpara permitir derribar la matriz.sudo mdadm --stop /dev/md0para detener la matriz.sudo badblocks -w -p 1 /dev/sdc -s -vpara borrar el disco duro sospechoso y, en el proceso, verificar si hay errores de E / S. Si hay errores de E / S, eso no es una buena señal. Con suerte, puedo obtener un reembolso ...
Ahora he confirmado que no hay problemas de entrada / salida en ninguno de los discos duros .
De toda esta investigación, mis dos preguntas originales siguen en pie.
Mis preguntas son:
- ¿Por qué la unidad de repuesto no se está convirtiendo en sincronización activa?
- ¿Cómo puedo hacer que la unidad de repuesto se active?
/dev/sdc1en ese momento porque/dev/sdc1estaba siendo leída mientras/dev/sdb1se estaba escribiendo, y los sectores defectuosos/dev/sdb1se habrían reasignado de manera transparente durante la escritura.watch -n 60 cat /proc/mdstatdónde60está el número de segundos entre actualizaciones.Tuve exactamente el mismo problema y, en mi caso, descubrí que el disco RAID activo sufría errores de lectura durante la sincronización. Por lo tanto, el nuevo disco se sincronizó correctamente y se mantuvo marcado como repuesto.
Es posible que desee verificar sus / var / log / messages y otros registros del sistema en busca de errores. Además, también puede ser una buena idea verificar el estado SMART de su disco:
1) Ejecute la prueba corta:
2) Mostrar los resultados de la prueba:
En mi caso, esto devolvió algo como esto:
Tuve que arrancar una distribución en vivo y copiar manualmente los datos del disco defectuoso al nuevo (actualmente "de repuesto").
fuente
Tuve exactamente el mismo problema y siempre pensé que mi segundo disco, que quería volver a agregar a la matriz, tenía errores. Pero era que mi disco original tenía errores de lectura.
Puede verificarlo
smartctl -t short /dev/sdXy ver los resultados unos minutos más tarde consmartctl -l selftest /dev/sdX. Para mí se veía así:Traté de arreglarlos con este manual . Eso fue divertido :-). Sé que ha verificado errores en ambos discos, pero creo que su problema es que el disco que todavía está en la matriz md tiene errores de lectura, por lo que falla la adición de un segundo disco.
Actualizar
Debería ejecutar un adicional
smartctl -a /dev/sdXsi ve Current_Pending_Sector> 0 algo está mal197 Current_Pending_Sector 0x0012 098 098 000 Old_age Siempre - 69
Para mí, definitivamente fue el problema que eliminé un disco de la incursión solo para probar y resincronizar debido a fallas de lectura. La sincronización abortó a la mitad. Cuando revisé mi disco que todavía estaba en la matriz de incursiones, smartctl informó problemas.
Pude arreglarlos con el manual anterior y vi reducir el número de sectores pendientes. Pero hubo muchos y es un procedimiento largo y aburrido, así que utilicé mi copia de seguridad y restauré los datos en un servidor diferente.
Como no tuvo la oportunidad de usar SMART, supongo que su autoevaluación no mostró esos sectores rotos.
Para mí es una lección aprendida: revise sus discos antes de eliminar uno de su matriz.
fuente
Tuve un problema similar y lo solucioné aumentando la cantidad de discos de la matriz RAID de 1 a 2.
fuente
ACTUALIZACIÓN (24 de mayo de 2015): después de tres años, investigué la verdadera causa de la degradación de la matriz RAID 1.
tl; dr: Una de las unidades estaba dañada, y no me di cuenta de esto porque solo había realizado una prueba de superficie completa en la unidad correcta.
Hace tres años, no pensé en revisar ningún registro sobre problemas de E / S. Si hubiera pensado verificarlo
/var/log/syslog, habría visto algo así cuando memdadmdi por vencido en la reconstrucción de la matriz:Para obtener esa salida en el registro, busqué el primer LBA problemático (14381058, en mi caso) con este comando:
¡No es de extrañar que te
mdhayas rendido! No puede reconstruir una matriz a partir de un disco defectuoso.La nueva tecnología (¿mejor
smartmontoolscompatibilidad de hardware?) Me ha permitido obtener información SMART de la unidad, incluidos los últimos cinco errores (de 1393 errores hasta ahora):Ahh ... eso lo haría.
Ahora, he resuelto esta pregunta en tres sencillos pasos:
ACTUALIZACIÓN (19 de julio de 2015): para cualquier persona que tenga curiosidad, la unidad finalmente se quedó sin sectores para reasignar:
fuente
En mi caso, también era un disco fuente incorrecto. Aunque parecía que en ese momento no lo era (el / proc / mdstat progresó por encima del 99.9% normalmente, pero en realidad falló en el 99.97%, lo que determinó cuándo finalizaría la sincronización regular). Por lo tanto, debe verificar la
dmesg(1)salida: le dirá si hay algún error de lectura.Puede ver los detalles de mi caso en el error de Debian # 767243 . Finalmente logré terminar la sincronización al sobrescribir forzosamente algunos sectores defectuosos en el disco de origen (que por suerte no se utilizaron en mi caso, de lo contrario habría habido pérdida de datos)
fuente
Tu podrías intentar
para actualizar las unidades y volver a sincronizarlas.
fuente
/dev/sdb1aún no se está volviendo "activo" después de reconstruirse como repuesto.No estoy seguro de si funcionará ya que ya
--addeditó el disco, pero--re-addparece ser la opción que necesita.O tal vez lo que necesita
--growel dispositivo para 2 discos activos,mdadm --grow -n 2? No probado, así que ten cuidado.fuente
sudo mdadm --grow -n 2fue una de las primeras cosas que hice, por eso es quesudo mdadm --detail /dev/md0muestra dos máquinas tragamonedas. Lo siento, no funciona.Recomendaría eliminar sdc1, poner a cero el superbloque en sdc1 y luego volver a agregarlo.
fuente