Migrar o copiar datos es una tarea que los administradores de sistema realizan frecuentemente. Existen diversas herramientas disponibles para estas tareas, incluyendo cp, tar y cplv.

David Tansley, System Administrator, Ace Europe

David TansleyDavid Tansley es escritor independiente. Tiene 15 años de experiencia como un administrador de UNIX, usando AIX los últimos 8 años. Disfruta jugar bádminton, después relajarse viendo la Fórmula 1, pero nada mejor que conducir su motocicleta GSA con su esposa.


Nivel de autor contribuyente en developerWorks

01-08-2011

Introducción

Migrar o mover datos es una tarea común. Ya sea copiando datos en toda la red en un nuevo sistema de archivos, o copiando volúmenes lógicos dentro del mismo grupo de volumen o a un grupo de volumen distinto o tal vez simplemente creando una copia de seguridad de un sistema de archivos. Las razones para mover o copiar datos pueden ser por problemas de rendimiento, o crecimiento general de datos donde no hay suficiente espacio en su entorno actual. Existen distintas herramientas que pueden usarse para loas tareas de movimiento de datos antes mencionadas, tales como migratepv, cplv, tar, cpio, cp o rsync. Para jfs, puede usar splitcopy o, para jfs2, usar una instantánea para tomar una copia de un sistema de archivos. No hay regla de oro sobre qué método se ajustaría mejor a un determinado movimiento de datos. En este artículo, demuestro distintos métodos para mover o copiar datos en un sistema de archivos y a un nivel de volumen lógico con un enfoque en las siguientes utilidades AIX: cplv, tar, y cp.


Usando tar y cp para copiar datos a un nuevo sistema de archivos

Al aplicar actualizaciones a un sistema de archivos de aplicaciones, una copia de seguridad sería tomada primero, muy probablemente en cinta. Sin embargo, si el espacio lo permite, también puede llevarse a cabo una copia del sistema de archivos donde la aplicación reside. La ventaja de esto es que permite una recuperación rápida. Al intercambiar los puntos de montaje, esto también es ventajoso porque puede comparar rápidamente los archivos actualizados con los originales. Asumamos que un sistema de archivos llamado /opt/pluto tiene una aplicación que va a ser actualizada:

# df -g
…
/dev/fslv00        1.00      0.03   97%       22     1% /opt/pluto

Veamos tres formas en que podemos copiar los archivos de la aplicación hacia otro sistema de archivos, usando cp, tar y cplv.

Primero, el sistema de archivos (copiado) de copia de seguridad necesita ser creado. Esto es llevado a cabo usando el comando crfs, asegurándose de que es el mismo tipo de sistema de archivos y al menos del mismo tamaño. El sistema de archivos /Pluto actual es de 1G de tamaño y es del tipo jfs2. El nuevo sistema de archivos es llamado /opt/pluto_bak. El siguiente comando consigue esto:

# crfs -v jfs2 -g rootvg -m /opt/pluto_bak -A yes -p rw -a agblksize=40
96 -a size=1G
File system created successfully.
524068 kilobytes total disk space.
New File System size is 1048576

En el ejemplo, los parámetros de entrada significan lo siguiente:

-v jfs2 Especifica un tipo de sistema de archivos jfs2.
-g rootvg Crea el sistema de archivos rootvg
-m /opt/pluto_bak Especifica el punto de montaje real.
-A yes Especifica que el sistema de archivos es montado automáticamente en cuando se vuelve a cargar.
-p rw Especifica permisos de lectura y escritura
-a agblksize=4096 Especifica el tamaño del bloque en bytes
-a size=1G Especifica el tamaño del sistema de archivos a ser creado, en este ejemplo es 1GB.

A continuación, monte el sistema de archivos /opt/pluto_bak:

# mount /opt/pluto_bak

Después de crear un sistema de archivos, no olvide aplicar la propiedad y los permisos correctos en el punto de montaje del sistema de archivos, si se requiere.

Ahora, usando el comando cp, asegurándose de que copiamos los permisos/modificaciones y cualquier enlace simbólico, usamos los distintivos Rph.

El siguiente comando cp copia todos los archivos y enlaces simbólicos (si los hay) de /opt/pluto a /opt/pluto_bak:

# cd /opt/pluto
# pwd
/opt/pluto
# cp -Rph * /opt/pluto_bak

Asegúrese de probar que la copia fue realizada correctamente listando el número de archivos y ejecutando du del sistema de archivos original y copia. Para /opt/pluto, tenemos:

# pwd
/opt/pluto
# du -ms .
988.46  .
# ls |wc
      17      17     146

Para /opt/pluto_bak, tenemos:

# cd ../pluto_bak
# ls |wc
      17      17     146
# du -ms .
988.46  .

Todas las salidas previas coinciden con el sistema de archivos original y copia, así que todo salió bien (la copia se ha completado con éxito).

Ahora haremos la misma operación de nuevo, pero esta vez usando la utilidad tar.

Usar tar es generalmente más rápido cuando se trabaja con muchos archivos más pequeños. Si sus archivos son mayores a 2GB, entonces asegúrese de usar la utilidad tar GNU.

# cd /opt/pluto
# pwd
/opt/pluto
# tar cpf - . | (cd /opt/pluto_bak; tar xpf - )

En la salida previa, tar crea los archivos con las modificaciones de tiempos/permisos del directorio actual; tar archiva esto a una salida estándar. La salida es entonces conducida hacia una sub-shell, después cd a /opt/pluto_bak y después untar (extraer) de la salida estándar en el sistema de archivos /opt/pluto_bak.

Como antes, asegúrese de verificar el sistema de archivos original y copia en la coincidencia del tamaño total y el número de archivos.

Si desea ver los archivos siendo archivados y extraídos, añada la opción verbosa (v):

# cd /opt/pluto
# tar cvpf - . | (cd /opt/pluto_bak; tar xvpf - )
a .
a ./lost+found
a ./myfile.dat 0 blocks.
a ./pop 1 blocks.
a ./test100M.bin 195313 blocks.
x .
x ./lost+found
x ./myfile.dat, 0 bytes, 0 media blocks.
x ./pop, 139 bytes, 1 media blocks.
x ./test100M.bin, 100000000 bytes, 195313 media blocks.
a ./myfile1 195313 blocks.
x ./myfile1, 100000000 bytes, 195313 media blocks.
a ./mprep 195313 blocks.
x ./mprep, 100000000 bytes, 195313 media blocks.
a ./chklp 195313 blocks.
x ./chklp, 100000000 bytes, 195313 media blocks.
a ./poplt 195313 blocks.
x ./poplt, 100000000 bytes, 195313 media blocks.
…..
…..

Usando tar para copiar datos en un sistema de archivos remoto

También puede usar tar para copiar datos a través de la red, aunque scp hará el trabajo. Generalmente prefiero usar tar para copias de sistema de archivos. Para tar en toda la red, use ssh como el método de transporte. Podría usar rsh, pero recomiendo no hacerlo por las fallas de seguridad que abre.

Asuma que deseamos copiar datos de /opt/pluto en el host local al host remoto de sistema de archivos nordkapp /opt/pluto. Podría usar:

# cd /opt/pluto
# tar -cpf - . | ssh nordkapp (cd /opt/pluto; tar -xpf -)

Como se puede ver en este ejemplo, no hay mucha diferencia en el comando tar entre copiar/restaurar localmente y copiar/restaurar remotamente. Lo anterior asume que las claves ssh han sido intercambiadas para permitir conexión/inicio de sesión sin contraseña.


Copiando un volumen lógico dentro de un grupo de volumen

Usar cplv es más lento que usar cp o tar cuando se trabaja con sistemas de archivos más pequeños. Otra opción a considerar es que cplv copia todo el lv a través, donde tar y cp sólo necesitan copiar estos archivos a través. Como norma general, yo usaría cplv si el sistema de archivos es mayor de 10GB.

En el siguiente ejemplo, vamos a copiar el volumen lógico que reside en /opt/pluto, que es llamado fslv00, en el volumen lógico copiado de sistema de archivos, fslv01. El comando cplv sobrescribe el contenido actual de fslv01, que es lo que queremos. Note en este ejemplo que el sistema de archivos /opt/pluto_bak ha sido creado como se demostró anteriormente; no hay datos en ese sistema de archivos en este momento. Esto puede verse en la salida del comando df:

# df -g
…..
/dev/fslv00   1.00      0.03   97%       22     1% /opt/pluto
/dev/fslv01   1.00      1.00    1%        4     1% /opt/pluto_bak

Lo primero que hay que hacer es desmontar ambos sistemas de archivos. A diferencia de tar y cp, cplv no puede ser llevado a cabo con los sistemas de archivos online:

# umount /opt/pluto
# umount /opt/pluto_bak

