La cinta es un medio sumamente estable y confiable para almacenamiento y conservación de datos a largo plazo. Sin embargo, tiene una vida útil limitada. El desgaste causado por los procesos mecánicos normales (montaje, tensión y lectura/escritura) se acumula con el tiempo. Cuando hay unidades nuevas de mayor rendimiento disponibles, las unidades anteriores son más difíciles de admitir y los medios compatibles son más costosos y más difíciles de encontrar. Por lo tanto, en algún momento, deberá transferir los archivos a medios nuevos.
En un sistema de archivos jerárquico de Oracle HSM, el reemplazo de medios antiguos con medios nuevos es un proceso complejo. Los medios de cinta son una parte integral del sistema de archivos. Los metadatos del sistema de archivos registran las ubicaciones para varias copias de los datos de cada archivo, algunas en disco y otras en copias de cinta. Por lo tanto, los inodes del sistema de archivos deben actualizarse para reflejar las nuevas ubicaciones de las copias de archivos migradas a medida que se copian las cintas. Al mismo tiempo, los medios y las unidades deben gestionarse de modo que las copias se realicen sin interferir en las operaciones normales del sistema de archivos, como el archivado y el almacenamiento provisional.
Oracle Hierarchical Storage Manager ofrece dos maneras de gestionar las complejidades de la migración de medios. Cada una tiene sus ventajas, según sus requisitos.
La función de migración de medios introducida en Oracle HSM 6.1 copia volúmenes completos desde los medios montados en una unidad de biblioteca hasta los medios montados en otra, y actualiza los metadatos del sistema de archivos en el proceso (no se admiten las unidades cargadas manualmente). Esto minimiza la sobrecarga del sistema y la carga de trabajo del administrador. Los volúmenes se copian en segundo plano, cuando las unidades ya no se necesitan para archivado ni almacenamiento provisional. Puede especificar el número de unidades utilizadas y las horas del día cuando puede ocurrir la migración. De lo contrario, puede permitir que Oracle HSM migre los volúmenes cuando las unidades están inactivas. Si una unidad o un volumen se necesitan para un trabajo de archivado o almacenamiento provisional, el proceso de migración de medios deja que se ejecute la operación de mayor prioridad. Si configuró correctamente las unidades de destino StorageTek T1000D (o posterior) disponibles, puede realizar la migración con la función de copia extendida de T10000 y la opción xcopy de Oracle HSM. Una vez que se realiza una solicitud, las unidades controlan la copia por su cuenta, sin utilizar recursos del servidor. De lo contrario, puede minimizar la carga del servidor mediante la opción de copia de servidor de Oracle HSM. El servidor del sistema de archivos copia volúmenes de una unidad a otra mediante un buffer de E/S configurable.
Los procesos de archivado normales también pueden migrar datos (un archivo de almacenamiento a la vez). Puede configurar el sistema para que almacene provisionalmente los archivos de los medios antiguos a la caché de disco y, luego, vuelva a almacenarlos en medios nuevos. Este enfoque de un archivo a la vez puede darle más control sobre la manera en que se agrupan y se distribuyen los archivos. Sin embargo, requiere una mayor administración. Usted se ocupa de asignar la caché de disco y los recursos de la unidad, de modo que debe planificar atentamente si necesita minimizar la interferencia en las operaciones normales del sistema de archivos.
El resto de este documento lo guía a través del proceso:
Migración de datos, ya sea mediante la Migración de volúmenes completos o el Almacenamiento provisional de archivos y rearchivado en medios de reemplazo
Antes de continuar, debe comprender:
Antes de iniciar una migración de medios, asegúrese de que los mecanismos de recuperación que, por lo general, protegen los datos de archivo de Oracle HSM sigan siendo eficaces durante el cambio y posteriormente. Los errores de usuario y los fallos de hardware catastróficos son probables durante una operación de migración. Por lo tanto, como siempre, debe asegurarse de poder recuperar archivos o sistemas de archivos completos a partir de los archivos de punto de recuperación samfsdump existentes.
Durante la migración y hasta un tiempo después, la recuperación dependerá de los archivos de punto de recuperación que hacen referencia a los volúmenes de cinta de origen y no a los volúmenes de destino nuevos. Si un fallo de hardware importante desactiva el sistema de archivos y estas cintas antiguas no están disponibles, no podrá llevar a cabo la recuperación.
Por lo tanto, como mínimo, debe planificar cómo conservar las cintas antiguas hasta haber creado suficientes puntos de recuperación nuevos para restaurar el sistema de archivos actual a partir de medios nuevos. Si necesita restaurar archivos a determinados puntos en el tiempo, posiblemente deba mantener los medios antiguos durante más tiempo o de forma indefinida. Idealmente, los volúmenes antiguos deben conservarse en una biblioteca, donde se pueda acceder a ellos fácilmente.
Asegúrese de que la biblioteca de destino contenga medios suficientes para almacenar los archivos migrados. Asegúrese de que todos los volúmenes estén correctamente etiquetados, como se describe en Cómo etiquetar una cinta nueva o volver a etiquetar una cinta existente. La migración fallará si los volúmenes no están etiquetados.
El método de migración que elija dependerá del estado del archivo y de los requisitos del usuario y la aplicación. Utilice el siguiente procedimiento para tomar una decisión.
Decida si el archivo seguirá funcionando durante la migración.
Desactivar el archivo y destinar todos los recursos exclusivamente a la migración puede simplificar la tarea y acelerar la finalización. Sin embargo, esto pocas veces resulta práctico si el archivo está activamente en uso.
Si necesita migrar grupos de archivos de manera selectiva, en lugar de volúmenes completos, o si necesita mantener relaciones específicas entre grupos de archivos de almacenamiento, utilice el método de almacenamiento provisional y rearchivado. Vaya a Almacenamiento provisional de archivos y rearchivado en medios de reemplazo.
Si simplemente necesita copiar volúmenes antiguos a medios nuevos o minimizar el impacto de la migración en las operaciones del sistema de archivos, use el método de migración de volúmenes.
Si no cuenta con unidades de canal de fibra Oracle StorageTek T10000D (o posterior) que pueda usar como unidades de destino o si las cintas de origen y de destino no comparten un tamaño de bloque común, use el método de copia de servidor.
En este modo, el software de Oracle HSM copia únicamente archivos de almacenamiento válidos desde la unidad de origen hasta un buffer de E/S configurable en el servidor del sistema de archivos. Si los tamaños de bloque de origen y de destino difieren, el software realiza ajustes automáticamente, siempre que el tamaño del bloque de destino sea mayor. El software envía bloques de cinta desde el buffer hasta la unidad de destino.
Si cuenta con unidades de destino de canal de fibra StorageTek T10000D (o posterior), si ambas unidades ejecutan el firmware actual, si las cintas de origen y de destino comparten el mismo tamaño de bloque, y si las unidades de origen y de destino se conectan mediante el mismo switch de red de área de almacenamiento (SAN), use la opción xcopy de Oracle HSM.
Cuando especifica xcopy, el servidor del sistema de archivos envía una solicitud de copia SCSI a la unidad y la unidad T10000D copia la cinta de origen a la cinta de destino, bloque por bloque, a partir del primer archivo de almacenamiento válido. Si la operación xcopy falla por algún motivo, el software de migración cambia automáticamente al método de copia de servidor. El método xcopy maximiza el rendimiento y minimiza la sobrecarga del servidor.
Para obtener más información sobre los requisitos de unidades y firmware, consulte las notas de la versión, README.txt, en el archivo ZIP de descarga o en el servidor del sistema de archivos en /opt/SUNWsamfs/doc/README.txt
Si los volúmenes de origen contienen pocos archivos caducados, use la opción xcopy en el modo eod (fin de datos).
En este modo, la unidad T10000 copia todos los archivos de almacenamiento encontrados entre el primer archivo válido y la marca de fin de datos (EOD) en la cinta. Si algunos de estos archivos están desactualizados, se copian al volumen de destino con los archivos válidos.
Si los volúmenes de origen contienen muchos archivos caducados, use la opción xcopy en el modo repack.
En este modo, la unidad T10000 copia al volumen de destino únicamente los archivos de almacenamiento no caducados.
Vaya a Almacenamiento provisional de archivos y rearchivado en medios de reemplazo.
Para seleccionar el método de copia de servidor o copia directa y configurar la migración, cree el archivo migrationd.cmd. Lleve a cabo las siguientes tareas:
migrationd.cmd.Inicie sesión en el servidor de metadatos de Oracle HSM como root.
root@solaris:~#
Abra el archivo /etc/opt/SUNWsamfs/migrationd.cmd en un editor de texto.
En el ejemplo, se abre el archivo nuevo en el editor vi y se agrega un comentario inicial:
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd # /etc/opt/SUNWsamfs/migrationd.cmd # A configuration file for migrating data from old tape volumes to replacements
Si solamente necesita migrar algunos volúmenes, especifique cada volumen de origen, volumen de destino y dirección de migración. Para cada volumen de origen, introduzca una línea con el formato migrate = from source to destination, donde:
media_type es el código de dos letras que identifica el tipo de medio que aloja el volumen de origen (consulte el Apéndice A, Glosario de tipos de equipos para obtener detalles).
VSN es el número de serie de volumen único que identifica un volumen de cinta en una biblioteca.
En el ejemplo, se migran datos de una cinta LTO (li) antigua, VOL305, a un nuevo cartucho de cinta Oracle StorageTek T10000 (ti), VOL820:
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd # /etc/opt/SUNWsamfs/migrationd.cmd # A configuration file for migrating data from old tape volumes to replacements # Migrate a single volume. migrate = from li VOL305 to ti VOL820
Si necesita migrar un número significativo de volúmenes, defina agrupaciones de medios para los volúmenes de origen y de destino. Defina cada agrupación introduciendo una línea con el formato vsnpool = poolname library equipment_number media_type VSNlist, donde:
name identifica de forma única la agrupación.
equipment-number es el número ordinal que el archivo mcf asigna a la biblioteca que aloja los volúmenes de origen.
media_type es el código de dos letras que identifica el tipo de medio que aloja el volumen de origen (consulte el Apéndice A, Glosario de tipos de equipos para obtener detalles).
VSNlist es una lista delimitada por espacios de VSN literales o expresiones regulares que identifican grupos y rangos de VSN.
En el ejemplo, se migran datos de volúmenes de cinta LTO4 (li) antiguos a cartuchos de cinta LTO6 (ti) nuevos. Se agrega una línea para una agrupación de origen, pool1, que representa los volúmenes LTO4 en la biblioteca 20 que se migrarán. Estos incluyen volúmenes que tienen VSN en el rango de VOL000 a VOL299 y dos volúmenes únicos: VOL300 y VOL304. A continuación, se agrega una línea para una agrupación de destino, pool2, que representa un rango de volúmenes LTO6 en la biblioteca 30.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd # /etc/opt/SUNWsamfs/migrationd.cmd # A configuration file for migrating data from old tape volumes to replacements # pool1 contains the source volumes vsnpool = pool1 library 20 li ˆVOL[0-2][0-9][0-9] VOL300 VOL304 # pool2 contains the destination volumes vsnpool = pool2 library 30 li ˆVOL50[0-9]
Si ya definió agrupaciones de medios de origen y de destino, especifique la dirección de la migración. Introduzca una línea con el formato migrate = from sourcepool to destinationpool, donde:
sourcepool es la agrupación de medios que contiene los datos que se migrarán.
destinationpool es la agrupación de medios que recibirá los datos migrados.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... vsnpool = pool1 library 20 li ˆVOL[0-2][0-9][0-9] VOL300 VOL304 # pool2 contains the destination volumes vsnpool = pool2 library 30 ti ˆVOL50[0-9] # Migrate data from tapes in pool1 to tapes in pool2. migrate = from pool1 to pool2
Si tiene previsto utilizar exclusivamente el método de migración de copia de servidor, desactive la función xcopy. Introduzca una línea con el formato xcopy = off.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # Disable xcopy and the StorageTek T10000 Extended Copy feature. xcopy = off
Si tiene previsto utilizar exclusivamente la función de copia extendida de StorageTek T10000 y no desea migrar datos cuando las unidades que admiten esta función no están disponibles, active únicamente la migración xcopy. Introduzca una línea con el formato xcopy = only.
En el ejemplo, se activa únicamente xcopy. Si la unidad de origen o la unidad de destino no admiten la función de copia extendida, el software de migración cancelará automáticamente la migración:
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # Enable xcopy, StorageTek T10000D Extended Copy feature. # If the source or destination is not xcopy capable, cancel migration. xcopy = only
Si tiene previsto aprovechar la función de copia extendida de StorageTek T10000 cuando sea posible, active el método de migración xcopy. Introduzca una línea con el formato xcopy = on.
En el ejemplo, se activa xcopy aun si es posible que las unidades compatibles no estén siempre disponibles durante el período de migración. Si la unidad de origen o la unidad de destino no admiten la función de copia extendida, el software de migración cambiará automáticamente al modo de copia de servidor:
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # Enable xcopy, StorageTek T10000D Extended Copy feature. # If the source or destination is not xcopy capable, automatically switch # to the server buffer copy. xcopy = on
Si tiene previsto utilizar el método xcopy para migrar volúmenes de cinta que contienen pocos archivos caducados, configure xcopy para que se ejecute en modo de fin de datos (eod). Introduzca una línea con el formato xcopy_eod = on.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy = on xcopy_eod = on
Si tiene previsto utilizar el método xcopy para migrar volúmenes de cinta que contienen números significativos de archivos caducados, configure xcopy para que se ejecute en modo de reempaquetado. Introduzca una línea con el formato xcopy_eod = off.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy = on xcopy_eod = off
Especifique la cantidad mínima de datos que debe copiarse antes de que xcopy pueda ser interrumpido por una tarea de archivado o almacenamiento provisional de mayor prioridad. Introduzca una línea con el formato xcopy_minsize = amountunits, donde:
amount es un número entero.
units es k para kilobytes, M para megabytes, G para gigabytes, T para terabytes, P para petabytes o E para exabytes.
Este valor define un compromiso entre la utilización eficaz de unidades T10000 y la disponibilidad de unidades para otras tareas. Los valores más altos escriben datos en las unidades más eficazmente. Los valores más bajos aumentan la disponibilidad de las unidades para archivado y almacenamiento provisional. En el ejemplo, se configura el tamaño de copia mínimo en 30 gigabytes:
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy_eod = on # xcopy can be interrupted after 30GB copied. xcopy_minsize = 30G
Defina el período diario durante el cual pueden ejecutarse los trabajos de migración. Introduzca una línea con el formato runtime = window, donde window es uno de los siguientes valores:
always permite que el daemon de migración migre los datos cuando las unidades y los medios no se necesitan para archivado o almacenamiento provisional. Si el daemon de migración está utilizando unidades o medios que son necesarios para archivado o almacenamiento provisional, los cede.
start_time end_time, donde start_time y end_time son, respectivamente, las horas en que comienza y finaliza el período permitido, expresadas como horas y minutos en un reloj de 24 horas (HHMM).
Puede anular esta directiva en cualquier momento con los comandos samcmd, migstart, migidle o migstop.
El servicio de migración cede volúmenes y unidades cuando son requeridos por el proceso de almacenamiento provisional o el archivador. Por lo tanto, a menos que tenga problemas con el archivado o el almacenamiento provisional (por ejemplo, durante las horas de mayor actividad), debe aceptar el valor por defecto always:
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy_minsize = 30G # Run all of the time. Migration daemon will yield VSNs and drives when # resources are wanted by the SAM-QFS archiver and stager. run_time = always
Especifique un directorio de log para activar el registro. Introduzca una línea con el formato logdir = path, donde path es la ruta del directorio y el nombre del directorio.
Una vez que se define el directorio, el daemon de migración registra el destino de cada archivo de almacenamiento que migra desde cada volumen de origen. Cada volumen de origen tiene su propio archivo log, denominado media_type.VSN, donde:
media_type es un código de dos letras que identifica el tipo de medio de origen (consulte el Apéndice A, Glosario de tipos de equipos para obtener detalles).
VSN es el número de serie de volumen único que identifica el volumen de origen.
Por ejemplo, el archivo log para el volumen de origen con el VSN VOL300 sería denominado li.VOL300.
Al igual que el log de archivador, estos logs de migración pueden ser muy valiosos durante la recuperación ante desastres (consulte Comprensión de los puntos de recuperación y los archive logs y la Guía de recuperación del sistema de archivos Oracle Hierarchical Storage Manager and StorageTek QFS Software para obtener detalles). Por lo tanto, siempre especifique un directorio de log si es posible. Seleccione una ubicación que no se verá afectada por la falla de software o hardware de Oracle HSM, como /var/adm/. En el ejemplo, se especifica el directorio /var/adm/hsm_migration_logs:
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... run_time = always # Log directory for the migration logs. logdir = /var/adm/hsm_migration_logs
Especifique un directorio raíz para la migración de bases de datos de inode. Introduzca una línea con el formato dbdir = path, donde path es un nombre de ruta de directorio absoluta.
Se crea una base de datos de inode para cada volumen de origen y se conserva por la duración de la migración. Se crea un registro de base de datos de 224 bytes para cada copia de archivo encontrada en el volumen de origen. Por lo tanto, debe elegir una ubicación que tenga suficiente espacio en disco para alojar el mayor número de copias posible en el medio de origen. Por ejemplo, cada volumen Oracle StorageTek T10000D puede contener hasta 8.200.104.892 copias de archivo. Por lo tanto, necesitará alrededor de 1,67 terabytes de espacio en la base de datos para cada volumen T10000D que se migre en cualquier momento dado (consulte la página del comando man migration.cmd (1m) para obtener detalles).
La ubicación de la base de datos por defecto es /var/opt/SUNWsamfs/sammig/db. En el ejemplo, se especifica el directorio por defecto:
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... logdir = /var/adm/hsm_migration_logs # database home directory dbdir = /var/opt/SUNWsamfs/sammig/db
Configure el tamaño del buffer de migración para el dispositivo de destino. Introduzca una línea con el formato buffsize = media_type blocks, donde:
media_type es el código de dos letras que identifica el tipo de medio que aloja el volumen de origen (consulte el Apéndice A, Glosario de tipos de equipos para obtener detalles).
size es un número entero en el rango [2-8192], donde el valor entero especifica el número de bloques de cinta que el buffer deberá poder alojar. El valor por defecto es 64.
En el ejemplo, se asigna espacio suficiente para alojar el número por defecto de bloques de cinta Oracle StorageTek T10000.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # database home directory dbdir = /var/opt/SUNWsamfs/sammig/db # allocate buffer space for 64 T10000D tape blocks bufsize = ti 64
Especifique el número máximo de unidades que pueden utilizarse para migración por biblioteca. Introduzca una línea con el formato max_drives = library-list, donde:
library-list es una lista delimitada por espacios de entradas de biblioteca, cada una con el formato library equipment-number device-count.
equipment-number es el número ordinal de equipo asignado a la biblioteca en el archivo mcf.
device-count es el número de unidades que pueden utilizarse en la biblioteca especificada. Por defecto, device-count está configurado en el número de unidades de la biblioteca.
El servicio de migración cede volúmenes y unidades cuando son requeridos por el proceso de almacenamiento provisional o el archivador. Por lo tanto, a menos que tenga problemas con el archivado o el almacenamiento provisional, debe aceptar la configuración por defecto y permitir que la migración utilice cualquier unidad libre. En el ejemplo, se observa que debemos limitar el uso de unidades. Por lo tanto, se asignan ocho unidades para migración en la biblioteca 20, seis en la biblioteca 30 y dos en la biblioteca 40:
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... dbdir = /var/opt/SUNWsamfs/sammig/db # allocate buffer space for 64 T10000D tape blocks bufsize = ti 64 # For migration, use 8 drives in library 20, 6 in 30, and 2 in 40 max_drives = library 20 8 library 30 6 library 40 2
Especifique el número máximo de operaciones de copia relacionadas con la migración que pueden ejecutarse al mismo tiempo. Introduzca una línea con el formato max_copy = processes, donde processes es un número entero.
El valor por defecto es el valor máximo, que es igual al número de unidades configuradas en todas las bibliotecas enumeradas en el archivo mcf dividido por 2. En el ejemplo, se permiten hasta ocho procesos de copia simultáneos:
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... bufsize = ti 64 # For migration, use 8 drives in library 20, 6 in 30, and 2 in 40 max_drives = library 20 8 library 30 6 library 40 2 # Up to 8 sam-migcopy process can be run simultaneously. max_copy = 8
Especifique el número máximo de operaciones de análisis de cinta relacionadas con la migración que pueden ejecutarse al mismo tiempo. Introduzca una línea con el formato max_scan = processes, donde processes es un número entero.
Para identificar copias de archivo en los VSN de origen de migración, el daemon sam-migrationd analiza todos los sistemas de archivos configurados en mcf, lee todos los inodes desde la caché de disco y compara el campo vsn de cada inode con los números de serie de volumen (VSN) de los volúmenes de origen de migración. El proceso aumenta la actividad de metadatos en el sistema de archivos y, por lo tanto, puede afectar negativamente el rendimiento del sistema.
Seleccione el valor que mejor equilibre el rendimiento aceptable del sistema de archivos con la velocidad de migración, o acepte el valor por defecto, 4, para la mayoría de los usos. Si tiene previsto desactivar el sistema de archivos para lograr una migración más rápida, configure max_scan en 0, de modo que todos los volúmenes de origen se analicen a la vez. En el ejemplo, se sabe por experiencia que se pueden permitir hasta ocho procesos de análisis simultáneos sin que se vean afectadas las operaciones normales del sistema de archivos:
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... bufsize = ti 64 # For migration, use 8 drives in library 20, 6 in 30, and 2 in 40 max_drives = library 20 8 library 30 6 library 40 2 # Run up to 8 sam-migcopy processes simultaneously. max_copy = 8 # Scan up to 8 VSNs simultaneously. max_scan = 8
Guarde el archivo y cierre el editor.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd
...
max_copy = 8
# Scan up to 8 VSNs simultaneously.
max_scan = 8
:wq
root@solaris:~#
Las instrucciones de esta sección describen la introducción de comandos desde el símbolo del sistema de shell mediante el comando samcmd. Tenga en cuenta que todos los comandos también pueden introducirse desde la interfaz samu, con el formato :command, donde command es el nombre del comando.
Si aún no ha iniciado sesión en el servidor de metadatos de Oracle HSM como root, inicie sesión ahora.
root@solaris:~#
Asegúrese de que no haya una migración anterior activa o incompleta. Primero, compruebe el estado de migración actual. Utilice el comando samcmd x.
Si hay otro trabajo de copia de migración en curso, el comando enumera los volúmenes de origen y de destino, por tipo de medio y VSN, el modo de copia, el porcentaje completo y el estado actual de la copia:
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year samcmd on hsm61sol Status: Stop: Waiting for :migstart source dest cmod perc status li VOL004 li VOL042 - 60% Copy idled
De lo contrario, si no se están ejecutando otros trabajos de copia de migración, el comando no muestra ningún trabajo:
root@solaris:~# samcmd x Migration status samu ver time date Source Vsns - wait: 0 fsscan: 0 copy: 0 update ino: 0 log: 0 done: 0 Status: Idle: Waiting for :migstart source dest cmod perc status
A continuación, compruebe el estado de los volúmenes de origen (S) o destino (D) actuales. Utilice el comando samcmd y.
En el primer ejemplo, el valor de end time del trabajo para los únicos volúmenes de origen y de destino enumerados es 10/16 12:14. La copia del volumen de origen está completa. Por lo tanto, no hay trabajos en ejecución:
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOLa01 10/16 12:12 10/16 12:14 complete 35023/35023 550.00M 0 D li VOLa80 10/16 12:12 10/16 12:14 avail 550.00M
En el segundo ejemplo, el valor de end time del trabajo para los volúmenes de origen y de destino es none. El volumen de origen aún se está copiando al volumen de destino. Por lo tanto, hay un trabajo de migración todavía en ejecución:
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOLa02 10/16 12:12 none copy 0/35023 164.50M 0 D li VOLa81 10/16 12:12 none copy 148.75M
Por último, compruebe las listas de volúmenes en el catálogo de la biblioteca. Utilice el comando samcmd v. Busque los siguientes indicadores en la salida:
R significa que el volumen es de solo lectura. Cuando se inicia la migración, los volúmenes de origen están marcados como solo lectura.
S (origen) significa que los datos aún se están copiando desde este volumen.
D (destino) significa que los datos aún se están copiando a este volumen.
m significa que el volumen de origen finalizó la migración.
e significa que el volumen de origen no se pudo migrar debido a un error.
En el ejemplo, el volumen VOLa01 se migró a VOLa80 correctamente. El volumen VOLa02 aún se está migrando a VOLa81.
root@solaris:~# samcmd v Robot catalog samcmd version HH:MM:SS month day year Robot VSN catalog by slot : eq 800 slot access time count use flags ty vsn count 64 0 2015/06/29 17:00 1 95% -il---b--Rm- li VOLa01 1 2015/07/02 17:43 2 89% -il-o-b--RS- li VOLa02 2 2015/07/02 18:31 2 89% -il-o-b--Re- li VOLa03 ... 51 2015/10/16 15:18 2 82% -il-o-b----- li VOLa80 52 2015/10/16 15:25 2 84% -il-o-b---D- li VOLa81
Si hay trabajos en ejecución, espere a que finalicen.
De lo contrario, una vez que se haya asegurado de que no hay migraciones en curso, realice la Migración de volúmenes.
Las instrucciones de esta sección describen la introducción de comandos desde el símbolo del sistema de shell mediante el comando samcmd. Tenga en cuenta que todos los comandos también pueden introducirse desde la interfaz samu, con el formato :command, donde command es el nombre del comando.
Si aún no ha iniciado sesión en el servidor de metadatos de Oracle HSM como root, inicie sesión ahora.
root@solaris:~#
Asegúrese de que el sistema de archivos de origen esté montado.
Active el archivo migrationd.cmd. Utilice el comando samcmd migconfig.
Si la configuración se realiza correctamente, el comando muestra el mensaje Configuring migration y le indica que consulte el archivo log para obtener detalles:
root@solaris:~# samcmd migconfig samcmd: migconfig: Configuring migration (see /var/opt/SUNWsamfs/sammig/logfile) root@solaris:~#
De lo contrario, el comando se detiene y genera un error. Posiblemente no haya detenido el proceso de migración antes de ejecutar el comando de configuración o haya detenido la migración mientras un volumen de cinta estaba en espera de migración:
root@solaris:~# samcmd migconfig samcmd: migconfig: Can't configure migration, migration status is not stop, or migration job is pending root@solaris:~#
Visualice la configuración de migración. Utilice el comando samcmd y.
Si la configuración se realizó correctamente, se enumeran los volúmenes especificados, el estado del volumen de origen es sched_wait (programado, en espera) y el estado del volumen de destino es avail (disponible). En el ejemplo, la configuración se realizó correctamente:
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year samcmd on hsm61sol Status: Stop: Waiting for :migstart Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 none none sched_wait 0/0 0 0 D li VOL501 none none avail 0
Si la configuración se realizó correctamente, inicie la migración. Utilice el comando samcmd migstart.
root@solaris:~# samcmd migstart samcmd: migstart: State changed to start root@solaris:~#
Compruebe el estado de la migración. Utilice los comandos samcmd x y samcmd y.
En el ejemplo, la migración acaba de empezar. La pantalla Migration status muestra que el estado del trabajo es Run, que hay 1 copia en curso con el modo de copia (cmod) s (servidor), que se completó 0% de la copia, que se actualizaron 0 inodes y que el volumen de origen aún está en estado Loading:
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year Source Vsns - wait: 0 fsscan: 0 copy: 1 update ino: 0 log: 0 done: 0 Status: Run source dest cmod perc status li VOL001 li VOL501 s 0% Loading li.VOL001
La pantalla Migration vsn list muestra que hay 2 volúmenes actualmente en proceso, 1 de origen y 1 de destino. El estado de ambos volúmenes es ahora copy para mostrar que el origen se están copiando al destino. En este punto, se copiaron 0 bytes del origen al destino y no se actualizó ninguno de los 35023 inodes:
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 10/16 12:12 none copy 0/35023 0 0 D li VOL501 10/16 12:12 none copy 0
Vuelva a comprobar el estado de la migración periódicamente con los comandos samcmd x y samcmd y.
En el ejemplo, la pantalla Migration status muestra que ahora se completó 23% de la copia y que se leyeron 560 (0x00000230) bloques de cinta del origen:
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year Source Vsns - wait: 0 fsscan: 0 copy: 1 update ino: 0 log: 0 done: 0 Status: Run source dest cmod perc status li VOL001 li VOL501 s 24% 0x00000230 blocks read
La pantalla Migration vsn list muestra que se leyeron 164.50 megabytes del volumen de origen y que se escribieron 148.75 megabytes al volumen de destino:
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 10/16 12:12 none copy 0/35023 164.50M 0 D li VOL501 10/16 12:12 none copy 148.75M
Cuando se completa la migración, compruebe el estado de finalización. Utilice los comandos samcmd x y samcmd y, y consulte el archivo log de migración:
En el ejemplo, los volúmenes de origen y de destino ya no aparecen en la pantalla Migration status, que ahora muestra que se realizó 1 copia. Observe que el estado de migración es aún Run y permanecerá así hasta introducir los comandos migidle o migstop:
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year Source Vsns - wait: 0 fsscan: 0 copy: 0 update ino: 0 log: 0 done: 1 Status: Run source dest cmod perc status
La pantalla Migration vsn list muestra que se leyeron 550.00 megabytes del volumen de origen y que se escribieron 550.50 megabytes al volumen de destino: Los 35023 inodes se actualizaron para reflejar las nuevas ubicaciones de las copias de archivo migradas:
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 10/16 12:12 10/16 12:14 complete 35023/35023 550.00M 0 D li VOL012 10/16 12:12 10/16 12:14 avail 550.00M
El archivo log del daemon de migración enumera todas las etapas de la migración y finaliza con un resumen. En el ejemplo, se utiliza el comando de Solaris tail para ver las entradas más recientes:
root@solaris:~# tail /var/opt/SUNWsamfs/sammig/logfile date time Info: Schedule: Create VsnList file. date time Info: Schedule: VsnList file created, source: 1, destination: 1. date time Info: Schedule: Migration status changed to Start. date time Info: 'li.VOL001' Filesystem scan: Started date time Info: 'li.VOL001' Filesystem scan: Completed, total copy bytes: 517.2M, inodes: 35023, multi vsn copy: 0, removable-media file: 0, obsolete copy: 0 date time Info: 'li.VOL001' Copy: Started, pid: 2459 destination 'li.VOL012' date time Info: 'li.VOL001' Copy: Mode - server copy date time Info: 'li.VOL001' Copy: Server copy started from position 0x4. date time Info: 'li.VOL001' Copy: Tar header check started from position 0x4. date time Info: 'li.VOL001' Copy: Tar header check succeeded, 5 inodes checked, 0 tar header error found. date time Info: 'li.VOL001' Copy: Completed, pid: 2459, exit status: 12, signal: 0 date time Info: 'li.VOL001' Update inode: Started, source position: 0 date time Info: 'li.VOL001' Update inode: Completed. date time Info: 'li.VOL001' Log: Started, source position: 0 date time Info: 'li.VOL001' Log: Completed. date time Summ: 'li.VOL001' date time Summ: 'li.VOL001' =============== Summary =============== date time Summ: 'li.VOL001' Status: Complete date time Summ: 'li.VOL001' Copy mode: Server copy date time Summ: 'li.VOL001' Start at: date time date time Summ: 'li.VOL001' End at: date time date time Summ: 'li.VOL001' Bytes: 550.00M date time Summ: 'li.VOL001' Archive copies: 35023 date time Summ: 'li.VOL001' Read error copies: 0 date time Summ: 'li.VOL001' Multi vsn copies: 0 date time Summ: 'li.VOL001' Removable-Media file: 0 date time Summ: 'li.VOL001' ---Dest--- ---Bytes--- ---Copies--- date time Summ: 'li.VOL001' li VOL501 550.00M 35023 root@solaris:~#
Por último, asegúrese de copiar los logs de migración de volúmenes a una ubicación segura.
Estos logs registran el volumen de destino y la posición inicial para cada copia del archivo de almacenamiento migrada fuera del volumen de origen. Esta información es crítica cuando necesita recuperar archivos o sistemas de archivos. Por lo tanto, Oracle recomienda conservar copias de seguridad de estos archivos junto con los archivos de punto de recuperación y los archivos log del archivador, como se describe en el Capítulo 7, Copia de seguridad de la configuración y los sistemas de archivos y en el capítulo correspondiente de la Guía de configuración e instalación de Oracle Hierarchical Storage Manager and StorageTek QFS.
El daemon de migración crea archivos log de migración en el directorio especificado en el archivo migrationd.cmd. Para cada volumen migrado, se crea un archivo denominado media_type.VSN donde:
media_type es un código de dos letras que identifica el tipo de medio de origen (consulte el Apéndice A, Glosario de tipos de equipos para obtener detalles).
VSN es el número de serie de volumen único que identifica el volumen de origen.
En el ejemplo, se copian los logs de volumen desde el directorio de log especificado, /var/adm/hsm_migration_logs/, hasta el directorio donde mantenemos los recursos de recuperación del sistema de archivos en un sistema de archivos remoto montado en NFS.
root@solaris:~# ls /var/adm/hsm_migration_logs/ li.VOL001 li.VOL002 li.VOL003 li.VOL004 li.VOL005 li.VOL006 ... ti.801 ... root@solaris:~# cp /var/adm/hsm_migration_logs/*.* /zfs/recover/hsmfs1/2015mig/
Cuando se hayan vuelto a almacenar todos los archivos, considere la disposición de la cinta según sus requisitos (consulte Disposición de medios antiguos tras la migración).
Deténgase aquí. Finalizó la migración.
Para migrar archivos de almacenamiento de un medio antiguo a uno nuevo con el método de almacenamiento provisional y rearchivado, debe identificar los archivos que migrará, almacenarlos provisionalmente en la caché de disco y, luego, escribirlos en el nuevo medio, sin interferir en las operaciones normales del sistema de archivos. En este, capítulo se tratan los siguientes etapas del proceso:
Los detalles del proceso de almacenamiento provisional y rearchivado dependen, en gran medida, de dos factores: la cantidad de almacenamiento en disco disponible y el número de unidades de medios extraíbles disponibles. Durante la migración de medios, el proceso de almacenamiento provisional de Oracle HSM carga los volúmenes extraíbles que pueden leer el formato de medios antiguo y restaura los archivos almacenados en la caché del disco. A continuación, el archivador Oracle HSM vuelve a archivar los archivos en los nuevos volúmenes extraíbles mediante unidades que pueden escribir el nuevo formato de medios. Por lo tanto, lo ideal sería almacenar todos los archivos en un volumen de cintas determinado en el disco de una vez y, luego, archivarlos inmediatamente en el medio nuevo.
Para ello, debería dedicar recursos significativos mientras dure la migración:
espacio en disco equivalente a la capacidad de toda la cinta.
uso exclusivo de una unidad que lee el formato de cinta antiguo.
uso exclusivo de una unidad que escribe el formato nuevo.
Lo anterior no es un problema si puede desactivar el sistema de archivos hasta que la migración se ha completado. Pero la migración de datos en un ambiente de producción, sin interferir de manera inadecuada con el sistema de archivos actual y las operaciones de archivado requiere planificación. Si el espacio en disco o las unidades de cinta son escasas, necesitará identificar los recursos que puede reservar razonablemente para migración y, luego, ajustar el proceso de migración. Realice lo siguiente:
Calcule la cantidad de caché en disco que puede utilizar para migración sin impedir las operaciones normales del sistema de archivos.
Calcule el número de unidades de cintas que puede obtener para dedicar a la migración.
Si solo hay una cantidad limitada de unidades de cinta disponibles, planee reducir los procesos de almacenamiento y archivado a fin de que el proceso de migración no impida las operaciones normales.
En base a los cálculos anteriores, tome una decisión sobre los parámetros de almacenamiento y archivado. Determine el número máximo de archivos de migración que contendrá el espacio en disco disponible en cualquier momento y la velocidad máxima a la cual es posible mover archivos de la caché hacia el nuevo medio.
Una vez que haya calculado los recursos, planifique la disposición de los medios antiguos tras la migración.
Agregue el medio nuevo al archivo archiver.cmd y modifique las directivas de copia de archivo de modo que siempre se realice una copia usando los medios nuevos.
Abra el archivo /etc/opt/SUNWsamfs/archiver.cmd en un editor de texto.
La política de archivado especifica dos copias, que están escritas en el tipo de medio que queremos reemplazar. En el ejemplo, abrimos el archivo en el editor vi. Queremos reemplazar los cartuchos DLT (tipo lt):
root@solaris: vi /etc/opt/SUNWsamfs/archiver.cmd # ============================================= # /etc/opt/SUNWsamfs/archiver.cmd # --------------------------------------------- ... # --------------------------------------------- # VSN Directives vsns allfiles.1 lt .* allfiles.2 lt .* endvsns
En las directivas de la copia 2, cambie el tipo de medio específico para el identificador de los medios nuevos, guarde el archivo y cierre el editor de texto.
En el ejemplo, queremos migrar datos desde las cintas DLT antiguas hacia cartuchos LTO nuevos. Por lo tanto, en la copia 2, cambiamos el tipo de medio antiguo, lt (DLT), a li (LTO):
root@solaris: vi /etc/opt/SUNWsamfs/archiver.cmd # ============================================= # /etc/opt/SUNWsamfs/archiver.cmd # --------------------------------------------- ... # --------------------------------------------- # VSN Directives vsns allfiles.1 lt .* allfiles.2 li .* endvsns :wq root@solaris:~#
Revise el archivo archiver.cmd para detectar errores de sintaxis. Ejecute el comando archiver -lv y corrija los errores hasta no encontrar más errores.
El comando archiver -lv imprimirá el archivo línea por línea. Si encuentra un error, dejará de ejecutarse en el punto donde se produjo el error.
root@solaris:~# archiver -lv Reading '/etc/opt/SUNWsamfs/archiver.cmd'. 1: # ============================================= 2: # /etc/opt/SUNWsamfs/archiver.cmd 3: # --------------------------------------------- 4: # Global Directives 5: logfile = /var/opt/SUNWsamfs/archiver.log 6: # --------------------------------------------- 7: # File System Directives: 8: fs = samqfsms 9: all . 10: 1 5m ... root@solaris:~#
Una vez que el archivo modificado archiver.cmd esté libre de errores, cárguelo en la configuración actual mediante el comando samd config:
root@solaris:~# samd config Configuring SAM-FS root@solaris:~#
A continuación, migre datos de un cartucho a otro.
El método de almacenamiento provisional y archivado para migrar datos utiliza sfind, la extensión de Oracle HSM del comando GNU find. El comando sfind se utiliza para ubicar archivos en un volumen de cintas específico y lanzar los comandos stage y rearchive contra todos los archivos encontrados.
Si no conoce los comandos sfind, stage y/o rearchive, revise ahora las respectivas páginas del comando man. Para cada cartucho de cintas que contiene datos que se deben migrar, haga lo siguiente:
Inicie sesión en el host del sistema de archivos como root.
root@solaris:~#
Diríjase al directorio del punto de montaje para el sistema de archivos que contiene los archivos que está migrando.
En el ejemplo, se migran copias de los archivos almacenados en el sistema de archivos hsmfs1 montado en /hsm/hsmfs1:
root@solaris:~# cd /hsm/hsmfs1 root@solaris:~#
Seleccione un volumen de cinta.
Cuando migra datos entre tipos de medios, trabaje con un volumen a la vez. En los ejemplos que se muestran a continuación, se trabaja con un número de serie de volumen VOL008.
Primero, busque en el volumen seleccionado los archivos dañados que no se puedan almacenar correctamente. Utilice el comando sfind . -vsn volume-serial-number -damaged de Oracle HSM, donde volume-serial-number es la cadena alfanumérica que identifica de manera única el volumen dentro de la biblioteca.
En el ejemplo, comenzamos la búsqueda desde el directorio de trabajo actual (.). El parámetro -vsn limita la búsqueda a los archivos que se encuentran en nuestra cinta actual, VOL008. El indicador -damaged limita la búsqueda a los archivos que no se pueden almacenar exitosamente:
root@solaris:~# sfind . -vsn VOL008 -damaged
Si la búsqueda sfind de archivos dañados devuelve cualquier resultado, intente reparar el archivo. Utilice el comando undamage -m media-type -vsn volume-serial-number file, donde:
media-type es uno de los códigos de tipos de medios de dos caracteres que se muestran en Apéndice A.
volume-serial-number es la cadena alfanumérica que identifica el volumen de manera única.
file es la ruta de acceso y el nombre del archivo dañado.
En ocasiones, un error de E/S transitoria hace que la copia se marque como dañada. El comando undamage de Oracle HSM borra este estado. En el ejemplo, la copia del archivo de almacenamiento /hsm/hsmfs1/data0008/20131025DAT se informa como dañada. Por lo tanto, se repara y se vuelve a intentar la búsqueda de archivos dañados:
root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged
Si el comando sfind vuelve a mostrar el archivo como dañado, la copia no se puede utilizar. Consulte si el archivo de almacenamiento contiene otra copia del archivo que no esté dañada. Para mostrar las copias disponibles, utilice el comando sls -D file, donde file es la ruta y el nombre del archivo. Para comprobar el estado de las copias encontradas, utilice el comando sfind file -vsn volume-serial-number.
En el ejemplo, el comando undamage no puede solucionar la copia. Por lo tanto, se utiliza sls para enumerar todas las copias del archivo /hsm/hsmfs1/data0008/20131025DAT:
root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sls -D /hsm/hsmfs1/data0008/20131025DAT 20131025DAT: mode: -rw-r--r-- links: 1 owner: root group: other length: 319279 admin id: 7 inode: 1407.5 project: system(0) offline; archdone; stage -n; copy 1: ---- May 21 07:12 1e4b1.1 lt VOL008 copy 2: ---- May 21 10:29 109c6.1 lt VOL022 ...
El volumen de cinta VOL022 aloja una segunda copia del archivo. Por lo tanto, se controla la segunda copia con sfind:
root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged
Si una copia no se puede utilizar y existe otra copia del archivo que no está dañada, almacene nuevamente el archivo. A continuación, una vez el archivo de almacenamiento contenga dos copias correctas, desarchive la copia dañada.
En el ejemplo, la copia 1 del archivo /hsm/hsmfs1/data0008/20131025DAT en el volumen VOL008 es inutilizable, pero el comando sfind no detectó daños en la copia 2. Por lo tanto, se ejecuta el comando archive con la opción -c para crear una copia 1 válida antes de desarchivar la copia dañada en el volumen VOL008:
root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged root@solaris:~# archive -c 1 /hsm/hsmfs1/data0008/20131025DAT ... root@solaris:~# unarchive -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT
Si no existen copias correctas, consulte si el archivo reside en la caché. Utilice el comando sfind . -vsn volume-serial-number -online.
En el ejemplo, tanto la copia 1 del volumen VOL008 como la copia 2 del volumen VOL022 están dañadas e inutilizables. De esta manera, se puede ver si el archivo está disponible en línea, en la caché de disco:
root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -online
Si no existen copias utilizables, pero el archivo reside en la caché, almacénelo. A continuación, una vez el archivo de almacenamiento contenga dos copias correctas, desarchive la copia dañada.
En el ejemplo, tanto la copia 1 en el volumen VOL008 como la copia 2 en el volumen VOL022 son inutilizables; por lo tanto, ejecutamos el comando archive para crear dos copias válidas antes de desarchivar la copia dañada en el volumen VOL008:
root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -online /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# archive /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# unarchive -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT
Si no existen copias correctas y si el archivo no reside en la caché del disco, es probable que se hayan perdido los datos. Si los datos son de vital importancia, consulte a una empresa especialista en recuperación de datos para pedir ayuda. De lo contrario, desarchive la copia dañada.
En el ejemplo, tanto la copia 1 del volumen VOL008 como la copia 2 del volumen VOL022 son inutilizables. El comando sfind no pudo encontrar el archivo en la caché de disco. Los datos no son críticos. Por lo tanto, desarchivamos la copia dañada en el volumen VOL008:
root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -online root@solaris:~# archive /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# unarchive -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT
Si la búsqueda sfind de archivos dañados no arroja resultados, almacene de manera provisional los archivos de la cinta actual a la caché del disco. Utilice el comando sfind . -vsn volume-serial-number -offline -exec stage {}\;
El parámetro -vsn limita la búsqueda a los archivos que se encuentran en la cinta actual (siempre migre los datos de una cinta a la vez).
El parámetro -offline restringe aún más la salida de sfind a los archivos que todavía no residen en la caché, de modo que los datos no se sobrescriban.
El argumento -exec stage {}\; toma cada ruta y nombre de archivo que sfind devuelve y lo utiliza como el argumento para un comando stage de Oracle HSM. Luego, el comando stage restaura el archivo específico a la caché del disco. El proceso se repite hasta que todos los archivos elegibles se han almacenado de manera provisional.
En el ejemplo, el comando sfind -vsn VOL008 -damaged no devuelve ninguna salida. Por lo tanto, utilizamos sfind para almacenar de manera provisional todos los archivos que se encuentran en VOL008 y que todavía no están en la caché:
root@solaris:~# sfind . -vsn VOL008 -damaged root@solaris:~# sfind . -vsn VOL008 -offline -exec stage {}\;
Una vez que se han almacenado los archivos de la cinta, vuelva a archivarlos de manera selectiva. Utilice el comando sfind . -vsn volume-serial-number -online -exec rearch -r -m media-type {}\; donde media-type es el tipo de medio desde el que está migrando.
El parámetro -vsn limita la búsqueda a los archivos que también se encuentran en la cinta actual (siempre migre los datos de una cinta a la vez).
El parámetro -online restringe aún más la salida sfind a los archivos que residen en la caché, de modo que los datos no se sobrescriben.
El argumento -exec rearch -r -m media-type {}\; toma cada ruta y nombre de archivo que sfind devuelve y lo utiliza como el argumento para un comando rearch -r -m media-type de Oracle HSM. El argumento -r ejecuta el proceso de forma recursiva mediante subdirectorios. El argumento -m vuelve a archivar solamente los archivos que residen en el medio de origen.
En el ejemplo, el valor del parámetro -vsn es VOL008, y el valor del parámetro -m especifica lt, para medios DLT:
root@solaris:~# sfind . -vsn VOL008 -online -exec rearch -r -m lt {}\;
Repita el paso anterior hasta que no se encuentren más archivos en la búsqueda de sfind.
Cuando se hayan vuelto a almacenar todos los archivos, elimine la cinta tal como lo ha planeado (consulte Disposición de medios antiguos tras la migración).
Repita este procedimiento hasta haber migrado lo datos desde los medios antiguos hacia los medios nuevos.
Una vez que completa una migración, los medios antiguos no necesariamente pierden todo el valor. Por lo tanto, debe considerar cuidadosamente su disposición.
Como mínimo, conserve los medios antiguos hasta haber acumulado suficientes archivos de puntos de recuperación nuevos para recuperar cualquier archivo del sistema de archivos utilizando solamente los medios de reemplazo nuevos.
Si el espacio de almacenamiento lo permite, conserve los medios antiguos indefinidamente. Siempre que haya unidades compatibles disponibles, los medios antiguos constituyen un recurso de recuperación y copia de seguridad muy valioso.
Si el espacio en la biblioteca es primordial, exporte los medios antiguos y consérvelos en una instalación de almacenamiento fuera del sitio.
Si los medios antiguos pueden reutilizarse y está seguro de que los datos que contienen ya no son útiles, vuelva a etiquetar los volúmenes antiguos. Por ejemplo, puede volver a etiquetar los medios para una unidad Oracle StorageTek T10000C anterior y utilizarlos con una unidad T10000D más reciente.
De lo contrario, si los datos en los volúmenes antiguos o los medios no tienen ningún valor, exporte los volúmenes de la biblioteca y realice una disposición adecuada.