4 Recuperación de sistemas de archivos

En esta sección, se indican los procesos de recuperación que se utilizan cuando un sistema de archivos Oracle HSM completo se daña o se pierde. Los procedimientos varían según el tipo de sistema de archivos implicados y de copia de seguridad y los preparativos de recuperación que haya realizado. Sin embargo, hay dos tareas básicas que debe realizar:

Recreación del sistema de archivos
Restauración de directorios y archivos.

Antes de comenzar, tenga en cuenta lo siguiente: si está realizando la recuperación desde la pérdida de un servidor de metadatos Oracle HSM, antes de continuar, asegúrese de haber finalizado la Restauración de la configuración de Oracle HSM, como se describe en el Capítulo 3. Los procedimientos de este capítulo asumen que el software Oracle HSM está instalado y configurado como estaba antes de la pérdida del sistema de archivos.

Recreación del sistema de archivos

Antes de poder recuperar archivos y directorios, debe contar con una ubicación para colocarlos. De modo que el primer paso del proceso de recuperación es crear un sistema de archivos vacío de reemplazo. Siga estos pasos:

Vuelva a crear el sistema de archivos mediante el uso de archivos de configuración de copia de seguridad y el comando `sammkfs`

Inicie sesión en el servidor de metadatos del sistema de archivos como usuario root.
```
root@solaris:~# 
```
Desmonte el sistema de archivos, si actualmente está montado. Utilice el comando umount mount-point, donde mount-point es el directorio en el que se monta el sistema de archivos.

En el ejemplo, desmontamos el sistema de archivos /samqfs1:
```
root@solaris:~# umount /samqfs1
root@solaris:~# 
```

Abra el archivo /etc/opt/SUNWsamfs/mcf y en un editor de texto. Compruebe la configuración del hardware. Si ha tenido que cambiar hardware, edite el archivo como corresponda y guarde los cambios.

En el ejemplo, se sustituyen los identificadores del equipo para dos dispositivos de disco que fallaron con los de sus reemplazos. Tenga en cuenta que los ordinales del equipo permanecerán sin cambios:

root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
# Equipment              Equipment  Equipment  Family     Device  Additional
# Identifier             Ordinal    Type       Set        State   Parameters
#----------------------- ---------  ---------  ---------  ------  -------------
samqfs1                  100        ms         samqfs1    on
 /dev/dsk/c1t3d0s3        101        md         samqfs1    on
 /dev/dsk/c1t4d0s5        102        md         samqfs1    on 
# Tape library
/dev/scsi/changer/c1t2d0 800        rb         lib800     on     .../lib800_cat
 /dev/rmt/0cbn            801        li         lib800     on
 /dev/rmt/1cbn            802        li         lib800     on
:wq
root@solaris:~#

Revise el archivo mcf para detectar errores. Utilice el comando sam-fsd.

El comando sam-fsd lee los archivos de configuración Oracle HSM e inicializa el software. Se detendrá si detecta un error:
```
root@solaris:~# sam-fsd
```
Si el comando sam-fsd encuentra un error en el archivo mcf, edite el archivo para corregir el error y vuelva a realizar la comprobación, como se describe en el paso anterior.

En el siguiente ejemplo, sam-fsd informa un problema no especificado con un dispositivo. Probablemente se trata de un error tipográfico en un campo de identificador de equipo:
```
root@solaris:~# sam-fsd
Problem in mcf file /etc/opt/SUNWsamfs/mcf for filesystem qfsms
sam-fsd: Problem with file system devices.
```
Generalmente, dichos errores son el resultado de errores de tipeo involuntarios. Aquí, cuando abrimos el archivo mcf en un editor, observamos que hemos escrito una letra o en lugar de 0 en la parte del número de segmento del nombre de equipo del dispositivo 102, el segundo dispositivo md:
```
root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
...
qfsms                100        ms         qfsms      on       
  /dev/dsk/c0t0d0s0   101        md         qfsms      on
  /dev/dsk/c0t3d0so   102        md         qfsms      on
```
A fin de corregir el error, guarde el archivo y vuelva a comprobar:
```
root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
...
qfsms                100        ms         qfsms      on       
  /dev/dsk/c0t0d0s0   101        md         qfsms      on
  /dev/dsk/c0t3d0s0   102        md         qfsms      on
:wq
root@solaris:~# sam-fsd
```

Cuando el comando sam-fsd se ejecuta sin errores, el archivo mcf es correcto. Continúe con el siguiente paso.