Si el sistema de archivos informa que no puede desmontar, porque está ocupado, asegúrese de que la aplicación está cerrada. Después determine qué procesos están evitando que el sistema de archivos se desmonte; use el fusor:

# fuser -u <filesystem>

Por ejemplo:

     # fuser -u /opt/pluto

Si decide que desea matar todos los procesos en ese sistema de archivos, use:

# fuser -k <filesystem>

A continuación, use el comando cplv. En esta instancia, vamos a copiar el volumen lógico fslv00, que sobrescribe el volumen lógico de destino existente (fslv01). El formato básico para esta demostración es:

cplv -e < dest lv>  -f  <source lv>

Donde:

-eCopia el contenido del volumen lógico en un volumen lógico existente
>dest lvEspecifica el volumen lógico de destino, en este ejemplo sería fslv01
source lv Especifica el volumen lógico de origen, en este ejemplo sería fslv00

Ya que estamos sobrescribiendo otro volumen lógico, asegúrese de que el volumen lógico de destino tiene el tipo de volumen lógico establecido como copy en lugar de jfs2 (en los atributos de volumen lógico). Si no es así, el comando falla y se le advierte que necesita cambiarlo. Para verificar el tipo, ejecute el siguiente comando lslv contra el destino lv:

# lslv fslv01 |grep TYPE
TYPE:          jfs2                 WRITE VERIFY:   off

EN la salida anterior, vemos que el volumen lógico de destino está establecido como jfs2. Ahora establézcalo como copy y ejecute el comando lslv para asegurarse de que está establecido:

# chlv -t copy fslv01
# lslv fslv01 |grep TYPE
TYPE:          copy                 WRITE VERIFY:   off

Ahora que está establecido como copy, podemos copiar el volumen lógico:

 # cplv -e fslv01 -f fslv00
cplv: Logical volume fslv00 successfully copied to fslv01 .

En esta salida, vemos que la copia fue exitosa, una vez que el comando cplv ha completado el tipo de volumen lógico que ha sido restablecido como: jfs2. Verifiquemos eso:

 # lslv fslv01 |grep TYPE
TYPE:            jfs2                WRITE VERIFY:   off

Todo está bien. Ahora, monte los sistemas de archivos:

# mount /opt/pluto
# mount /opt/pluto_bak
# df -g
….
/dev/fslv00    1.00      0.03   97%       22     1% /opt/pluto
/dev/fslv01    1.00      0.03   97%       22     1% /opt/pluto_bak

El sistema de archivos /opt/pluto ha sido copiado a /opt/pluto_bak usando el comando cplv. Asegúrese de comparar el tamaño y el conteo de archivos en el sistema de archivos copiado, como antes.

Si durante una actualización de aplicación algo sale mal, la aplicación no es utilizable y no tendrá otra opción más que restaurarla. Sin embargo, como en esta demostración, hemos hecho una copia de el sistema de archivos, así que todo lo que necesitamos hacer es intercambiar el sistema de archivos de aplicación que está mal por el que está bien. Intercambiar los sistemas de archivos es más rápido que restaurarlos desde la cinta, y usted también tiene una copia del sistema de archivos actualizado que falló para diagnósticos futuros.

En el siguiente ejemplo, asuma que deseamos intercambiar (con esto quiero decir cambiar el punto de montaje) de /opt/pluto_bak a /opt/pluto. Primero, necesitamos cambiar el punto de montaje de /opt/pluto a /opt/pluto_err. Esto se hace para que no haya conflictos de nombre cuando cambiemos /opt/pluto_bak a /opt/pluto. Cambiar el punto de montaje de un sistema de archivos se hace usando el comando chfs. Asegúrese de tener el sistema de archivos desmontado primero. El formato básico es:

chfs -m <new mount point> <original mount point>

Para confirmar, cambie el punto de montaje de /opt/pluto a /opt/pluto_err y cambie el punto de montaje de /opt/pluto_bak a /opt/pluto:

#  chfs -m /opt/pluto_err /opt/pluto

Ahora que hemos cambiado el punto de montaje de /opt/pluto a /opt/pluto_err, podemos cambiar /opt/pluto_bak a /opt/pluto:

# chfs -m /opt/pluto /opt/pluto_bak

A continuación, monte los sistemas de archivos:

# mount /opt/pluto_err
# mount /opt/pluto

La aplicación es ahora utilizable. La aplicación errónea ahora reside en /opt/pluto_err, que también ha sido montado. Esto permite más investigación, ya que ambos sistemas de archivos de aplicación están ahora montados, y ahora se puede llevar a cabo una comparación.


