ZFS en FreeBSD: recuperación de la corrupción de datos

44

Tengo varios TB de datos personales muy valiosos en un zpool al que no puedo acceder debido a la corrupción de datos. El grupo se configuró originalmente en 2009 en un sistema FreeBSD 7.2 que se ejecuta dentro de una máquina virtual VMWare en la parte superior de un sistema Ubuntu 8.04. FreeBSD VM todavía está disponible y funciona bien, solo el sistema operativo host ahora ha cambiado a Debian 6. Los discos duros se hacen accesibles a la VM invitada por medio de dispositivos SCSI genéricos VMWare, 12 en total.

Hay 2 piscinas:

  • zpool01: 2x 4x 500GB
  • zpool02: 1x 4x 160GB

El que funciona está vacío, el roto contiene todos los datos importantes:

[user@host~]$ uname -a
FreeBSD host.domain 7.2-RELEASE FreeBSD 7.2-RELEASE #0: \
  Fri May  1 07:18:07 UTC 2009                          \
  [email protected]:/usr/obj/usr/src/sys/GENERIC  amd64

[user@host ~]$ dmesg | grep ZFS
WARNING: ZFS is considered to be an experimental feature in FreeBSD.
ZFS filesystem version 6
ZFS storage pool version 6

[user@host ~]$ sudo zpool status
  pool: zpool01
 state: UNAVAIL
 scrub: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    zpool01     UNAVAIL      0     0     0  insufficient replicas
      raidz1    UNAVAIL      0     0     0  corrupted data
        da5     ONLINE       0     0     0
        da6     ONLINE       0     0     0
        da7     ONLINE       0     0     0
        da8     ONLINE       0     0     0
      raidz1    ONLINE       0     0     0
        da1     ONLINE       0     0     0
        da2     ONLINE       0     0     0
        da3     ONLINE       0     0     0
        da4     ONLINE       0     0     0

  pool: zpool02
 state: ONLINE
 scrub: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    zpool02     ONLINE       0     0     0
      raidz1    ONLINE       0     0     0
        da9     ONLINE       0     0     0
        da10    ONLINE       0     0     0
        da11    ONLINE       0     0     0
        da12    ONLINE       0     0     0

errors: No known data errors

Pude acceder a la piscina hace un par de semanas. Desde entonces, tuve que reemplazar casi todo el hardware de la máquina host e instalar varios sistemas operativos host.

Mi sospecha es que una de estas instalaciones de sistema operativo escribió un gestor de arranque (o lo que sea) en una (¿la primera?) De las unidades de 500 GB y destruyó algunos metadatos de zpool (o lo que sea), lo que significa que esto es solo una idea muy vaga y ese tema no es exactamente mi lado fuerte ...


Hay muchos sitios web, blogs, listas de correo, etc. sobre ZFS. Publico esta pregunta aquí con la esperanza de que me ayude a reunir suficiente información para un enfoque sensato, estructurado, controlado, informado y bien informado para recuperar mis datos, y espero ayudar a alguien más en la misma situación.


El primer resultado de búsqueda al buscar en Google 'zfs recovery' es el capítulo de Solución de problemas y recuperación de datos de ZFS de la Guía de administración de Solaris ZFS. En la primera sección de modos de falla de ZFS , dice en el párrafo 'Datos corruptos de ZFS':

La corrupción de datos siempre es permanente y requiere una consideración especial durante la reparación. Incluso si los dispositivos subyacentes se reparan o reemplazan, los datos originales se pierden para siempre.

Algo desalentador.

Sin embargo, el segundo resultado de la búsqueda de Google es el blog de Max Bruning y allí, leí

Recientemente, recibí un correo electrónico de alguien que tenía 15 años de videos y música almacenados en un grupo de 10 TB de ZFS que, después de una falla de energía, se volvió defectuoso. Él desafortunadamente no tenía una copia de seguridad. Estaba usando ZFS versión 6 en FreeBSD 7 [...] Después de pasar aproximadamente 1 semana examinando los datos en el disco, pude restaurar básicamente todos.