En el ejemplo, sam-fsd se ejecuta sin error:

root@solaris:~# sam-fsd
Trace file controls:
sam-amld      /var/opt/SUNWsamfs/trace/sam-amld
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
root@solaris:~#

Indique al software Oracle HSM que lea el archivo mcf y se vuelva a realizar la configuración en consecuencia:
```
root@solaris:~# samd config
Configuring SAM-FS
root@solaris:~# 
```

Cree el sistema de archivos de reemplazo. Utilice el comando sammkfs family-set-name, donde family-set-name es el nombre del sistema de archivos.

En el ejemplo, volvemos a crear el sistema de archivos samqfs1:

root@solaris:~# sammkfs samqfs1
Building 'samqfs1' will destroy the contents of devices:
  /dev/dsk/c0t0d0s0
  /dev/dsk/c0t3d0s0
Do you wish to continue? [y/N]yes
total data kilobytes       = ...
root@solaris:~#

Vuelva a crear el directorio del punto de montaje para el sistema de archivos, si es necesario.

En el ejemplo, se vuelve a crear el directorio /samqfs1:
```
root@solaris:~# mkdir /samqfs1
root@solaris:~# 
```
Realice una copia de seguridad del archivo /etc/vfstab del sistema operativo.
```
root@solaris:~# cp /etc/vfstab /etc/vfstab.backup
root@solaris:~# 
```
Abra el archivo /etc/vfstab en un editor de textos. Si el archivo /etc/vfstab no contiene parámetros de montaje para el sistema de archivos que está restaurando, tendrá que restaurar los parámetros de montaje.

En el ejemplo, el servidor Oracle HSM está instalado en un host de reemplazo. Entonces el archivo no contiene parámetros de montaje para el sistema de archivos que se está restaurando, samqfs1:
```
root@solaris:~# vi /etc/vfstab
#File
#Device    Device   Mount     System  fsck  Mount    Mount
#to Mount  to fsck  Point     Type    Pass  at Boot  Options
#--------  -------  --------  ------  ----  -------  ---------------------
/devices   -        /devices  devfs   -     no       -
/proc      -        /proc     proc    -     no       -
...
```

Si es posible, cuando se deban restaurar los parámetros de montaje, abra una copia de seguridad del archivo /etc/vfstab original y copie la línea requerida en el archivo /etc/vfstab actual. Una vez que se hayan completado los cambios, guarde el archivo y cierre el editor.

En el ejemplo, contamos con una copia de seguridad, /zfs1/sam_config/20140127/etc/vfstab. De modo que copiamos la línea del sistema de archivos samqfs1 desde la copia de seguridad y la pegamos en el archivo /etc/vfstab actual:

root@solaris:~# vi /zfs1/sam_config/20140127/etc/vfstab.20140127
#File
#Device    Device   Mount     System  fsck  Mount    Mount
#to Mount  to fsck  Point     Type    Pass  at Boot  Options
#--------  -------  --------  ------  ----  -------  ---------------------
/devices   -        /devices  devfs   -     no       -
/proc      -        /proc     proc    -     no       -
...
samqfs1    -        /samqfs1  samfs   -     yes      stripe=1,bg      
:q

root@solaris:~# vi /etc/vfstab
#File
#Device    Device   Mount     System  fsck  Mount    Mount
#to Mount  to fsck  Point     Type    Pass  at Boot  Options
#--------  -------  --------  ------  ----  -------  ---------------------
/devices   -        /devices  devfs   -     no       -
/proc      -        /proc     proc    -     no       -
...
samqfs1    -        /samqfs1  samfs   -     yes      stripe=1,bg      
:wq
root@solaris:~#

Monte el sistema de archivos.

En el ejemplo, montamos el sistema de archivos samqfs1:
```
root@solaris:~# mount /samqfs1
root@solaris:~# 
```
Luego, inicie Restauración de directorios y archivos.

Restauración de directorios y archivos

Una vez que haya vuelto a crear el sistema de archivos de base, puede iniciar la restauración de directorios y archivos. Hay dos enfoques posibles:

La Restauración de archivos y directorios a partir de un archivo de punto de recuperación samfsdump (qfsdump) es por el momento la opción más adecuada, si ha creado y almacena de forma segura los puntos de recuperación regularmente.

Este enfoque devuelve el sistema de archivos para todas las funciones de forma inmediata, ya que restaura los metadatos del sistema de archivos. Un sistema de archivos de almacenamiento puede acceder inmediatamente a datos en un medio de archivo y almacenar de manera provisional los archivos en la caché del disco, ya sea inmediatamente o según se necesite, a medida que los usuarios acceden a los archivos. Los archivos se restauran con sus atributos originales.