Copiando un volumen lógico a un grupo de volumen distinto

Copiar datos de un sistema de archivos a un grupo de volumen distinto puede realizarse usando tar, cp o cplv. En esta sección esto usando cplv. El procedimiento cplv es similar a las demostraciones previas. La única diferencia es que en lugar de que el sistema de archivos objetivo resida en el mismo grupo de volumen, será creado en un grupo de volumen distinto. Cuando se copia a un grupo de volumen distinto los atributos del dispositivo de volumen lógico (y quizá el dispositivo de registro) en /etc/filesystems deben ser cambiados, de forma que AIX sepa dónde buscar el sistema de archivos cuando se haga una solicitud de montaje.

Veamos cómo copiar un volumen lógico en un grupo de volumen distinto. Los pasos involucrados son:

  • Desmontar el sistema de archivos /opt/pluto.
  • Copiar el volumen lógico en el que reside /opt/pluto (fslv00). Con el comando copy, analizarlo en el nuevo volumen lógico, pluto_lv.
  • Si este es un nuevo grupo de volumen, cree uno jfs2log nuevo y dele formato. De otra forma, use el jfs2log existente que reside en ese grupo de volumen.
  • Edite /etc/filesystems para apuntar los dispositivos dev y log de /opt/pluto hacia los dispositivos correctos que ahora residen en ese grupo de volumen.
  • Monte el sistema de archivos /opt/pluto en el recientemente copiado volumen lógico, pluto_lv.
  • Verifique que el recientemente montado sistema de archivos esté bien.
  • Desmonte el sistema de archivos fsck y vuelva a montarlo.

Usando nuestro sistema de archivos /opt/pluto, asuma que deseamos copiar el volumen lógico fslv00 de rootvg en un grupo de volumen distinto, apps_vg. Y el volumen lógico debe ser renombrado como pluto_lv.

El formato básico del comando cplv para esta demostración es:

cplv -v <dest vg> -y <new lv name> source _lv

Donde:

-v <dest vg>es el grupo de volumen de destino, en este ejemplo es apps-vg
-y <new lv name> es el nombre de volumen lógico de destino, en este ejemplo es pluto_lv

Por lo tanto, la primera tarea es desmontar el sistema de archivos que deseamos copiar, de forma que podamos acceder al volumen lógico.

# umount /opt/pluto

Usando el comando lsvg, vemos que el sistema de archivos está cerrado:

# lsvg -l rootvg
…
fslv00              jfs2       64      64      1    closed/syncd  /opt/pluto

Ahora haga la copia:

#  cplv -v apps_vg -y pluto_lv fslv00
cplv: Logical volume fslv00 successfully copied to pluto_lv .

Ahora que está copiado, verifique con el comando lsvg:

 # lsvg -l apps_vg
apps_vg:
LV NAME     TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
pluto_lv    jfs2       128     128     1    closed/syncd  N/A

En la salida previa, vemos que el volumen lógico fslv00 ha sido copiado al grupo de volumen apps_vg y el volumen lógico es renombrado como pluto_lv. Sin embargo, también note que no hay entrada jfs2log de JFS (sistema de archivos del diario). Esto ocurre si está copiando volúmenes lógicos en un grupo de volumen vacío.

Si ya hay un jfs2log en el grupo de volumen, entonces su sistema de archivos copiado puede usar ese, no hay necesidad de crear un nuevo jfs2log.

Para crear el jfs2log use el comando mklv. El formato básico del comando mklv para esta demostración es:

mklv -t <type> -y <new lv_name> vg_name <number of LPs>

Donde:

-t <type>Especifica el tipo de volumen lógico. En este caso, es jfs2log.
-y <new lv name>Especifica el nombre de volumen lógico de destino. En este ejemplo, es jfs2log_lv.
vg_name :Indica el nombre de grupo de volumen donde va a residir el jfs2log. En este ejemplo, es apps_vg.
Number of LPsEl número de particiones lógicas; en este caso, una partición es necesaria.

Por lo tanto, para crear el jfs2log, que será llamado jfs2log_lv para el grupo de volumen apps_vg, use:

# mklv -t jfs2log -y jfslog_lv apps_vg 1
jfslog_lv

Puede omitir -y < new lv_name> y dejar que AIX lo nombre por usted (de manera predeterminada el primero es llamado loglv00).

Para verificar que ha sido creado:

# lsvg -l apps_vg
apps_vg:
LV NAME     TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
pluto_lv    jfs2       128     128     1    closed/syncd  N/A
jfslog_lv   jfs2log    1       1       1    closed/syncd  N/A