y

En cuanto a que ZFS pierda sus datos, lo dudo. Sospecho que sus datos están allí, pero necesita encontrar la forma correcta de obtenerlos.

(Eso suena mucho más como algo que quiero escuchar ...)

Primer paso : ¿Cuál es exactamente el problema?

¿Cómo puedo diagnosticar por qué exactamente se informa que el zpool está dañado? Veo que hay zdb que no parece estar documentado oficialmente por Sun u Oracle en ninguna parte de la web. Desde su página de manual:

NAME
       zdb - ZFS debugger

SYNOPSIS
       zdb pool

DESCRIPTION
       The  zdb  command is used by support engineers to diagnose failures and
       gather statistics. Since the ZFS file system is  always  consistent  on
       disk  and is self-repairing, zdb should only be run under the direction
       by a support engineer.

       If no arguments are specified, zdb, performs basic  consistency  checks
       on  the pool and associated datasets, and report any problems detected.

       Any options supported by this command are internal to Sun  and  subject
       to change at any time.

Además, Ben Rockwood ha publicado un artículo detallado y hay un video de Max Bruning hablando sobre esto (y mdb) en la Open Solaris Developer Conference en Praga el 28 de junio de 2008.

Ejecutar zdb como root en el zpool roto da el siguiente resultado:

[user@host ~]$ sudo zdb zpool01
    version=6
    name='zpool01'
    state=0
    txg=83216
    pool_guid=16471197341102820829
    hostid=3885370542
    hostname='host.domain'
    vdev_tree
        type='root'
        id=0
        guid=16471197341102820829
        children[0]
                type='raidz'
                id=0
                guid=48739167677596410
                nparity=1
                metaslab_array=14
                metaslab_shift=34
                ashift=9
                asize=2000412475392
                children[0]
                        type='disk'
                        id=0
                        guid=4795262086800816238
                        path='/dev/da5'
                        whole_disk=0
                        DTL=202
                children[1]
                        type='disk'
                        id=1
                        guid=16218262712375173260
                        path='/dev/da6'
                        whole_disk=0
                        DTL=201
                children[2]
                        type='disk'
                        id=2
                        guid=15597847700365748450
                        path='/dev/da7'
                        whole_disk=0
                        DTL=200
                children[3]
                        type='disk'
                        id=3
                        guid=9839399967725049819
                        path='/dev/da8'
                        whole_disk=0
                        DTL=199
        children[1]
                type='raidz'
                id=1
                guid=8910308849729789724
                nparity=1
                metaslab_array=119
                metaslab_shift=34
                ashift=9
                asize=2000412475392
                children[0]
                        type='disk'
                        id=0
                        guid=5438331695267373463
                        path='/dev/da1'
                        whole_disk=0
                        DTL=198
                children[1]
                        type='disk'
                        id=1
                        guid=2722163893739409369
                        path='/dev/da2'
                        whole_disk=0
                        DTL=197
                children[2]
                        type='disk'
                        id=2
                        guid=11729319950433483953
                        path='/dev/da3'
                        whole_disk=0
                        DTL=196
                children[3]
                        type='disk'
                        id=3
                        guid=7885201945644860203
                        path='/dev/da4'
                        whole_disk=0
                        DTL=195
zdb: can't open zpool01: Invalid argument

Supongo que el error 'argumento inválido' al final ocurre porque el zpool01 en realidad no existe: no ocurre en el zpool02 de trabajo, pero tampoco parece haber más resultados ...

OK, en esta etapa, probablemente sea mejor publicar esto antes de que el artículo sea demasiado largo.

Tal vez alguien pueda darme algún consejo sobre cómo avanzar desde aquí y mientras espero una respuesta, miraré el video, repasaré los detalles de la salida de zdb anterior, leeré el artículo de Bens e intentaré averiguar qué es qué...