Si el punto de recuperación contiene datos y metadatos, este enfoque también es la única manera de restaurar sistemas de archivos independientes (no de almacenamiento) que no fueron guardados en copias de seguridad por aplicaciones de terceros.
La Restauración de archivos y directorios desde el medio de archivo sin un archivo de punto de recuperación mediante una secuencia de comandos de recuperación y la utilidad Oracle HSM star.

Restauración de archivos y directorios a partir de un archivo de punto de recuperación `samfsdump` (`qfsdump`)

Cuando sea posible, debe basar los esfuerzos de recuperación del sistema de archivos en el archivo de punto de recuperación más reciente disponible. Este enfoque es sin duda la forma más rápida, fiable, minuciosa y que requiere menos trabajo para la recuperación de un fallo de un sistema de archivos Oracle HSM. Por lo tanto, si existe un archivo de punto de recuperación, haga lo siguiente:

Restauración del sistema de archivos perdidos desde un archivo de punto de recuperación

Inicie sesión en el servidor de metadatos del sistema de archivos como usuario root.
```
root@solaris:~# 
```
Si aún no lo ha hecho detenga el archivado y el reciclaje mediante los procedimientos en Detención de procesos de archivado y reciclaje.
Identifique el archivo de punto de recuperación más reciente disponible.

En el ejemplo, se crearon archivos de punto de recuperación con fecha para el sistema de archivos samqfs1 en una ubicación conocida, el subdirectorio samqfs1_recovery en el sistema de archivos independiente /zfs1. Por lo tanto, el archivo más reciente 20140324, es fácil de encontrar:
```
root@solaris:~# ls /zfs1/samqfs1_recovery/
20140321    20140322    20140323    20140324
root@solaris:~# 
```
Cambie al directorio de punto de montaje para el sistema de archivos recreado.

En el ejemplo, se monta el sistema de archivos que se volvió a crear en /samqfs1:
```
root@solaris:~# cd /samqfs1
root@solaris:~# 
```
Restaure todo el sistema de archivos relacionado con el directorio actual. Utilice el comando samfsrestore -T -f recovery-point-file -g logfile o el comando exclusivo de QFS qfsrestore -T -f recovery-point-file -g logfile, donde:
- -T muestra las estadísticas de recuperación cuando el comando finaliza, incluido el número de archivos y directorios procesados y el número de errores y advertencias.
- -f recovery-point-file especifica la ruta y el nombre de archivo del archivo de punto de recuperación seleccionado.
- -g logfile crea una lista de los directorios y archivos en línea cuando se creó el punto de recuperación y guarda la lista en el archivo especificado por logfile.
  
  Si va a restaurar un sistema de archivos de almacenamiento, este archivo se puede utilizar para almacenar automáticamente de forma provisional los archivos de medios de archivo, de modo que la caché de disco esté en el mismo estado que en el momento en que se creó automáticamente el punto de recuperación.
En el ejemplo, se restaura el sistema de archivos samqfs1 desde el archivo de punto de recuperación /zfs1/samqfs1_recovery/20140324. Registramos los archivos en línea en el archivo /root/20140324.log (tenga en cuenta que el siguiente comando se introduce como una sola línea, el salto de línea se identifica por el carácter de barra diagonal inversa):
```
root@solaris:~# samfsrestore -T -f /zfs1/samqfs1_recovery/20140324 \
-g /root/20140324.log
      samfsdump statistics:
                Files:              52020
                Directories:        36031
                Symbolic links:     0
                Resource files:     8
                File segments:      0
                File archives:      0
                Damaged files:      0
                Files with data:    24102
                File warnings:      0
                Errors:             0
                Unprocessed dirs:   0
                File data bytes:    0
root@solaris:~# 
```
Si restauró un sistema de archivos independiente (no de almacenamiento), se restauraron los metadatos del sistema de archivos y los datos del archivo que se guardaron en el archivo de punto de recuperación. Deténgase aquí.
De lo contrario, deberá Realmacenamiento provisional de archivos (si es necesario).

Realmacenamiento provisional de archivos (si es necesario)

En la mayoría de los casos, no vuelva a almacenar de manera provisional archivos desde los medios de archivo al disco después de una recuperación del sistema de archivos. Permita que los usuarios almacenen de manera provisional los archivos, según sea necesario, mediante el acceso a ellos.

