Como recuperar un metadispositivo con DiskSuite

Titulo: Solstice Disksuite, como recuperar un metadispositivo que está en estado inetable o como recrear un md sin perder datos.

Productos: Solstice DiskSuite 4.2.1, Solaris Volume Manager, Solstice DiskSuite 4.0 (japones), Solstice DiskSuite 4.1(japones), Solstice DiskSuite 4.1 Software, Solstice DiskSuite 4.2 Software

Área: LVM Logical Volume Management

Descripción:

Rara vez un dispositivo lógico queda en estado indefinido, por lo que recuperarlo suele ser algo problemático.

Este procedimiento es para recrearlo luego de que hallamos guardado la configuración actual con un metastat -p. Este procedimiento es algo riesgoso por lo que es altamente recomendable tener hecho un backup completo de la información.

Documento:

Ejemplos de cuando debo usar este procedimiento:

1. El mirror tiene sus dos componentes en “Needs Maintenance” y los comandos comunes no me sirven para limpiar el “Last Erred”.

2. Uno de los submirror tiene un error de I/O no fatal y está en “needs maintenance”. En este momento es muy dificil poner el mirror nuevamente en linea.

3. Puede haber habido un reboot o una reconfiguración y uno de los dispositivos cambió de controladora o de target.

4. Cuando un submirror está en OK de un mirror y se va a un estado stale y la otra parte del mirror está OK pero sin información, y si usaramos el “metareplace -e” nos haría perder toda la información.

Ejemplos de cuando no debo usar este procedimiento:

1. Un submirror está en “Need Maintenance” y el otro en “Last erred”.

2. Un submirror con datos validos está en OK y el otro en “Last erred” o “Need Maintenance”

Para estos casos use el procedimiento normal de recuperación.

Este documento puede ser utilizado con todas las versiones de DiskSuite. Tener en cuenta que en las versiones anteriores a DiskSuite 4.2.1 los comandos se encuentran en /usr/opt/SUNWmd/sbin así que recomendamos agregar este directorio a su PATH antes de comenzar a trabajar. Para hacer esto tipee:

PATH=$PATH:/usr/opt/SUNWmd/sbin

en las otras versiones de DiskSuite los comandos están en /usr/sbin que es el path del root.

Procedimiento de recuperado:

Con Solaris Volume Manager se puede limpiar cualquier metadispositivo y luego volver a recrearlo sin perder información. El siguiente ejemplo, con el dispositivo d8 que no puede ser reparado, nos muestra el procedimiento para recuperarlo.

Paso 1: Examine la salida del metastat para determinar el estado del mirro y los submirrors.

# metastat [-s setname] d8

d8: Mirror
Submirror 0: d82
State: Needs Maintenance
Submirror 1: d83
State: Needs Maintenance
Pass:1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 35307016 (16Gb)

En este ejemplo, ambos submirror necesitan mantenimiento. Si uno de los dos se encontrara en "Last Erred" use el procedimiento normal de recuperación. Y si este procedimiento no le funcionó continue con el siguiente paso.

Paso 2: Determine si uno de los dos submirro se encuentra activo.

El proposito de este paso es determinar cual de los dos submirror utilizar como principal para luego recrearlo. Si usted ya tiene esta información, o si el mirror solo posee un componente puede obviar este paso.
Use iostat para determinar cual es el submirror activo:

# iostat -xnz 10 6 (el -z no muestra las líneas en cero)

aquí podremos ver a que metadispositivo estamos accediendo.

Paso 3: Para tener una copia de los dispositivos originales capturemos el metastat -p para el dispositivo que tenga fallas

# metastat [-s setname] -p d8 | tee d8.metastat

d8 -m d82 d83 1
d82 1 1 c1t2d0s0
d83 1 1 c1t3d0s0
(esta información también puede ser extraida de un explorer viejo)

Paso 4: Verifique por la existencia de cualquier softpartition creadas sobre este dispositivo

# metastat [-s setname] -p | grep d8 | tee d8.sp

d8 -m d82 d83 1
d82 1 1 c1t2d0s0
d83 1 1 c1t3d0s0
d106 -p d8 -0 28286982 -b 1433600
d105 -p d8 -o 29720583 -b 2097152
d104 -p d8 -o 27262981 -b 1024000
d103 -p d8 -o 25165828 -b 2097152
d102 -p d8 -o 20971523 -b 4194304
d101 -p d8 -o 8388610 -b 12582912 -o 31817736 -b 3481600
d100 -p d8 -o 1 -b 8388608

En este ejemplo tenemos 7 soft partition sobre el mirror. No continue sin haber antes capturado estos datos. Tenga la precaución que el grep puede haberle capturado información de otros dispositivos aparte del que estamos queriendo reparar.

Como una alternativa para los pasos 3 y 4, asegurese que el md.tab está actualizado.

Para el Solstice DiskSuite 4.2.1 y el Solaris Volume Manager:
# mv /etc/lvm/md.tab /etc/lvm/md.tab.old
# metastat [-s setname] -p > /etc/lvm/md.tab

Para versiones anteriores el md.tab no se encuentra en el mismo lugar sino que debemos proceder como se muestra abajo:

# mv /etc/opt/SUNWmd/md.tab /etc/opt/SUNWmd/md.tab.old
# metastat [-s setname] -p > /etc/opt/SUNWmd/md.tab

Paso 5:
Use los comandos como el "df -k" y el "swap -l" para observar todos los filesystems y aplicaciones que están utilizando este metadispositivo.

a) Mire todos los file systems:

# df -k | grep /dev/md/dsk/d8