20110806-1600 + 1000

Actualización 01:

Creo que he encontrado la causa raíz: Max Bruning tuvo la amabilidad de responder a un correo electrónico mío muy rápidamente, pidiendo la salida de zdb -lll. En cualquiera de los 4 discos duros en la 'buena' raidz1 mitad del grupo, la salida es similar a lo que publiqué anteriormente. Sin embargo, en las primeras 3 de las 4 unidades en la mitad 'rota', los zdbinformes failed to unpack labelpara las etiquetas 2 y 3. La cuarta unidad en el grupo parece estar bien, zdbmuestra todas las etiquetas.

Buscar en Google ese mensaje de error muestra esta publicación . Desde la primera respuesta a esa publicación:

Con ZFS, son 4 etiquetas idénticas en cada vdev físico, en este caso, un solo disco duro. L0 / L1 al comienzo de vdev y L2 / L3 al final de vdev.

Las 8 unidades del grupo son del mismo modelo, Seagate Barracuda 500GB . Sin embargo, recuerdo que comencé el grupo con 4 unidades, luego una de ellas murió y Seagate la reemplazó bajo garantía. Más tarde, agregué otras 4 unidades. Por esa razón, los identificadores de unidad y firmware son diferentes:

[user@host ~]$ dmesg | egrep '^da.*?: <'
da0:  <VMware, VMware Virtual S 1.0> Fixed Direct Access SCSI-2 device 
da1:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da2:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da3:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da4:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da5:  <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device 
da6:  <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device 
da7:  <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device 
da8:  <ATA ST3500418AS CC35> Fixed Direct Access SCSI-5 device 
da9:  <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 
da10: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 
da11: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 
da12: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 

Sin embargo, recuerdo que todas las unidades tenían el mismo tamaño. Mirando las unidades ahora, muestra que el tamaño ha cambiado para tres de ellas, se han reducido en 2 MB:

[user@host ~]$ dmesg | egrep '^da.*?: .*?MB '
da0:   10240MB (20971520  512 byte sectors: 255H 63S/T 1305C)
da1:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da2:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da3:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da4:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da5:  476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da6:  476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da7:  476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da8:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da9:  152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da10: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da11: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da12: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)

Por lo que parece, no fue una de las instalaciones del sistema operativo que 'escribió un gestor de arranque en una de las unidades' (como había supuesto antes), en realidad era la nueva placa base (un ASUS P8P67 LE ) que creaba un host de 2 MB área protegida al final de tres de las unidades que estropearon mis metadatos ZFS.

¿Por qué no creó un HPA en todas las unidades? Creo que esto se debe a que la creación de HPA solo se realiza en unidades más antiguas con un error que se corrigió más tarde mediante una actualización del BIOS del disco duro de Seagate: cuando todo este incidente comenzó hace un par de semanas, ejecuté SeaTools de Seagate para verificar si hay algo físicamente mal con las unidades (todavía en el hardware antiguo) y recibí un mensaje que me decía que algunas de mis unidades necesitan una actualización del BIOS. Como ahora estoy tratando de reproducir los detalles exactos de ese mensaje y el enlace a la descarga de la actualización del firmware, parece que desde que la placa base creó el HPA, ambas versiones SeaTools DOS no pueden detectar los discos duros en cuestión, un rápido invalid partitiono algo similar parpadea cuando comienzan, eso es todo. Irónicamente, sí encuentran un conjunto de unidades Samsung.

(Me he saltado los detalles dolorosos, que consumen mucho tiempo y, en última instancia, son infructuosos de enredar en un shell FreeDOS en un sistema no conectado en red). Al final, instalé Windows 7 en una máquina separada para ejecutar SeaTools Windows versión 1.2.0.5. Solo un último comentario sobre SeaTools de DOS: no se moleste en intentar arrancarlos de forma independiente; en su lugar, invierta un par de minutos y cree una memoria USB de arranque con el increíble Ultimate Boot CD , que además de DOS SeaTools también le ofrece muchos otros herramientas útiles