Este enfoque automáticamente da prioridad al almacenamiento provisional según las necesidades del usuario. Maximiza la disponibilidad del sistema de archivos en un momento en que puede haber quedado fuera de línea durante algún tiempo. Solo se almacenan de manera provisional los archivos que se necesitan de inmediato. Por lo tanto, el esfuerzo total de almacenamiento provisional se distribuye durante un período de tiempo. Esto ayuda a garantizar que los recursos del sistema de archivos, como las unidades, siempre estén disponibles para las tareas de alta prioridad, como el archivado de archivos nuevos y el almacenamiento provisional de datos requeridos del usuario.

Este enfoque también reduce el esfuerzo administrativo asociado con la recuperación.
Si debe volver a almacenar de manera provisional los archivos residentes en la caché del disco antes de una falla, use el comando /opt/SUNWsamfs/examples/restore.sh logfile, donde logfile es la ruta y el nombre de archivo del archivo log creado mediante la opción -g del comando samfsrestore (qfsrestore).

La secuencia de comandos restore.sh almacena de manera provisional los archivos que aparecen en el archivo log. Estos archivos estaban en línea cuando se creó el archivo de punto de recuperación samfsrestore (qfsrestore).

Si miles de archivos se deben almacenar de manera provisional, considere la posibilidad de dividir el archivo log en archivos más pequeños. A continuación, ejecute la secuencia de comandos restore.sh con un archivo a la vez. Esto desglosa el esfuerzo de almacenamiento provisional durante un período de tiempo y reduce la interferencia con el archivado y el almacenamiento provisional iniciado por el usuario.
Ahora realice la Identificación de archivos dañados y ubicación de copias de reemplazo.

Identificación de archivos dañados y ubicación de copias de reemplazo

El proceso samfsrestore restaura una copia de los metadatos del sistema de archivos desde un archivo de punto de recuperación, de modo que pueda encontrar los datos correspondientes del sistema de archivos en cinta y restaurarlos en las ubicaciones adecuadas en el sistema de archivos. No obstante, los archivos de punto de recuperación se crean antes de la pérdida del sistema de archivos. Por lo tanto, de forma inevitable, algunos de los metadatos apuntan normalmente a ubicaciones de datos que han cambiado desde la creación del punto de recuperación. El sistema de archivos tiene un registro de estos archivos, pero no puede localizar su contenido. Por lo tanto, establece el indicador dañado en cada uno de esos archivos.

De hecho, en algunos casos, los datos de un archivo dañado se pueden perder. Pero en otros casos, los metadatos restaurados simplemente están desactualizados. El posible que el sistema de archivos restaurado no pueda encontrar datos de los archivos que se almacenaron después de la creación del punto de recuperación, simplemente, porque los metadatos restaurados no registran una ubicación actual. En estos casos, puede reparar los archivos buscando los datos usted mismo y, a continuación, actualizar los metadatos restaurados.

Para encontrar los datos faltantes, actualizar los metadatos y reparar archivos, use los logs del archivador. Siga estos pasos:

Si aún no lo ha hecho, inicie sesión en el servidor de metadatos del sistema de archivos como usuario root.
```
root@solaris:~# 
```
Identifique el archivo log de archivador más reciente disponible.

Si el log de archivador en el servidor aún está disponible, es probable que contenga la información más reciente. De lo contrario, deberá utilizar una copia de seguridad.

En el ejemplo, el archivo log del archivador samqfs1.archiver.log está en el servidor en el subdirectorio /var/adm/. También tenemos copias del archivo log del archivador en una ubicación conocida, el subdirectorio samqfs1_recovery/archlogs, en el sistema de archivos independiente /zfs1. De modo que se cuenta con el último archivo, samqfs1.archiver.log, y una copia de seguridad reciente, 20150324:
```
root@solaris:~# dir /var/adm/*.archiver.log
samqfs1.archiver.log
root@solaris:~# dir /zfs1/samqfs1_recovery/archivelogs
20150322    20150323    20150324
root@solaris:~# 
```
En el sistema de archivos recién restaurado, identifique los archivos dañados. Utilice el comando sfind mountpoint -damaged, donde mountpoint es el directorio donde se monta el sistema de archivos recuperado.

