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:
Antes de comenzar, tenga en cuenta lo siguiente: si está realizando una recuperación después de la pérdida de un servidor de metadatos de 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.
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:
sammkfsInicie 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, se desmonta el sistema de archivos /hsmfs1:
root@solaris:~# umount /hsmfs1 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 #----------------------- --------- --------- --------- ------ ------------- hsmfs1 100 ms hsmfs1 on /dev/dsk/c1t3d0s3 101 md hsmfs1 on /dev/dsk/c1t4d0s5 102 md hsmfs1 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, se recrea el sistema de archivos /hsmfs1:
root@solaris:~# sammkfs hsmfs1 Building 'hsmfs1' 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 recrea el directorio /hsmfs1:
root@solaris:~# mkdir /hsmfs1 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. Por lo tanto, el archivo no contiene parámetros de montaje para el sistema de archivos que se está restaurando, hsmfs1:
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 se copia la línea para el sistema de archivos hsmfs1 desde la copia de seguridad y se la pega 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 - ... hsmfs1 - /hsmfs1 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 - ... hsmfs1 - /hsmfs1 samfs - yes stripe=1,bg :wq root@solaris:~#
Monte el sistema de archivos.
En el ejemplo, se monta el sistema de archivos hsmfs1:
root@solaris:~# mount /hsmfs1 root@solaris:~#
Ahora comience a restaurar los directorios y los 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 desde un archivo de punto de recuperación samfsdump (qfsdump) es la mejor opción si creó y guardó de forma segura los puntos de recuperación de manera regular.
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 medios de archivo sin un archivo de punto de recuperación mediante una secuencia de comandos de recuperación y la utilidad star de Oracle HSM.
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:
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 hsmfs1 en una ubicación conocida, el subdirectorio hsmfs1_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/hsmfs1_recovery/ 20140321 20140322 20140323 20140324 root@solaris:~#
Cambie al directorio de punto de montaje para el sistema de archivos recreado.
En el ejemplo, el sistema de archivos que se volvió a crear se desmonta en /hsmfs1:
root@solaris:~# cd /hsmfs1 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 hsmfs1 desde el archivo de punto de recuperación /zfs1/hsmfs1_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/hsmfs1_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, vuelva a almacenar de manera provisional los archivos almacenados 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 identifique los archivos dañados y ubique las 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. Es posible que el sistema de archivos restaurado no encuentre datos de los archivos que se almacenaron o migraron 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, actualice los metadatos y repare los archivos; use los archivos log del archivador y de migración de medios (si los hay). 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 hsmfs1.archiver.log está en el servidor, en el subdirectorio /var/adm/. Además, hay copias con fecha del archivo log del archivador en una ubicación conocida, el subdirectorio hsmfs1_recovery/archlogs en el sistema de archivos independiente /zfs1. De modo que se cuenta con el último archivo, hsmfs1.archiver.log, y una copia de seguridad reciente, 20150324:
root@solaris:~# dir /var/adm/*.archiver.log hsmfs1.archiver.log root@solaris:~# dir /zfs1/hsmfs1_recovery/archivelogs 20150322 20150323 20150324 root@solaris:~#
Si los archivos se migraron recientemente a los medios de reemplazo, también debe ubicar los logs de migración.
Se crean logs de migración de medios para cada volumen de origen en el directorio de registro especificado por el archivo migrationd.cmd. Los logs se denominan media-type.vsn, donde media-type es uno de los códigos de dos dígitos que se describen en el Apéndice B, Glosario de tipos de equipos y vsn es el número de serie de volumen alfanumérico de seis caracteres del volumen de origen.
El formato de los logs de migración de medios contiene la misma información de recuperación que los logs del archivador y se pueden usar de la misma manera. Para obtener una descripción de las pocas diferencias de formato que existen, consulte el Apéndice A, Comprensión de los logs del archivador y de migración.
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 /hsmfs1 y se encuentran seis archivos dañados:
root@solaris:~# sfind /hsmfs1 -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/hsmfs1.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/hsmfs1.archiver.log A 2015/03/04 21:49:15 li VOL012 SLOT12 allsets.1 78.1 hsmfs1 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, Comprensión de los logs del archivador y de migración.
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.
A continuación, busque los archivos que se almacenaron después de que se creó el punto de recuperación.
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. No pueden contener metadatos de los archivos creados y almacenados a partir de entonces.
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 se migraron archivos a medios de reemplazo antes de la pérdida del sistema de archivos, también puede usar los logs de migración de medios.
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 hsmfs1.archiver.log está en el servidor, en el subdirectorio /var/adm/. Además, hay copias con fecha del archivo log del archivador en una ubicación conocida, el subdirectorio hsmfs1_recovery/archlogs en el sistema de archivos independiente /zfs1. De modo que se cuenta con el último archivo, hsmfs1.archiver.log, y una copia de seguridad reciente, 20150324:
root@solaris:~# dir /var/adm/*.archiver.log hsmfs1.archiver.log root@solaris:~# dir /zfs1/hsmfs1_recovery/archivelogs 20150322 20150323 20150324 root@solaris:~#
Si los archivos se migraron recientemente a los medios de reemplazo, también debe ubicar los logs de migración.
Se crean logs de migración de medios para cada volumen de origen en el directorio de registro especificado por el archivo migrationd.cmd. Los logs se denominan media-type.vsn, donde media-type es uno de los códigos de dos dígitos que se describen en el Apéndice B, Glosario de tipos de equipos y vsn es el número de serie de volumen alfanumérico de seis caracteres del volumen de origen.
El formato de los logs de migración de medios contiene la misma información de recuperación que los logs del archivador y se pueden usar de la misma manera. Para obtener una descripción de las pocas diferencias de formato que existen, consulte el Apéndice A, Comprensión de los logs del archivador y de migración.
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/hsmfs1.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, Glosario de tipos de equipos).
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/hsmfs1.archiver.log A 2015/03/23 10:43:18 li VOL002 all.1 111.1 hsmfs1 1053.3 69 genfiles/hops f 0 0 A 2015/03/23 10:43:18 li VOL002 all.1 111.3 hsmfs1 1051.1 104 genfiles/anic f 0 0 A 2015/03/23 13:09:05 li VOL004 all.1 212.1 hsmfs1 1535.2 1971 genfiles/genA0 f 0 0 A 2015/03/23 13:09:06 li VOL004 all.1 212.20 hsmfs1 1534.2 1497 genfiles/genA9 f 0 0 A 2015/03/23 13:10:15 li VOL004 all.1 212.3f hsmfs1 1533.2 6491 genfiles/genA2 f 0 0 A 2015/03/23 13:12:25 li VOL003 all.1 2.5e hsmfs1 1532.2 17717 genfiles/genA13 f 0 0 A 2015/03/23 13:12:28 li VOL003 all.1 2.7d hsmfs1 1531.2 14472 genfiles/genA4 f 0 0 A 2015/03/23 13:12:40 li VOL003 all.1 2.9c hsmfs1 1530.2 19971 genfiles/genA45 f 0 0 A 2015/03/23 21:49:15 dk DISKVOL1/f2 all.1 2.2e9 hsmfs1 1511.2 8971 socfiles/spcC4 f 0 0 A 2015/03/23 21:49:15 dk DISKVOL1/f2 all.1 2.308 hsmfs1 1510.2 7797 spcfiles/spcC5 f 0 0 A 2015/03/23 14:01:47 li VOL013 all.1 76a.1 hsmfs1 14.5 10485760 bf/dat011/1 S 0 51 A 2015/03/23 14:04:11 li VOL013 all.1 76a.5002 hsmfs1 15.5 10485760 bf/dat011/2 S 0 51 A 2015/03/23 14:06:24 li VOL013 all.1 1409aa4.1 hsmfs1 16.5 184 bf/dat011/3 S 0 51 A 2015/03/23 18:28:51 li VOL036 all.1 12d.1 hsmfs1 11731.1 89128448 rf/rf81 f 0 210 A 2015/03/23 18:28:51 li VOL034 all.1 15f.0 hsmfs1 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, Comprensión de los logs del archivador y de migración.
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.
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.
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.