Cuando se inicia, SeaTools para Windows muestra este cuadro de diálogo:

Cuadro de diálogo de actualización de firmware de SeaTools

Los enlaces conducen al Verificador de número de serie (que por alguna razón está protegido por un captcha - mío era 'Usuarios invasivos') y un artículo de la base de conocimiento sobre la actualización del firmware. Probablemente haya más enlaces específicos para el modelo de disco duro y algunas descargas y demás, pero no seguiré ese camino por el momento:

No me apresuraré a actualizar el firmware de tres unidades a la vez que tienen particiones truncadas y son parte de un grupo de almacenamiento roto. Eso es pedir problemas. Para empezar, la actualización del firmware probablemente no se pueda deshacer, y eso podría arruinar irrevocablemente mis posibilidades de recuperar mis datos.

Por lo tanto, lo primero que haré a continuación es crear una imagen de las unidades y trabajar con las copias, por lo que hay un original al que volver si algo sale mal. Esto podría introducir una complejidad adicional, ya que ZFS probablemente notará que las unidades fueron intercambiadas (por medio del número de serie de la unidad u otro UUID o lo que sea), a pesar de que se trata de copias dd de bits exactos en el mismo modelo de disco duro. Además, el zpool ni siquiera está vivo. Chico, esto puede ser complicado.

Sin embargo, la otra opción sería trabajar con los originales y mantener las unidades duplicadas como copia de seguridad, pero probablemente me encuentre con la complejidad anterior cuando algo salga mal con los originales. Naa, no está bien.

Para limpiar los tres discos duros que servirán como reemplazos de imágenes para las tres unidades con el BIOS defectuoso en el grupo roto, necesito crear algo de espacio de almacenamiento para las cosas que están allí ahora, así que profundizaré la caja de hardware y ensamblar un zpool temporal de algunas unidades antiguas, que también puedo usar para probar cómo ZFS trata con el intercambio de unidades dd'd.

Esto podría tomar un tiempo...


20111213-1930 + 1100

Actualización 02:

Esto tomó un tiempo de hecho. Pasé meses con varias cajas de computadoras abiertas en mi escritorio con varias cantidades de pilas de discos duros colgando y también dormí algunas noches con tapones para los oídos, porque no podía apagar la máquina antes de acostarme, ya que estaba ejecutando una operación crítica prolongada . Sin embargo, ¡finalmente prevalecí! :-) También he aprendido mucho en el proceso y me gustaría compartir ese conocimiento aquí para cualquier persona en una situación similar.

Este artículo ya es mucho más largo de lo que cualquiera con un servidor de archivos ZFS fuera de acción tiene tiempo para leer, así que entraré en detalles aquí y crearé una respuesta con los hallazgos esenciales más abajo.

Cavé profundamente en la obsoleta caja de hardware para armar suficiente espacio de almacenamiento para mover las cosas de las unidades individuales de 500 GB a las que se reflejaron las unidades defectuosas. También tuve que extraer algunos discos duros de sus estuches USB, para poder conectarlos directamente a través de SATA. Hubo algunos problemas más, no relacionados, y algunas de las unidades antiguas comenzaron a fallar cuando las volví a poner en acción que requerían un reemplazo de zpool, pero omitiré eso.

Consejo: En algún momento, hubo un total de aproximadamente 30 discos duros involucrados en esto. Con tanto hardware, es de gran ayuda tenerlos apilados correctamente; los cables que se sueltan o el disco duro que se cae de su escritorio seguramente no ayudará en el proceso y pueden causar más daños a la integridad de sus datos.

Pasé un par de minutos creando algunos accesorios de disco duro de cartón improvisados ​​que realmente ayudaron a mantener las cosas ordenadas:

parte del espacio de almacenamiento improvisado solo un montón de tornillos más un poco de cartón el ventilador no es exactamente necesario, la pila es de un proyecto anterior las piezas de distancia tampoco son necesarias ...

Irónicamente, cuando conecté los discos viejos por primera vez, me di cuenta de que hay un viejo zpool allí que debo haber creado para probar con una versión anterior de algunos, pero no todos los datos personales que faltan, así que mientras la pérdida de datos fue algo reducido, esto significaba un desplazamiento adicional de un lado a otro de los archivos.

Finalmente, reflejé las unidades problemáticas en las unidades de respaldo, las usé para el zpool y dejé las originales desconectadas. Las unidades de respaldo tienen un firmware más nuevo, al menos SeaTools no informa de ninguna actualización de firmware requerida. Hice la duplicación con un simple dd de un dispositivo a otro, por ejemplo

sudo dd if=/dev/sda of=/dev/sde

Creo que ZFS nota el cambio de hardware (por algún UUID del disco duro o lo que sea), pero no parece importarle.

Sin embargo, el zpool todavía estaba en el mismo estado, réplicas insuficientes / datos dañados.

Como se menciona en el artículo de HPA Wikipedia mencionado anteriormente, la presencia de un área protegida de host se informa cuando Linux arranca y puede investigarse usando hdparm . Hasta donde yo sé, no hay una herramienta hdparm disponible en FreeBSD, pero en este momento, tenía FreeBSD 8.2 y Debian 6.0 instalados como sistema de arranque dual, así que arranqué en Linux:

user@host:~$ for i in {a..l}; do sudo hdparm -N /dev/sd$i; done

   ...
/dev/sdd:
 max sectors   = 976773168/976773168, HPA is disabled
/dev/sde:
 max sectors   = 976771055/976773168, HPA is enabled
/dev/sdf:
 max sectors   = 976771055/976773168, HPA is enabled
/dev/sdg:
 max sectors   = 976771055/976773168, HPA is enabled
/dev/sdh:
 max sectors   = 976773168/976773168, HPA is disabled
   ...

Entonces, el problema obviamente era que la nueva placa base creó un HPA de un par de megabytes al final de la unidad que 'ocultó' las dos etiquetas superiores ZFS, es decir, impidió que ZFS las viera.


Jugar con la HPA parece un negocio peligroso. Desde la página de manual de hdparm, parámetro -N:

Get/set max visible number of sectors, also known as the Host Protected Area setting.
  ...
To change the current max (VERY DANGEROUS, DATA LOSS IS EXTREMELY LIKELY), a new value
should be provided (in base10) immediately following the -N option.
This value is specified as a count of sectors, rather than the "max sector address"
of the drive. Drives have the concept of a temporary (volatile) setting which is lost on
the next hardware reset, as well as a more permanent (non-volatile) value which survives
resets and power cycles.  By default, -N affects only the temporary (volatile) setting.
To change the permanent (non-volatile) value, prepend a leading p character immediately
before the first digit of the value. Drives are supposed to allow only a single permanent
change per session. A hardware reset (or power cycle) is required before another
permanent -N operation can succeed.
  ...

En mi caso, el HPA se elimina así:

user@host:~$ sudo hdparm -Np976773168 /dev/sde

/dev/sde:
 setting max visible sectors to 976773168 (permanent)
 max sectors   = 976773168/976773168, HPA is disabled

y de la misma manera para las otras unidades con un HPA. Si obtiene la unidad incorrecta o algo sobre el parámetro de tamaño que especifique no es plausible, hdparm es lo suficientemente inteligente como para saber:

user@host:~$ sudo hdparm -Np976773168 /dev/sdx

/dev/sdx:
 setting max visible sectors to 976773168 (permanent)