En el ejemplo, se inicia la búsqueda en el directorio /samqfs1 y se encuentran seis archivos dañados:
```
root@solaris:~# sfind /samqfs1 -damaged
./genfiles/ay0
./genfiles/ay1
./genfiles/ay2
./genfiles/ay5
./genfiles/ay6
./genfiles/ay9
root@solaris:~# 
```
Busque la copia más reciente del log de archivador para entradas relacionadas con cada uno de los archivos dañados. Utilice el comando grep "file-name-expression" archiver-log, donde file-name-expression es una expresión regular que coincide con el archivo dañado y archiver-log es la ruta y el nombre de la copia del log de archivador que está examinando.

En el ejemplo, se utiliza la expresión regular genfiles\/ay0 para buscar el archivo log más reciente para las entradas relacionadas con el archivo genfiles/ay0:
```
root@solaris:~# grep "genfiles\/ay0 " /var/adm/samqfs1.archiver.log
```
Cuando encuentre una entrada para un archivo, anote el tipo de medio, el número de serie del volumen y la posición del archivo (tar) de almacenamiento donde se almacena el archivo de datos. Anote también el tipo de archivo, ya que esto afectará la manera como se restaure el archivo.

En el ejemplo, ubicamos una entrada para el archivo genfiles/ay0. La entrada del log muestra que se archivó (A) el 4 de marzo de 2015 a las 9:49 p. m. mediante LTO (li) volumen VOL012. El archivo se almacena en el archivo de almacenamiento ubicado en la posición hexadecimal 0 x 78 (78). Se trata de un archivo normal; escriba f:
```
root@solaris:~# grep "genfiles\/ay0 " /var/adm/samqfs1.archiver.log
A 2015/03/04 21:49:15 li VOL012 SLOT12 allsets.1 78.1 samqfs1 7131.14 8087 genfiles/ay0 f 0 51
root@solaris:~# 
```
Para obtener una explicación completa de los campos de las entradas del log de archivador, consulte Apéndice A, Descripción del log del archivador.
Si no encuentra una entrada para un archivo dañado en la copia del log del archivador, repita la búsqueda usando los logs de archivo de copia de seguridad que se crearon después de que se creó el archivo de punto de recuperación.

Los logs del archivador se renuevan con frecuencia. Por lo tanto, si mantiene varias copias del log del archivador, puede recuperar archivos dañados usando copias de almacenamiento realizadas antes del período cubierto por el log de archivador actual.
Continúe con Buscar los archivos faltantes que se almacenaron después de la creación del punto de recuperación.

Buscar los archivos faltantes que se almacenaron después de la creación del punto de recuperación

Normalmente, algunos archivos se almacenan después de la creación del último punto de recuperación y antes de la pérdida de un sistema de archivos. Dado que los metadatos de estos archivos no están en el archivo de punto de recuperación, samfsrestore no puede recuperarlos, ni siquiera como archivos dañados. No obstante, los datos de archivos residen en medios de archivo, de modo que pueda volver a crear los metadatos y recuperar los archivos en su lugar apropiado en el sistema de archivos mediante los archive logs.

Si aún no lo ha hecho, inicie sesión en el servidor de metadatos del sistema de archivos como usuario root.
```
root@solaris:~# 
```
Identifique el archivo log de archivador más reciente disponible.

Si el log de archivador en el servidor aún está disponible, es probable que contenga la información más reciente. De lo contrario, deberá utilizar una copia de seguridad.

En el ejemplo, el archivo log del archivador samqfs1.archiver.log está en el servidor en el subdirectorio /var/adm/. También tenemos copias del archivo log del archivador en una ubicación conocida, el subdirectorio samqfs1_recovery/archlogs, en el sistema de archivos independiente /zfs1. De modo que se cuenta con el último archivo, samqfs1.archiver.log, y una copia de seguridad reciente, 20150324:
```
root@solaris:~# dir /var/adm/*.archiver.log
samqfs1.archiver.log
root@solaris:~# dir /zfs1/samqfs1_recovery/archivelogs
20150322    20150323    20150324
root@solaris:~# 
```
Busque la copia más reciente del log de archivador para encontrar las entradas que se realizaron después de la creación del punto de recuperación. Utilice el comando grep "time-date-expression" archiver-log, donde time-date-expression es una expresión regular que coincide con la fecha y la hora en las que quiere iniciar la búsqueda y archiver-log es la ruta y el nombre de la copia del log del archivador que está examinando.

