7 Migración a medios de almacenamiento nuevos

Para migrar archivos de almacenamiento de un medio antiguo a uno nuevo, necesita identificar los archivos que migrará, almacenarlos de manera provisional en la caché del disco y, luego, escribirlos en el nuevo medio sin interferir con las operaciones normales del sistema de archivos Oracle Hierarchical Storage Manager. En este, capítulo se tratan los siguientes etapas del proceso:

Planificación de migración de datos
Editar el archivo archiver.cmd
Migración de datos hacia medios de reemplazo.

Planificación de migración de datos

Antes de comenzar a trasladar los datos, debe llevar a cabo las siguientes tareas.

Cálculo de los recursos disponibles
Planificación de la disposición de medios antiguos después de la migración.

Cálculo de los recursos disponibles

Los detalles del proceso de migración de datos real dependen, en gran medida, de dos factores: la cantidad de almacenamiento en disco disponible y la cantidad de unidades de cinta 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 ha calculado los recursos, continúe con Planificación de la disposición de medios antiguos después de la migración.

Planificación de la disposición de medios antiguos después de la migración

Después de la migración de datos, tal vez necesite (o no) conservar los medios anteriores. Por lo tanto, identifique sus requisitos y planee una eliminación de los medios ahora, antes de comenzar el proceso de migración de datos.

Si tiene archivos del punto de recuperación creados con samfsdump antes de la migración, los metadatos del sistema de archivos en el archivo de volcado todavía hacen referencia a los antiguos volúmenes de cintas. No podría restaurar el sistema de archivos a estos puntos de recuperación sin acceso a los datos en los medios originales. Entonces, como mínimo, debe conservar el medio antiguo hasta estar seguro de que no necesitará recuperar el sistema de archivos al estado en que se encontraba en el momento de creación de los antiguos archivos de punto de recuperación. Una vez que haya ejecutado samfsdump la suficiente cantidad de veces como para crear puntos de recuperación que hacen referencia a nuevos volúmenes, podrá eliminar los volúmenes antiguos.

Una vez que todos los archivos del punto de recuperación apunten a los medios nuevos, podrá exportar los volúmenes antiguos de la biblioteca robótica o actualizarlos y volver a etiquetarlos para volver a utilizar, según el tipo de medio. Por ejemplo, podría simplemente exportar los medios de DLT para su eliminación. Podría volver a etiquetar los medios para una unidad Oracle StorageTek T10000C anterior y utilizarlos con una unidad T10000D más nueva.

Después de decidir cómo eliminará los medios antiguos, estará listo para comenzar Configuración del proceso de archivado para migración.

Configuración del proceso de archivado para migración

Durante el proceso de migración, modifica el archivo de configuración del archivador, archiver.cmd, para incluir el tipo de medio de reemplazo nuevo junto al tipo que está reemplazando.

Editar el archivo `archiver.cmd`

Modifique el archivo archiver.cmd de manera de enviar la segunda copia a los medios nuevos. No existe motivo para agregar una copia de archivos adicional.

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:~# 
```
Luego, Migración de datos desde un cartucho al otro.

Migración de datos hacia medios de reemplazo

El procedimiento recomendado 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:

Migración de datos desde un cartucho al otro

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 samqfs1 montado en /samqfs1:
```
root@solaris:~# cd /samqfs1
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, Glosario de tipos de equipos.
- 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 /samqfs1/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
/samqfs1/data0008/20131025DAT
root@solaris:~# undamage -m lt -vsn VOL008 /samqfs1/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 usa sls para mostrar todas las copias del archivo /samqfs1/data0008/20131025DAT:
```
root@solaris:~# undamage -m lt -vsn VOL008 /samqfs1/data0008/20131025DAT
root@solaris:~# sfind . -vsn VOL008 -damaged
/samqfs1/data0008/20131025DAT
root@solaris:~# sls -D /samqfs1/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 /samqfs1/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 /samqfs1/data0008/20131025DAT en el volumen VOL008 es inutilizable, pero el comando sfind no encontró 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 /samqfs1/data0008/20131025DAT -vsn VOL022 -damaged
root@solaris:~# archive -c 1 /samqfs1/data0008/20131025DAT
...
root@solaris:~# unarchive -m lt -vsn VOL008 /samqfs1/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 /samqfs1/data0008/20131025DAT
root@solaris:~# sfind . -vsn VOL008 -damaged
/samqfs1/data0008/20131025DAT
root@solaris:~# undamage -m lt -vsn VOL022 /samqfs1/data0008/20131025DAT
root@solaris:~# sfind /samqfs1/data0008/20131025DAT -vsn VOL022 -damaged
/samqfs1/data0008/20131025DAT
root@solaris:~# sfind /samqfs1/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 /samqfs1/data0008/20131025DAT
root@solaris:~# sfind . -vsn VOL008 -damaged
/samqfs1/data0008/20131025DAT
root@solaris:~# undamage -m lt -vsn VOL022 /samqfs1/data0008/20131025DAT
root@solaris:~# sfind /samqfs1/data0008/20131025DAT -vsn VOL022 -damaged
/samqfs1/data0008/20131025DAT
root@solaris:~# sfind /samqfs1/data0008/20131025DAT -online
/samqfs1/data0008/20131025DAT
root@solaris:~# archive /samqfs1/data0008/20131025DAT
root@solaris:~# unarchive -m lt -vsn VOL008 /samqfs1/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 la caché del disco del archivo. 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 /samqfs1/data0008/20131025DAT
root@solaris:~# sfind . -vsn VOL008 -damaged
/samqfs1/data0008/20131025DAT
root@solaris:~# undamage -m lt -vsn VOL022 /samqfs1/data0008/20131025DAT
root@solaris:~# sfind /samqfs1/data0008/20131025DAT -vsn VOL022 -damaged
/samqfs1/data0008/20131025DAT
root@solaris:~# sfind /samqfs1/data0008/20131025DAT -online
root@solaris:~# archive /samqfs1/data0008/20131025DAT
root@solaris:~# unarchive -m lt -vsn VOL008 /samqfs1/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 Planificación de la disposición de medios antiguos después de la migración).
Repita este procedimiento hasta haber migrado lo datos desde los medios antiguos hacia los medios nuevos.