En este ejemplo no hay filesystem porque el d8 es solo la base para las softpartitions por lo cual los filesystems deberian estar sobre las mismas.

b) busque los dispositivos swap

# swap -l | grep /dev/md/dsk/d8

En este ejemplo no hay dispositivos swap sobre este dispositivo. Si los hubiera deberiamos usar los procedimientos normales para agregar dispositivos swap mientras este se encuentra momentaneamente fuera de línea.

Paso 6: En el paso 4 hemos encontrados soft partition sobre el mirror, debemos encontrar y resguardar los filesystems relevantes, usando el grep para encontrar los patrones que estamos buscando.

# df -k | grep /dev/md/dsk/d10 | awk '{ print $6 }'

/data
/data/packages
/data/crash
/data/dl
/data/install
/data/patches
/data/samba

Paso 7: Borre los metadispositivos soft partition

# metaclear [-s setname] d100
# metaclear [-s setname] d101
# metaclear [-s setname] d102
# metaclear [-s setname] d103
# metaclear [-s setname] d104
# metaclear [-s setname] d105
# metaclear [-s setname] d106

Haga esto uno a uno o use el siguiente comando para todas las particiones

# metaclear [-s setname] -p

Paso 8: Borre recursivamente el mirror (puede necesitar la opción -f)

# metaclear [-s setname] -r d8

Paso 9: Recree los metadispositivos, primero creando los submirrors

# metainit [-s setname] d82 1 1 c1t2d0s0
# metainit [-s setname] d8 -m d82

El submirror usado para que sea el principal es el d82. En el paso 2 vimos que solo había I/O en uno de los submirror, el cual es el mismo que estamos utilizando en este paso.

Si en el paso 1 nos muestra como que uno de los submirror está en "Last Erred", entonces aquí use ese submirror como principal en este paso.

Si nuestro caso es como el pto 4 descripto en los casos en los que debemos usar este procedimiento, entonces en este paso debemos utilizar el submirror con datos validos como submirror principal.

Repase muy bien este punto antes de hacerlo ya que un error puede acarrear la perdida total de la información.

Paso 10: Recrear las softpartition, esto puede ser realizado mientras el d8 se termina de sincronizar.

# metainit [-s setname] d100 -p d8 -o 1 -b 8388608
# metainit [-s setname] d101 -p d8 -o 8388610 -b 12582912 -o 31817736 -b 3481600
# metainit [-s setname] d102 -p d8 -o 20971523 -b 4194304
# metainit [-s setname] d103 -p d8 -o 25165828 -b 2097152
# metainit [-s setname] d104 -p d8 -o 27262981 -b 1024000
# metainit [-s setname] d105 -p d8 -o 29720583 -b 2097152
# metainit [-s setname] d106 -p d8 -o 28286982 -b 1433600

Paso 11 (opcional) si el tiempo lo permite usted puede realizar un fsck -n a cada uno de los filesystem

Si el fsck falla en seguida, deberíamos recrear los metadispositivos que se encuentren en estado incorrecto. Si el fsck encuentra otro errores , estos errores pueden que ya hallan estado en los filesystem originales pero no pudieron ser generados por este procedimiento.

Paso 12: Monte los filesystem como estaban originalmente.

Si el montaje falla puede que deba recrear los metadispositivos incorrectos. Para recuperarlos use el metaclear y el metainit nuevamente.

Paso 13: Una vez que hallamos confirmado que tenemos nuestros datos intactos podemos atachar los otros componentes del mirror

# metainit [-s setname] d83 1 1 c1t3d0s0
# metattach [-s setname] d8 d83

Usando este procedimiento para otro tipo de metadispositivos:
- Raid 5: este mismo procedimiento puede ser utilizado para el Raid 5. La opción -k. Cuando estamos rearmando los dispositivos en el paso 9 la opción -k es de gran importancia. Esta opción le dice al SVM que no inicialice los metadispositivos para usar los datos que ya se encuentran en el disco. No hacer esto puede causar la perdida total de los datos.

- Concatenado o stripe (o los dos): este procedimiento puede ser utilizado en este caso y el uso del metainit y el metaclear no afecta a los datos del usuario. Es muy importante que al recrear el stripe o el concat cada componente sea recreado en el mismo orden. Si no lo hacemos exactamente de la misma forma no perderemos los datos, mientras que los datos (filesystem) no sean modificado (como con un fsck -y). Si accidentalmente recreamos el stripe en el orden equivocado simplemente debemos borrarlo con el metaclear y recrearlo en el orden correcto. Si no conocemos el orden correcto, simplemente repita los pasos del metainit y luego ejecute el fsck -n antes que fsck se complete correctamente.

Usando este procedimiento con los números de las controladoras cambiados:
Este procedimiento puede ser utilizado cuando un reboot de reconfiguración cambió el número de controladora de los dispositivos c#. Simplemente edite y guarde los archivos para reflejar el nuevo número de controladora. Cuando el número de la controladora cambió, es necesario reiniciar todas las meta database (MDBs) en esa controladora.

Trabajando con MDBs embebidas
Con MDBs es cualquier submirror o slice del dispositivo que hallamos recreado y que tenga "Yes" bajo el Dbase en la salida del metastat.
Las MDBs no afectan a este procedimiento. Los metadispositivos pueden ser limpiados e inicializados sin tocar las MDBs embebidas. Si usamos este procedimiento como parte de un cambio de número de controladora, deberiamos reinicializar todas las MDBs. El uso de MDBs no es lo mejor y debemos considerar eliminarlas en un futuro .

(Extraido y traducido del artículo 76077 de Sun Solve)