En el ejemplo, el sistema de archivos se perdió a las 2:02 a. m. del 24 de marzo de 2015. El último archivo de punto de recuperación se realizó a las 2:10 a. m. del 23 de marzo de 2015. Por lo tanto, se utiliza la expresión regular ˆA 2015\/03\/2[45] para buscar el archivo log más reciente para los archivos almacenados que se registraron el 23 o el 24 de marzo en:
```
root@solaris:~# grep "ˆA 2015\/03\/2[34]" /var/adm/samqfs1.archiver.log
```
Cuando encuentre una entrada para una copia almacenada de un archivo sin restauración, anote la información de ruta, nombre, tipo de archivo, tipo de medio y ubicación.

Los tipos de archivos se muestran como f para archivos normales, R para archivos extraíbles o S para un segmento de datos en un archivo segmentado. El tipo de medio es un código de dos caracteres (consulte Apéndice B).

Para ubicar la copia de seguridad, necesita el número de serie del volumen de medios que almacena la copia. Si la copia se almacena en un medio de acceso secuencial, como una cinta magnética, también anote el valor hexadecimal que representa la posición de inicio del archivo de almacenamiento (tar). Si la copia se almacena en medios de acceso aleatorio, como un disco de archivado, anote la ruta y en nombre del archivo tar relacionado con el número de serie del volumen. Por último, si el archivo es segmentado, anote la longitud del segmento.

En el siguiente ejemplo, las entradas del log del archivador muestran que los siguientes archivos se han archivado después de la creación del último punto de recuperación:
```
root@solaris:~# grep "ˆA 2015\/03\/2[34]" /var/adm/samqfs1.archiver.log
A 2015/03/23 10:43:18 li VOL002 all.1 111.1 samqfs1 1053.3 69 genfiles/hops f 0 0
A 2015/03/23 10:43:18 li VOL002 all.1 111.3 samqfs1 1051.1 104 genfiles/anic f 0 0
A 2015/03/23 13:09:05 li VOL004 all.1 212.1 samqfs1 1535.2 1971 genfiles/genA0 f 0 0
A 2015/03/23 13:09:06 li VOL004 all.1 212.20 samqfs1 1534.2 1497 genfiles/genA9 f 0 0
A 2015/03/23 13:10:15 li VOL004 all.1 212.3f samqfs1 1533.2 6491 genfiles/genA2 f 0 0
A 2015/03/23 13:12:25 li VOL003 all.1 2.5e samqfs1 1532.2 17717 genfiles/genA13 f 0 0
A 2015/03/23 13:12:28 li VOL003 all.1 2.7d samqfs1 1531.2 14472 genfiles/genA4 f 0 0
A 2015/03/23 13:12:40 li VOL003 all.1 2.9c samqfs1 1530.2 19971 genfiles/genA45 f 0 0
A 2015/03/23 21:49:15 dk DISKVOL1/f2 all.1 2.2e9 samqfs1 1511.2 8971 socfiles/spcC4 f 0 0
A 2015/03/23 21:49:15 dk DISKVOL1/f2 all.1 2.308 samqfs1 1510.2 7797 spcfiles/spcC5 f 0 0
A 2015/03/23 14:01:47 li VOL013 all.1 76a.1 samqfs1 14.5 10485760 bf/dat011/1 S 0 51
A 2015/03/23 14:04:11 li VOL013 all.1 76a.5002 samqfs1 15.5 10485760 bf/dat011/2 S 0 51
A 2015/03/23 14:06:24 li VOL013 all.1 1409aa4.1 samqfs1 16.5 184 bf/dat011/3 S 0 51
A 2015/03/23 18:28:51 li VOL036 all.1 12d.1 samqfs1 11731.1 89128448  rf/rf81 f 0 210
A 2015/03/23 18:28:51 li VOL034 all.1 15f.0 samqfs1 11731.1 525271552 rf/rf81 f 1 220
root@solaris:~# 
```
Tenga en cuenta la siguiente información:
- Se archivan ocho archivos comunes (f) (A) en medios LTO (li): genfiles/hops y genfiles/anic en la posición 0x111 en el volumen VOL002, genfiles/genA0, genfiles/genA9 y genfiles/genA2 en la posición 0x212 en el volumen VOL004 y genfiles/genA13, genfiles/genA4 y genfiles/genA45 en la posición 0x212 en el volumen VOL003.
- Se archivan dos archivos comunes (f) (A) en medios de disco (dk): spcfiles/spcC4 y spcfiles/spcC5 en el archivo de almacenamiento DISKVOL1 \f2 en el volumen DISKVOL1.
- Un archivo de tres partes segmentado (S) se archiva en medios LTO (li): bf/dat011, en dos segmentos a partir de la posición 0x76a y un segmento a partir de la posición 1409aa4 en el volumen VOL013. El segmento /1 tiene 10485760 bytes de longitud, el segmento /2 tiene 10485622 bytes y el segmento /3 tiene 184 bytes.
- Se archiva un archivo común de desbordamiento de volumen (escriba f) (A) en medios LTO (li): rf/rf81, a partir de la posición 0x12d en el volumen VOL036 y continuando en la posición 0x15f en el volumen VOL034.
Para obtener una explicación completa de los campos de las entradas del log de archivador, consulte Apéndice A, Descripción del log del archivador.
Repita la búsqueda usando cualquier log de archivo de copia de seguridad que se haya creado después del archivo de punto de recuperación.

