Copias de seguridad con dump y restore en Linux
Hoy os voy a hablar de dump y restore, herramientas clásicas de los sistemas UNIX, que pueden ser una excelente alternativa, para realizar copias de seguridad de ficheros y carpetas, en nuestros sistemas GNU Linux.
¿Cómo funciona dump?
La herramienta se encarga de examinar los archivos y sistemas de ficheros ext2 y ext3 y determina qué archivos deben copiarse. Estos se pueden almacenar en el propio disco del sistema o bien en otro medio externo, ya sea un recurso compartido en red o bien una unidad de cinta. Un volcado que es más grande que el medio de salida, se divide en varios volúmenes. Se puede indicar el tamaño de cada volumen también de manera manual mediante parámetros.
Sus características principales son:
- Se pueden hacer copias en varios volúmenes
- Se pueden salvar ficheros de cualquier tipo, incluyendo ficheros de dispositivos.
- Todos los permisos, propietarios y fechas de modificación se salvaguardan.
- Se pueden realizar copias de seguridad incrementales además de las completas.
- Permite guardan ficheros individuales, aunque no es lo habitual.
Su sintaxis es la siguiente:
1 | dump [opciones] [archivo-volcado] [Sistema de ficheros, archivo o directorio] |
Las opciones más comunes son:
- -f Realizamos copia de seguridad del fichero indicado.
- -u Actualiza el fichero /etc/dumpdates con el historial de las copias de seguridad realizadas.
- -v Amplia la información de salida (modo verbose)
- -e Excluye “inodos” cuando hace la copia de seguridad
- -z Se activa la compresión.
Además de esto es importante indicar el nivel de volcado.
- 0 Con el este nivel se indica que la copia es completa.
- 1 Aquí indicamos que la copia es incremental.
A modo de ejemplo vamos a utilizar una máquina virtual, que tengo con el sistema de monitorización Icinga, con un sistema operativo CentOS 7. Podemos ver el sistema de ficheros:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | [root@icinga backups]# df -h S.ficheros Tamaño Usados Disp Uso% Montado en /dev/mapper/cl_icinga-root 20G 4,3G 16G 22% / devtmpfs 1,9G 0 1,9G 0% /dev tmpfs 1,9G 0 1,9G 0% /dev/shm tmpfs 1,9G 8,4M 1,9G 1% /run tmpfs 1,9G 0 1,9G 0% /sys/fs/cgroup /dev/sda1 473M 274M 175M 62% /boot /dev/mapper/cl_icinga-home 4,7G 33M 4,7G 1% /home /dev/mapper/cl_icinga-opt 20G 1,1G 19G 6% /opt /dev/mapper/cl_icinga-usr_share 26G 557M 26G 3% /usr/share /dev/mapper/cl_icinga-var 1,9G 275M 1,6G 15% /var /dev/mapper/cl_icinga-var_log 4,7G 54M 4,6G 2% /var/log /dev/mapper/cl_icinga-var_cache 953M 152M 802M 16% /var/cache tmpfs 380M 0 380M 0% /run/user/0 |
Vemos una muestra del funcionamiento, sobre /boot
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | [root@icinga backups]# dump 0zf ./boot-20170710.dump /boot DUMP: Date of this level 0 dump: Mon Jul 10 13:14:56 2017 DUMP: Dumping /dev/sda1 (/boot) to ./boot-20170710.dump DUMP: Label: none DUMP: Writing 10 Kilobyte records DUMP: Compressing output at compression level 2 (zlib) DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 277991 blocks. DUMP: Volume 1 started with block 1 at: Mon Jul 10 13:14:57 2017 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing ./boot-20170710.dump DUMP: Volume 1 completed at: Mon Jul 10 13:15:10 2017 DUMP: Volume 1 took 0:00:13 DUMP: Volume 1 transfer rate: 19979 kB/s DUMP: Volume 1 279100kB uncompressed, 259731kB compressed, 1.075:1 DUMP: 279100 blocks (272.56MB) on 1 volume(s) DUMP: finished in 13 seconds, throughput 21469 kBytes/sec DUMP: Date of this level 0 dump: Mon Jul 10 13:14:56 2017 DUMP: Date this dump completed: Mon Jul 10 13:15:10 2017 DUMP: Average transfer rate: 19979 kB/s DUMP: Wrote 279100kB uncompressed, 259731kB compressed, 1.075:1 DUMP: DUMP IS DONE |
De esta manera ya tenemos el fichero de backup generado:
1 2 3 4 5 6 7 | [root@icinga backups]# pwd /home/backups [root@icinga backups]# ls -la total 259732 drwxr-xr-x 2 root root 31 jul 10 13:14 . drwxr-xr-x. 4 root root 34 jul 10 13:10 .. -rw-r--r-- 1 root root 265965186 jul 10 13:15 boot-20170710.dump |
La herramienta dump está ligada con la herramienta restore, que sirve para restaurar las copias de seguridad realizadas.
¿Cómo funciona restore?
Se encarga de restaurar los ficheros generados por dump.
Su sintaxis es la siguiente:
1 | restore [acciones] [opciones] [ficheros a recuperar] |
Las opciones más comunes son:
-
- -r Restaura la copia completa.
- -t Muestra los contenidos de la copia.
- -x Extrae sólo los ficheros indicados.
- -l Se accede al modo interactivo.
- -f Especifica el dispositivo o fichera de la copia.
- -a Nos pregunta de qué volumen extraer los ficheros.
Una muestra de su funcionamiento. Vamos a ver cómo acceder al fichero y listar todo su contenido:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 | [root@icinga backups]# restore -i -f boot-20170710.dump Dump tape is compressed. restore > ls .: .vmlinuz-3.10.0-514.10.2.el7.x86_64.hmac .vmlinuz-3.10.0-514.16.1.el7.x86_64.hmac .vmlinuz-3.10.0-514.21.1.el7.x86_64.hmac .vmlinuz-3.10.0-514.26.2.el7.x86_64.hmac .vmlinuz-3.10.0-514.el7.x86_64.hmac System.map-3.10.0-514.10.2.el7.x86_64 System.map-3.10.0-514.16.1.el7.x86_64 System.map-3.10.0-514.21.1.el7.x86_64 System.map-3.10.0-514.26.2.el7.x86_64 System.map-3.10.0-514.el7.x86_64 config-3.10.0-514.10.2.el7.x86_64 config-3.10.0-514.16.1.el7.x86_64 config-3.10.0-514.21.1.el7.x86_64 config-3.10.0-514.26.2.el7.x86_64 config-3.10.0-514.el7.x86_64 grub/ grub2/ initramfs-0-rescue-13cf7d0d35634f69afcfdf8ae8054aa7.img initramfs-3.10.0-514.10.2.el7.x86_64.img initramfs-3.10.0-514.10.2.el7.x86_64kdump.img initramfs-3.10.0-514.16.1.el7.x86_64.img initramfs-3.10.0-514.16.1.el7.x86_64kdump.img initramfs-3.10.0-514.21.1.el7.x86_64.img initramfs-3.10.0-514.21.1.el7.x86_64kdump.img initramfs-3.10.0-514.26.2.el7.x86_64.img initramfs-3.10.0-514.el7.x86_64.img initramfs-3.10.0-514.el7.x86_64kdump.img initrd-plymouth.img lost+found/ symvers-3.10.0-514.10.2.el7.x86_64.gz symvers-3.10.0-514.16.1.el7.x86_64.gz symvers-3.10.0-514.21.1.el7.x86_64.gz symvers-3.10.0-514.26.2.el7.x86_64.gz symvers-3.10.0-514.el7.x86_64.gz vmlinuz-0-rescue-13cf7d0d35634f69afcfdf8ae8054aa7 vmlinuz-3.10.0-514.10.2.el7.x86_64 vmlinuz-3.10.0-514.16.1.el7.x86_64 vmlinuz-3.10.0-514.21.1.el7.x86_64 vmlinuz-3.10.0-514.26.2.el7.x86_64 vmlinuz-3.10.0-514.el7.x86_64 |
A continuación, continuando con el ejemplo, seleccionamos un fichero y lo restauramos:
1 2 3 4 5 6 7 8 | restore> add vmlinuz-3.10.0-514.el7.x86_64 restore> extract You have not read any volumes yet. Unless you know which volume your file(s) are on you should start with the last volume and work towards the first. Specify next volume # (none if no more volumes): 1 set owner/mode for '.'? [yn] n restore> quit |
Hemos restaurado el fichero, conservando sus atributos:
1 2 3 4 | [root@icinga backups]# ls -ltr total 265000 -rwxr-xr-x. 1 root root 5392080 nov 22 2016 vmlinuz-3.10.0-514.el7.x86_64 -rw-r--r-- 1 root root 265965186 jul 10 13:15 boot-20170710.dump |
El artículo lo dejamos aquí. Si os ha parecido interesante o tenéis alguna duda, podéis dejar un comentario.
Para el artículo me he servido de los siguientes enlaces:
persoal.citius.usc.es | Su respectiva página en man | networking.ringofsaturn.com
Derechos de la imagen | Flickr
Hola. Desde luego que suena muy bien aunque soy bastante torpe y tendréqtendré que releerlo para enterarme bien yy no meter la pata. Un saludo
Hola Fernando,
Todo es ponerse y como dicen por aquí «ponerse la manta en la cabeza» y al lío 🙂
Gracias por pasarte y comentar. Saludos!!