Use of -Nnnnnn is VERY DANGEROUS.
You have requested reducing the apparent size of the drive.
This is a BAD idea, and can easily destroy all of the drive's contents.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.

Después de eso, reinicié la máquina virtual FreeBSD 7.2 en la que se había creado originalmente el zpool y el estado de zpool informó un grupo de trabajo nuevamente. ¡HURRA! :-)

Exporté el grupo en el sistema virtual y lo volví a importar en el sistema host FreeBSD 8.2.

Algunas actualizaciones de hardware más importantes, otro intercambio de placa base, una actualización del conjunto de ZFS a ZFS 4/15, una limpieza exhaustiva y ahora mi zpool consta de 8x1TB más 8x500GB de piezas raidz2:

[user@host ~]$ sudo zpool status
  pool: zpool
 state: ONLINE
 scrub: none requested
config:

NAME        STATE     READ WRITE CKSUM
zpool       ONLINE       0     0     0
  raidz2    ONLINE       0     0     0
    ad0     ONLINE       0     0     0
    ad1     ONLINE       0     0     0
    ad2     ONLINE       0     0     0
    ad3     ONLINE       0     0     0
    ad8     ONLINE       0     0     0
    ad10    ONLINE       0     0     0
    ad14    ONLINE       0     0     0
    ad16    ONLINE       0     0     0
  raidz2    ONLINE       0     0     0
    da0     ONLINE       0     0     0
    da1     ONLINE       0     0     0
    da2     ONLINE       0     0     0
    da3     ONLINE       0     0     0
    da4     ONLINE       0     0     0
    da5     ONLINE       0     0     0
    da6     ONLINE       0     0     0
    da7     ONLINE       0     0     0

errors: No known data errors

[user@host ~]$ df -h
Filesystem         Size    Used   Avail Capacity  Mounted on
/dev/label/root     29G     13G     14G    49%    /
devfs              1.0K    1.0K      0B   100%    /dev
zpool              8.0T    3.6T    4.5T    44%    /mnt/zpool

Como última palabra, me parece que los grupos de ZFS son muy, muy difíciles de matar. Los chicos de Sun que crearon ese sistema tienen todos los motivos para llamarlo la última palabra en los sistemas de archivos. ¡El respeto!

ssc
fuente
2
Antes de hacer nada, ¡imagina esas unidades! Haga una copia de seguridad de sus datos "corruptos" en caso de que empeore.
MikeyB
sí, ese es un muy buen punto! y es también la razón por la que no he actualizado este artículo con mi progreso todavía - todavía ocupado la limpieza de los discos duros de repuesto ...
SSC

Respuestas:

24

El problema era que el BIOS de la nueva placa base creaba un área protegida de host (HPA) en algunas de las unidades, una pequeña sección utilizada por los OEM para fines de recuperación del sistema, generalmente ubicada al final del disco duro.

ZFS mantiene 4 etiquetas con metainformación de partición y el HPA evita que ZFS vea las dos superiores.

Solución: Inicie Linux, use hdparm para inspeccionar y eliminar el HPA. Tenga mucho cuidado, esto puede destruir fácilmente sus datos para siempre. Consulte el artículo y la página de manual de hdparm (parámetro -N) para más detalles.

El problema no solo ocurrió con la nueva placa base, tuve un problema similar al conectar las unidades a una tarjeta controladora SAS. La solución es la misma.

ssc
fuente
5

Lo primero que recomendaría que haga es obtener algunos discos duros más y hacer copias duplicadas de las 8 unidades que tiene con sus datos, utilizando el ddcomando. De esa manera, si en sus intentos de recuperarlos termina empeorando las cosas, aún puede volver a esta línea de base.

He hecho esto antes y hubo momentos en que no lo necesitaba, pero las veces que lo hice hicieron que valiera la pena el esfuerzo.

No trabajes sin una red.

