Solución de la comunidad

Recuperar un RAID 1 de ZimaOS después de reinstalar el sistema

A ZimaOS 1.6.1 user documented a real RAID 1 recovery after reinstalling the OS, using read-only verification, an external offload copy, a native UI rebuild, and a verified restore.

Si se reinstala ZimaOS y un RAID 1 existente aparece como discos sin usar, no hagas clic inmediatamente en Crear RAID. Recrear o formatear la matriz puede destruir los datos que aún están presentes en los discos miembros.

La primera vía de recuperación debe ser el método oficial actual de ZimaOS: restaurar el archivo guardado local-storage.db archivo de la instalación anterior del sistema. El tutorial de la comunidad en el que se basa esta página documenta una alternativa más invasiva para el caso más difícil en el que no se hizo una copia de seguridad de esa base de datos. Esa alternativa se probó en ZimaOS 1.6.1, pero incluye operaciones destructivas de RAID y solo debe considerarse después de copiar y verificar los datos de origen de forma independiente.

Primera opción: restaurar local-storage.db

ZimaOS guarda la información de configuración del almacenamiento en:

/ZimaOS-HD/.casaos/db/local-storage.db

La guía oficial de recuperación actual recomienda descargar este archivo antes de reinstalar el sistema y volver a colocarlo en el mismo directorio después de la nueva instalación de ZimaOS y de reiniciar.

Recuperación oficial de RAID de ZimaOS después de la reinstalación

Si todavía tienes acceso al disco del sistema anterior, intenta recuperar esta base de datos antes de tocar los discos miembros del RAID.

Por qué la matriz de datos aún puede estar intacta

ZimaOS utiliza RAID por software de Linux. Los discos miembros pueden conservar los metadatos RAID incluso cuando la nueva instalación de ZimaOS ya no tiene la base de datos de almacenamiento anterior. Por eso los discos pueden aparecer físicamente presentes mientras la interfaz ya no reconoce el grupo de almacenamiento original.

ZimaOS 1.6 también introdujo mejoras en la recuperación de metadatos RAID y en el comportamiento de reidentificación, por lo que no debe suponerse que un problema observado originalmente en un sistema se produzca de forma idéntica en cada versión más reciente.

No crees un RAID nuevo hasta decidir cómo realizar la recuperación

Si los discos contienen datos que necesitas, evita:

  • formatear cualquiera de los discos miembros;
  • crear un RAID nuevo sobre los mismos discos;
  • ejecutar wipefs o mdadm --zero-superblock prematuramente;
  • adivinar cuál /dev/sdX cuál es el dispositivo.

Antes de realizar cualquier trabajo de recuperación, identifica los discos por modelo, número de serie y capacidad, en lugar de confiar únicamente en las letras de dispositivo.

Verificar los metadatos RAID en modo de solo lectura

El autor de la comunidad utilizó primero una inspección de solo lectura para confirmar que ambos miembros del RAID 1 seguían perteneciendo a la misma matriz.

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE,MODEL,SERIAL

mdadm --examine /dev/sda
mdadm --examine /dev/sdb

Para que un RAID 1 esté en buen estado, ambos miembros deben informar del mismo UUID de matriz y de metadatos RAID compatibles. Si falta un miembro, está degradado o informa de metadatos diferentes, detente y solicita asistencia para la recuperación en lugar de seguir una receta de reconstrucción genérica.

Ensambla y monta la matriz antigua en modo de solo lectura

Para una recuperación avanzada, ensamblar la matriz en modo de solo lectura reduce la probabilidad de modificar la fuente mientras se verifica que los archivos sean accesibles:

mdadm --assemble --readonly /dev/md127 /dev/sda /dev/sdb

mkdir -p /DATA/oldraid
mount -o ro /dev/md127 /DATA/oldraid

Después inspecciona el sistema de archivos:

df -h /DATA/oldraid
ls -la /DATA/oldraid
du -sh /DATA/oldraid/*

Los nombres de dispositivo anteriores son solo ejemplos. Nunca los pegues sin modificarlos a menos que hayas confirmado que coinciden con tu hardware.

Crea una copia completa externa antes de realizar cualquier paso destructivo

El flujo de trabajo original utilizaba una unidad externa ext4 con capacidad suficiente para contener todos los datos usados del RAID. Para los datos de aplicaciones de Linux, ext4 resulta útil porque puede conservar la propiedad, los permisos, los enlaces, las ACL y los atributos extendidos habituales.

Una copia típica con estilo de archivado es:

rsync -aHAX --info=progress2   /DATA/oldraid/   /DATA/offload/

Ejecuta la copia en tmux o utiliza otro terminal persistente si, de lo contrario, una desconexión de SSH interrumpiría el proceso.

Verifica la copia de seguridad antes de continuar

No dependas únicamente de la línea de salida de rsync. Compara el número de archivos e inspecciona los tamaños de los directorios principales:

find /DATA/oldraid -xdev -type f | wc -l
find /DATA/offload -xdev -type f | wc -l

du -sh /DATA/oldraid/*
du -sh /DATA/offload/*

Para los datos irreemplazables, es preferible contar con una segunda copia de seguridad independiente. RAID no es una copia de seguridad por sí mismo.

Último recurso: descargar los datos, eliminar los metadatos del RAID antiguo y recrearlo en la interfaz

El autor original de la comunidad quería que la matriz recuperada volviera a administrarse normalmente desde la interfaz de ZimaOS. Su método de último recurso era:

  1. verifica la matriz antigua en modo de solo lectura;
  2. copia todos los datos en una unidad externa;
  3. verifica la copia;
  4. detén la matriz md antigua;
  5. elimina los metadatos del RAID antiguo;
  6. crea un RAID 1 nuevo mediante la interfaz de almacenamiento de ZimaOS;
  7. restaura los archivos copiados;
  8. verifica los datos restaurados.

Este procedimiento destruye intencionadamente los metadatos del RAID antiguo. Una vez realizado este paso, la copia externa se convierte en la fuente de recuperación. No utilices este método si la copia está incompleta o no estás seguro de la identidad de los dispositivos.

El comando irreversible del flujo de trabajo original

El procedimiento utilizado por la comunidad:

mdadm --zero-superblock /dev/sda /dev/sdb

Este no es un comando de resolución de problemas. Elimina los metadatos RAID de los discos especificados. Una ruta de dispositivo incorrecta puede provocar una pérdida de datos grave.

Por ese motivo, esta página no recomienda ejecutarlo simplemente porque la interfaz de ZimaOS no reconozca un RAID. Restaurar local-storage.db, comprueba el comportamiento actual de recuperación de ZimaOS y contacta primero con el servicio de soporte cuando el conjunto contenga datos importantes.

¿Por qué recrear el conjunto mediante la interfaz de ZimaOS?

El objetivo del flujo de trabajo de origen era terminar con un conjunto de almacenamiento administrado normalmente por ZimaOS, en lugar de un dispositivo md ensamblado manualmente de forma permanente fuera de la interfaz de almacenamiento.

Después de descargar de forma segura los datos antiguos y restablecer intencionadamente los discos, utiliza la interfaz de Almacenamiento actual para crear un RAID 1 y deja que se complete la sincronización inicial.

Restaura los archivos en el nuevo conjunto

Después de crear y montar el nuevo conjunto, restaura los datos desde el disco de descarga:

rsync -aHAX --info=progress2   /DATA/offload/   /media/Storage/

Reemplaza /media/Storage con la ruta de destino real que muestre tu sistema.

Verifica el conjunto de almacenamiento restaurado

find /DATA/offload -xdev -type f | wc -l
find /media/Storage -xdev -type f | wc -l
du -sh /media/Storage/*
cat /proc/mdstat

Mantén la unidad de descarga intacta hasta que la sincronización del RAID se complete y hayas verificado el acceso normal mediante la interfaz Archivos de ZimaOS y las aplicaciones que dependen de los datos.

Haz una copia de seguridad de local-storage.db antes de la próxima reinstalación

La recuperación más sencilla es la que se prepara con antelación. Conserva una copia actualizada de:

/ZimaOS-HD/.casaos/db/local-storage.db

fuera de la unidad del sistema. La documentación oficial ahora proporciona un procedimiento directo de restauración mediante este archivo.

¿Qué ruta de recuperación deberías elegir?

Situación Acción preferida
Hiciste una copia de seguridad de local-storage.db Usa el método oficial para restaurar la base de datos
El disco del sistema antiguo todavía se puede leer Recupera local-storage.db antes de modificar los discos del RAID
No hay copia de seguridad de la base de datos; los metadatos del RAID parecen estar en buen estado Pausa las acciones destructivas y solicita asistencia u orientación sobre recuperación
Tienes una copia completa y verificada de los datos descargados y quieres intencionadamente una matriz limpia administrada desde la interfaz Considera el método comunitario de descargar, recrear y restaurar
Los miembros del RAID muestran metadatos no coincidentes o degradados Detente y utiliza orientación de especialistas en recuperación

Preguntas frecuentes sobre la recuperación de RAID en ZimaOS

¿Reinstalar ZimaOS borra automáticamente los datos del RAID?

No. Reinstalar el disco del sistema es diferente de formatear los discos miembros del RAID. La configuración de almacenamiento puede perderse mientras los metadatos y los datos del RAID permanecen en los discos miembros.

¿Debería hacer clic en «Crear RAID» si los discos antiguos aparecen como no utilizados?

No, hasta que hayas confirmado que no es necesario recuperar ningún dato existente. Crear un RAID nuevo puede ser destructivo.

¿Cuál es la recuperación más segura si hice una copia de seguridad de local-storage.db?

Usa el procedimiento oficial actual de ZimaOS para restaurar esa base de datos y reinicia.

¿Es seguro poner a cero el superbloque de mdadm?

Es intencionalmente destructivo para los metadatos de RAID. Úsalo únicamente como parte de un plan de recuperación verificado después de haber copiado los datos de forma segura en otro lugar.