Los logs del archivador se renuevan con frecuencia. Por lo tanto, si mantiene varias copias del log del archivador, puede recuperar archivos dañados usando copias de almacenamiento realizadas antes del período cubierto por el log de archivador actual.
Ahora realice la Restauración de archivos dañados o faltantes.

Restauración de archivos dañados o faltantes

Dado el volumen de medios y la posición de un archivo de almacenamiento (tar) en el medio, la restauración de archivos dañados o faltantes implica simplemente acceder al archivo tar y extraer el archivo de datos requerido. Cuando los archivos de almacenamiento residen en dispositivos de disco esto es sencillo, ya que los archivos tar residen en directorios de acceso aleatorio bajo un punto de montaje de sistema de archivos. Sin embargo, cuando el archivo tar reside en un medio de alta capacidad de acceso secuencial hay una complicación que se agrega: no podemos extraer normalmente el archivo de datos requerido del archivo de almacenamiento hasta que éste no se almacene de manera provisional en un dispositivo de disco de acceso aleatorio. Como los archivos de almacenamiento pueden ser grandes, esto puede llevar bastante tiempo y ser molesto en una situación de recuperación. Por lo tanto, los procedimientos a continuación aprovechan el comando Oracle HSM request, que lee los archivos de almacenamiento en la memoria y hace que estén disponibles como si estuvieran siendo leídos desde el disco.

Restaure todos los archivos normales dañados y faltantes que pueda. Para cada archivo, siga los pasos detallados a continuación:

Primero, recupere los archivos normales que no abarcan volúmenes. Utilice el procedimiento Restauración de archivos normales perdidos y dañados.
A continuación, recupere los archivos segmentados. Utilice el procedimiento Restauración de archivos segmentados perdidos y dañados.
A continuación, restaure los archivos normales que abarcan volúmenes. Utilice el procedimiento Restauración de archivos de desbordamiento de volumen perdidos y dañados.
Una vez que haya restaurado todos los archivos faltantes y dañados que tiene copias, vuelva a activar el archivado eliminando las directivas wait del archivo archiver.cmd. Vuelva a activar el reciclaje mediante los parámetros -ignore del archivo recycler.cmd.

El sistema de archivos está lo más parecido posible a su condición original. No se pueden recuperar archivos que aún están dañados o que faltan.
Una vez que se restauraron todos los archivos perdidos y dañados que tienen copias, consulte Restauración del funcionamiento normal de los sistemas de archivos de almacenamiento.

Restauración de archivos y directorios desde el medio de archivo sin un archivo de punto de recuperación

Si debe recuperar un sistema de archivos directamente a partir de los medios de archivo sin la ayuda de un archivo de punto de recuperación, puede hacerlo. Siga estos pasos:

Si está intentando restaurar los archivos desde medios ópticos, pare y póngase en contacto con los servicios de soporte de Oracle para obtener ayuda.
Desactive el uso compartido del sistema de archivos de red (NFS) para el sistema de archivos.
Desactive el archivado y el reciclaje. Utilice el método que se describe en Detención de procesos de archivado y reciclaje.
Reserve una unidad de cinta para el uso exclusivo del proceso de recuperación. Utilice el comando samcmd unavail drive-equipment-number, donde drive-equipment-number es el número ordinal del equipo asignado a la unidad en el archivo /etc/opt/SUNWsamfs/mcf.

El comando samcmd unavail hace que la unidad no esté disponible para el archivado, el almacenamiento provisional y los procesos de liberación. En el ejemplo, reservamos la unidad 804
```
root@solaris:~# samcmd unavail 804
root@solaris:~# 
```
Copie el archivo /opt/SUNWsamfs/examples/tarback.sh en una ubicación alternativa, como /tmp.