Sean Reifschneider
fuente
En realidad, recomendaría ddrescuemás dd. Realmente no funciona de manera muy diferente cuando las unidades funcionan perfectamente (pero le da una buena indicación de progreso), pero si hay sectores problemáticos o algo así, ddrescue maneja esa situación mucho mejor que dd (o eso es lo que yo hago). me han dicho).
un CVn
2

Parece que estás en camino de resolver esto. Si desea otro punto de vista más nuevo y posible, puede probar un Live CD de Solaris 11 Express. Es probable que haya un código mucho más nuevo allí (zpool en Solaris ahora está en la versión 31, mientras que usted está en la versión 6) y podría ofrecer mejores posibilidades de recuperación. Sin zpool upgradeembargo, no se ejecute con Solaris si desea mantener el grupo montable en FreeBSD.

Jakob Borg
fuente
Gracias por ese consejo! :-) Estaba investigando OpenSolaris en 2009 cuando comencé todo este negocio de ZFS, pero desafortunadamente, no era compatible con los controladores que estoy usando, después de todo, este es hardware de nivel de consumidor. Recientemente, también he visto OpenIndiana, pero no estoy seguro de si la situación ha cambiado. Podría actualizar los controladores a SAS en algún momento y considerar migrar entonces.
ssc
Creo que OpenIndiana podría valer una nueva mirada. Por lo menos, podrían ser más amigables con el hardware "barato" que Oracle ... Le recomendé el CD en vivo porque es fácil de probar, también puede ejecutarlo en una VM.
Jakob Borg
1

Las listas de correo de FreeBSD pueden ser un buen punto de partida para su búsqueda. Recuerdo haber visto solicitudes similares en FreeBSD-Stable y -Current. Sin embargo, según la importancia de sus datos, es posible que desee ponerse en contacto con una empresa de recuperación profesional, ya que la manipulación de los grupos de almacenamiento de datos inaccesibles tiene una buena posibilidad de empeorar las cosas.

Andreas Turriff
fuente
1

Experimenté un problema similar después de actualizar de FreeBSD 10.3 a 11.1, luego el zpool falló y no hubo forma de recuperar los datos, a pesar de que zdb -llllas cuatro etiquetas fueron válidas.

Resulta que de alguna manera la actualización activó los controladores de administración de almacenamiento de Intel para crear un espejo softraid de los discos (¿tal vez fue habilitado pero no fue compatible con geomel proveedor de Intel hasta la actualización posterior?) Y eso impidió que ZFS montara los discos.

Adjuntarlos a otra PC con el firmware Intel RST de tiempo de arranque habilitado y deshabilitar el softraid ( muy importante: hay dos formas de romper el softraid, el valor predeterminado es el que inicializa (también conocido como formatos) los discos. Debe elegir la opción para desactivar en su lugar sin tocar los datos) y luego dejar que ZFS reconozca el primer disco en el espejo, aunque nada de lo que hice le permitiría identificar los discos restantes como los mismos que estaban en la actualización previa de la máquina. Afortunadamente, era un zpool reflejado y pude simplemente separar y volver a colocar los discos en el grupo en cuestión y el resilver se completó sin eventos.

Nota al margen: en mi caso, hdparm(ejecutándose desde un ISO de servidor Ubuntu en vivo) informó que HBA estaba deshabilitado en todos los discos y no podía ayudar.

Mahmoud Al-Qudsi
fuente
-2

si fuera solo un problema de partición de algún tipo, haría las particiones del disco + MBR y simplemente haría la partición del tamaño correcto ...

si no formatea una partición, la creación o el cambio de la tabla de partición no afecta nada (¡así que puede revertirlo!) siempre que no haya formato, la mayoría de los datos aún estarán allí / accesibles si se inserta la nueva partición al final de la unidad, es posible que tenga archivos corruptos allí donde se escribieron las cosas nuevas, por eso es que solo es bueno para ese truco hasta que formatee (nuevo mbr, tabla de archivos, etc.)

npn
fuente