La siguiente tarea es inicializar y dar formato al volumen lógico jfs2log_lv para que pueda ser usado como un registro jfs2. Esto se consigue usando el comando logform. Cuando se solicita destruir el contenido, seleccione Yes. Realmente no está destruyendo nada, sino que está dando formato a un volumen lógico recientemente creado.

# logform /dev/jfslog_lv
logform: destroy /dev/rjfslog_lv (y)?y
#

Ahora estamos casi listos para montar el /opt/pluto; sin embargo, primero debemos permitir que AIX conozca el nuevo dispositivo y el jfs2log asociado a él. Si observamos la entrada de sistema de archivos para /opt/pluto, del archivo /etc/filesystems, tenemos:

# grep -w -p "/opt/pluto" /etc/filesystems
/opt/pluto:
        dev             = /dev/fslv00
        vfs             = jfs2
        log             = /dev/hd8
        mount           = true
        options         = rw
        account         = false

Podemos ver que necesitamos cambiar los siguientes atributos:

dev
log

Estos atributos reflejan el registro y el dispositivo cuando el volumen lógico residió en rootvg. Esto necesita cambiarse, ya que el volumen lógico ahora reside en el grupo de volumen apps_vg con distintos valores de log y dev. Para reflejar dónde residen el log y el volumen lógico ahora, cambie lo siguiente:

dev  = /dev/fslv00

a

dev = /dev/pluto_lv

Si ya hay un jfs2log en el grupo de volumen donde copió su volumen lógico, asegúrese de que usa ese dispositivo para el atributo jfs2log al hacer sus cambios en /etc/filesystems.

Cambie:

log   = /dev/hd8

a

log   = /dev/jfslog_lv

Ahora edite /etc/filesystems y cambie esos atributos como en el ejemplo previo. Una vez que esto esté hecho, verifique que los cambios de atributo han sido realizados.

# grep -w -p "/opt/pluto" /etc/filesystems
/opt/pluto:
        dev             = /dev/pluto_lv
        vfs             = jfs2
        log             = /dev/jfslog_lv
        mount           = true
        options         = rw
        account         = false

Ahora sólo resta montar /opt/pluto que ahora reside en el grupo de volumen apps_vg. El volumen lógico ahora está completo.

# mount /opt/pluto

# lsvg -l apps_vg
apps_vg:
LV NAME    TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
pluto_lv   jfs2       128     128     1    open/syncd    /opt/pluto
jfslog_lv  jfs2log    1       1       1    open/syncd    N/A

Aún tenemos el volumen lógico original residiendo en rootvg, sin un punto de montaje asociado a él. Una vez que /opt/pluto ha sido verificado, este puede ser eliminado. Como parte del proceso de verificación, es un buen hábito y una buena práctica ejecutar fsck en el sistema de archivos recientemente copiado (asegúrese de desmontarlo primero).

# umount /opt/pluto
# fsck -y /dev/pluto_lv
The current volume is: /dev/pluto_lv
Primary superblock is valid.
J2_LOGREDO:log redo processing for /dev/pluto_lv
Primary superblock is valid.
*** Phase 1 - Initial inode scan
*** Phase 2 - Process remaining directories
*** Phase 3 - Process remaining files
*** Phase 4 - Check and repair inode allocation map
*** Phase 5 - Check and repair block allocation map
File system is clean

# mount /opt/pluto

A continuación, asumiendo que todo se ha verificado correctamente, elimine el volumen lógico original de rootvg. Asegúrese de eliminar el volumen lógico original antes de volver a cargar (o exportvg), ya que ODM seguirá teniendo el volumen lógico original y los atributos de sistema de archivos:

# lsvg -l rootvg
…..
fslv00              jfs2       64      64      1    closed/syncd  N/A

# rmlv fslv00
Warning, all data contained on logical volume fslv00 will be destroyed.
rmlv: Do you wish to continue? y(es) n(o)? y
rmlv: Logical volume fslv00 is removed.

Conclusión

Mover o copiar datos entre sistemas de archivos es una tarea común para administradores de sistema, ya sea dentro del mismo grupo de volumen o a través de las redes. En este artículo, he demostrado distintas formas en que estas tareas pueden ser llevadas a cabo. Existen muchas formas de copiar datos; yo sólo he destacado un par de ellas con ejemplos.


Recursos

Recursos

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=746577
ArticleTitle=Migrando datos
publish-date=08012011