El archivo tarback.sh es una secuencia de comandos ejecutable que recupera archivos desde un conjunto de volúmenes de medios especificado. La secuencia de comandos ejecuta el comando star -n en cada archivo de almacenamiento (tar) de cada volumen. Cuando una copia de seguridad en cinta no tiene ningún archivo correspondiente en el sistema de archivos o cuando la copia en cinta es más reciente que el archivo correspondiente en el sistema de archivos, star -n restaura la copia.

En el ejemplo, se copia la secuencia de comandos en /tmp:
```
root@solaris:~# cp /opt/SUNWsamfs/examples/tarback.sh /tmp/tarback.sh
root@solaris:~# 
```

Abra la copia del archivo tarback.sh en un editor de texto.

En el ejemplo, utilizamos el editor vi:

root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh
#!/bin/sh
#   script to reload files from SAMFS archive tapes
STAR="/opt/SUNWsamfs/sbin/star"
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=28
TAPEDRIVE="/dev/rmt/3cbn"
# BLOCKSIZE is in units of 512 bytes (e.g. 256 for 128K)
BLOCKSIZE=256
MEDIATYPE="lt"
VSN_LIST="VSNA VSNB VSNC VSNZ"
...

Si las utilidades Oracle HSM star, load y unload se instalan en ubicaciones no estándares, edite las rutas de comando por defecto en la copia del archivo tarback.sh.

En el ejemplo, todas las utilidades se instalan en las ubicaciones por defecto, de modo que no es necesario editar nada:
```
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh
#!/bin/sh
#   script to reload files from SAMFS archive tapes
STAR="/opt/SUNWsamfs/sbin/star"
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
...
```

En la copia del archivo tarback.sh, busque la variable EQ. Establezca su valor en el número ordinal de equipo de la unidad que ha reservado para uso de recuperación.

En el ejemplo, definimos EQ=804:

root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh
#!/bin/sh
#   script to reload files from SAMFS archive tapes
STAR="/opt/SUNWsamfs/sbin/star"
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
...

En la copia del archivo tarback.sh, busque la variable TAPEDRIVE. Establezca su valor en la ruta raw al dispositivo, delimitada por comillas dobles.

En el ejemplo, la ruta raw al dispositivo 804 es /dev/rmt/3cbn:

root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh
#!/bin/sh
#   script to reload files from SAMFS archive tapes
STAR="/opt/SUNWsamfs/sbin/star"
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
...

En la copia del archivo tarback.sh, busque la variable BLOCKSIZE. Establezca su valor en el número de unidades de 512 bytes en el tamaño deseado del bloque.

En el ejemplo, se desea un tamaño de segmento de 256 kilobytes para la unidad LTO-4. Por lo tanto, se especifica 512:
```
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
...
```
En la copia del archivo tarback.sh, busque la variable MEDIATYPE. Establezca su valor en el código de tipo de medio físico de dos caracteres que Apéndice B muestra para el tipo de medio que la unidad admite. Incluya el tipo de medio entre comillas dobles.

En el ejemplo, se utiliza una unidad LTO-4. Por lo que es especifica li:
```
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
MEDIATYPE="li"
...
```
En la copia del archivo tarback.sh, busque la variable VSN_LIST. Como su valor, proporcione una lista delimitada por espacios de los números de serie de volumen (VSN) que identifican las cintas que pueden contener copias de seguridad de sus archivos. Incluya la lista entre comillas dobles.

En el ejemplo especificamos los volúmenes VOL002, VOL003, VOL004, VOL013, VOL034 y VOL036:
```
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
MEDIATYPE="lt"
VSN_LIST="VOL002 VOL003 VOL004 VOL013 VOL034 VOL036"
...
```

Guarde la copia del archivo tarback.sh. Cierre el editor.

EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
MEDIATYPE="lt"
VSN_LIST="VOL002 VOL003 VOL004 VOL013 VOL034 VOL036"
...
:wq
root@solaris:~#

Ejecute la secuencia de comandos /tmp/tarback.sh.
```
root@solaris:~# /tmp/tarback.sh
```
Para cada archivo restaurado, vuelva a crear la propiedad de usuario y de grupo, los modos, los atributos extendidos y las listas de control de acceso (ACL), según sea necesario.

La secuencia de comandos /tmp/tarback.sh no puede restaurar estos tipos de metadatos.
Una vez que se ejecutó la secuencia de comandos /tmp/tarback.sh y que terminaron de recuperarse los archivos, consulte Restauración del funcionamiento normal de los sistemas de archivos de almacenamiento.