Un poco de teoría sobre backup

Un backup es una copia instantánea de datos tomada en un instante, almacenada en un formato común soportado por diferentes herramientas de backup, y gestionada por algún periodo de utilidad, y mantenida de forma independiente a las otras copias. Para que podamos hablar de backup, los archivos copiados deben poder ser accedidos de manera independiente.

Los backup totales representan la copia de todos los datos que se desean proteger, y representan la base para los otros tipos de copia. Además de los backup totales (full backup) existen otros dos niveles de backup, que capturan los cambios relativos al backup total. Se trata del backup diferencial y el backup incremental. Los siguientes gráficos muestran de forma clara cada tipo de backup. El ejemplo se da en un entorno donde a partir de un backup total de 20TB, se produce una media de 1TB de cambio cada día, a lo largo de 10 días.

Hay que tener cuidado con las copias diferenciales, ya que su tamaño se puede disparar hasta ocupar más que la misma copia total. Su principal ventaja es el número de imágenes de backup requeridas para restaurar: hará falta el backup total y la última copia diferencial. De este modo, la probabilidad de deterioro, pérdida, etcétera, de las dos imágenes es muy baja.

Las copias incrementales tienen como ventaja que el espacio y el tiempo empleado es menor para los backup. Sin embargo, para restaurar las copias, son necesarias más imágenes que en el caso anterior, lo que afecta negativamente en el tiempo requerido para la restauración. Además hay otro problema: debido a que las copias incrementales capturan los cambios desde la última copia total, el conjunto total de backups puede contener múltiples copias de un cierto archivo, con lo que se pueden dar problemas al restaurar la versión equivocada del archivo.

Existe un concepto llamado periodo de retención de backup que indica el tiempo total que los backups deben estar disponibles. Pongamos como ejemplo un total de 20 TB de los que se hace una copia completa todas las semanas y diariamente se hace una copia incremental. Supongamos también que el periodo de retención es de 4 semanas.

En el momento en que más espacio ocuparemos con los backup es al final de la quinta semana: 20 TB x 6 + 1 TB x 6 x 5 = 100 TB + 30 TB = 150 TB.

Para contar con un periodo de retención de 4 semanas, necesitaremos guardar las copias durante 5 semanas, más el primer día de la sexta semana, ya que hasta que no esté hecha la copia total de la sexta semana, no podremos borrar los backups de la primera semana.

Plan de recuperación de desastres (DRP)

Un desastre es un evento o suceso impredecible cuyos efectos ocasionan la pérdida parcial o total de servicios esenciales para el funcionamiento de las actividades productivas de una organización. En un RDP se manejan habitualmente conceptos como el RPO o el RTO:

  • RTO (Recovery Time Objective) representa la máxima cantidad de tiempo que puede pasar desde el principio de una recuperación hasta que los datos han sido recuperados (y cuando hablamos de principio, nos referimos al tiempo que tardará el administrador de backups en recuperar los datos desde que éstos han sido identificados. Hay que tener en cuenta que RTO puede entenderse tambien como el tiempo que pasa desde que el usuario final pide la restauración de los datos, hasta que éstos han sido restaurados, pasando por la preparación del administrador del sistema para la restauración.
  • RPO (Recovery Point Objective) representa la cantidad de datos que se perderían desde el último "evento de protección" (backup, snapshots, log dumps o replicaciones). Para el administrador, esto se traduce en el tiempo que puede dejar pasar entre copia y copia. Para el usuario representa el número de transacciones que se perderían en la restauración más reciente. Para calcular el tiempo entre copia y copia, en base al RPO establecido por el usuario, el administrador calculará lo siguiente:

    tiempo entre copias(RPO) = número de transacciones a perder / número de transacciones por unidad de tiempo .

    Otro asunto a tener en cuenta es el tiempo de carga del medio (suponiendo que es preciso cargarlo, como en el caso de las cintas), de modo que es preciso restar dicho tiempo al periodo de backup para cumplir el RTO.

Si se produce un desastre en el límite del RPO, entonces habremos perdido la cantidad máxima de datos, y tardaremos una cantidad de tiempo RTO en volver a tener el servicio operativo:

Por ejemplo, supongamos que tenemos una aplicación que gestiona 2 TB de datos en total, donde se producen cambios por un total de 3GB diarios. El RTO es de 3 horas. Suponiendo que queremos perder un máximo de 1GB de cambios:

  • ¿Cuál debe ser el RPO (tiempo entre copias)?
  • ¿Cuánto pasará desde la última copia hasta que el sistema esté de nuevo operativo?
  • Si el tiempo de retención es de 2 semanas, y se va a hacer una copia total cada semana, y el resto serán copias incrementales, ¿Qué espacio necesitaremos como mínimo para almacenar las copias?

Actividad 1. Se desea proteger una base de datos de 240GB que se ejecuta en un servidor, con un tiempo de retención de una semana. Después de analizar la base de datos, hemos averiguado que se producen un máximo de 50 modificaciones al día, que en total suponen unos 2 GB de cambio. Deseamos tener un máximo de 1GB de pérdida de datos en caso de desastre. El RTO es de 2 horas. Se va a hacer una copia total cada semana y el resto serán copias incrementales. El espacio de que dispones para hacer las copias es de 1TB.

Averigua

  • ¿Cada cuanto tiempo hay que hacer una copia de seguridad (RPO)?
  • ¿Cuánto tiempo tardará el sistema en estar operativo en el peor de los casos desde la última copia de seguridad?
  • Calcula el espacio máximo ocupado al completar un ciclo completo de copias.

Entrega un documento de texto, llamado Act1-backuplinux.txt, donde justifiques tus respuestas.

Soluciones backup

Existen muchas soluciones de backup en linux. En el enlace http://www.muylinux.com/2009/01/15/21-herramientas-de-backup-para-linux podemos ver algunas de ellas. En este tema, nosotros nos vamos a centrar en soluciones sencillas y con solera. Si nuestro requerimientos son muy exigentes, con backup de muchos servidores, que requiera una arquitectura de copia más compleja, podemos decidirnos por Bacula o Zmanda.

Tar

Tar es una solución clásica, que permite hacer copias de seguridad totales, incrementales y diferenciales de una manera sencilla. Se puede combinar con scripts y crond para crear configuraciones más complejas.

Empaquetar archivos

tar -cvf archivo.tar /ruta/directorio
  • c - crear paquete tar
  • v - mostrar detalles del empaquetamiento
  • f - nombre del archivo

Comprimir archivos

Si necesitamos más velocidad en la compresión, podemos usar el formato gzip. Si lo que necesitamos es mayor nivel de compresión, podemos usar el formato bzip2

tar -zcvf archivo.tar.gz /ruta/directorio
  • z - compresión gzip
tar -jcvf archivo.tar.bz2 /ruta/directorio
  • j - compresión bzip2

Descompresión de un archivo

Para descomprimir un paquete sin comprimir (.tar)

tar -xvf archivo.tar
  • x - extraer archivos empaquetados

Para descomprimir un paquete tar.gz

tar -zxvf archivo.tar.gz

Para descomprimir un paquete tar.bz2

tar -jxvf archivo.tar.bz2

Copias diferenciales e incrementales

Para realizar copias diferenciales, utilizamos la opción --listed-incremental=archivo-snapshot, donde "archivo-snapshot" es un archivo especial mantenido por tar para determinar los archivos que nah sido añadidos, modificados o borrados. Por ejemplo:

tar --listed-incremental=archivo.snapshot -cvzf backup.tar.gz /directorio/a/copiar

La única diferencia con los comandos explicados previamente es la opción -listed-incremental. Tar tiene en cuenta dos posibles situaciones:

  • El archivo "archivo.snapshot" no existe aún
  • El archivo "archivo.snapshot" ya existe

El archivo "archivo.snapshot" no existe aún

Si el archivo "archivo.snapshot" no existe, entonces tar hace lo siguiente:

  1. realiza un backup total (nivel 0)
  2. crea el archivo "archivo.snapshot" con metadatos sobre los archivos copiados

El archivo "archivo.snapshot" ya existe

Si "archivo.snapshot" ya fue creado anteriormente, tar creará un archivo incremental, llamado "backup.tar.gz", que contiene únicamente los archivos cambiados según los metadatos almacenados en "archivo.snapshot". De este modo se creará una copia de nivel 1. Por ello, el nombre del archivo copiado debería ser asignado para poder diferenciarlo de la copia total:

tar --listed-incremental=archivo.snapshot -cvzf backup.1.tar.gz /directorio/a/copiar

Cómo elegir entre hacer copia diferencial o incremental

¡OJO! El archivo original "archivo.snapshot" será actualizado según los nuevos archivos copiados. Es decir, que la siguiente copia sería incremental. Por ello, si lo que queremos es hacer más copias de nivel 1 (diferenciales) debemos copiar el archivo "archivo.snapshot" para salvaguardarlo y utilizarlo en posteriores ocasiones:

cp archivo.snapshot archivo.snapshot.1 tar --listed-incremental=archivo.snapshot.1 -cvzf backup.1.tar.gz /directorio/a/copiar

De este modo, "archivo.snapshot" no sufrirá cambios, y podremos hacer más copias diferenciales en el futuro.

Simpre podemos volver a hacer una copia total, haciendo una de dos opciones:

  • Borrando el archivo "archivo.snapshot"
  • añadiendo la opción "--level=0" como en el ejemplo siguiente:
tar --listed-incremental=archivo.snapshot --level=0 -cvzf backup.tar.gz /directorio/a/copiar

Restauración de copias

Para extraer copias incrementales/diferenciales, simplemente debemos extraer los archivos comprimidos.

tar -xvf backup.tar.gz

Si existen varios niveles de copia, debemos extraer las copias en orden:

tar -xvf backup.tar.gz tar -xvf backup.1.tar.gz ...

El siguiente script permite realizar copias de seguridad con tar siguiendo un esquema de rotación: tarbackup.sh

Actividad 2. Deseas hacer una copia de seguridad total del directorio /mnt/datos utiliando tar, con vistas a hacer copias incrementales en el futuro.

  • Cómo sería el comando de copia total
  • Cómo serían los comandos de copia incremental posteriores
  • Cómo programarías las copias, para que se haga la copia total el lunes, y el resto de días se haga una copia total

Entrega un documento llamado act2-backuplinux.txt, donde expliques la solución al problema.

RSYNC

rsync es una herramienta que permite sincronizar archivos y directorios ubicados en sitios diferentes (ya sea en la misma máquina o en otra).

rsync se utiliza en muchas ocasiones como mecanismo de respaldo de datos.

Para instalar rsync:

yum install rsync

Transferencia entre directorios dentro del mismo equipo

Necesitamos dos directorios, uno de origen y otro de destino. Para remarcar el uso que le vamos a usar para respaldo de datos, vamos a llamar a estas carpetas /mnt/datos y /mnt/backup.

Supongamos que ya se han creado ciertos cambios en /mnt/datos y queremos respaldarlos a /mnt/backup:

rsync -av /mnt/datos /mnt/backup

La opción -a indica que la sincronización sea recursiva a lo largo de los directorios, y que se mantengan enlaces simbólicos, archivos especiales, permisos y propietarios y tiempos de modificación.

La opción -v hace referencia al detalle con que se muestran las acciones realizadas.

También podemos utilizar la opción -n si queremos poder ver los cambios que se llevarían a cabo, si que en realidad se hagan, para así poder ver el plan de acción de rsync. De este modo, el comando sería rsync -anv /mnt/datos /mnt/backup

Transferencia entre equipos remotos

Para la transferencia entre equipos remotos, es una buena idea utilizar ssh, ya que la comunicación se produce en un canal cifrado.

Ahora supongamos que la carpeta local se llama /mnt/datos y la carpeta remota se llama /mnt/backup en la máquina 192.168.0.5 y propiedad del usuario pedro. Entonces para realizar la transferencia entre origen y destino, haremos lo siguiente:

rsync -azP /mnt/datos pedro@192.168.0.5:/mnt/backup

La opción -z indica que los archivos deben ser comprimidos antes de ser enviados. Esta acelera la transferencia pero supone una mayor carga en los equipos origen y destino.

La opción -P ofrece dos cosas. Muestra una barra de progreso de la transferencia y permite reanudar transferencia interrumpidas anteriormente.

La inconveniencia de introducir la contraseña

El procedimiento de transferencia por ssh require la introducción de una contraseña. Esto puede ser contraproducente, si queremos automatizar las transferencia. La autenticación es posible hacerla mediante contraseña, aunque también la podemos hacer empleando certificados. En este caso, nos interesea la utenticación por certificado, que no requiere de la introducción de una contraseña. El proceso sería el siguiente:

Vamos a suponer que estamos en "Datos-srv" y queremos poder autenticarnos contra el servidor "SSH-srv" utilizando certificados en vez de contraseña. El primer paso es crear la clave pública y la privada en "Datos-srv", mediante el siguiente comando:

$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/usuario/.ssh/id_rsa): Enter passphrase (empty for no passphrase):

Si dejamos en blanco, no tendremos que introducir contraseña al iniciar sesión ssh.

Enter same passphrase again: Your identification has been saved in /home/usuario/.ssh/id_rsa. Your public key has been saved in /home/usuario/.ssh/id_rsa.pub. The key fingerprint is: 0e:73:29:66:8e:f8:2e:fb:96:49:e4:02:3a:1c:61:5d usuario@laptop-50

Si comprobamos en el directorio "/home/usuario/.ssh", veremos lo siguiente:

$ cd /home/usuario/.ssh $ ls id_rsa id_rsa.pub known_hosts

Ahora debemos copiar la clave pública de "Datos-srv" en "SSH-srv". Podemos hacer utilizando el mismo SSH:

$ scp /home/usuario/.ssh/id_rsa.pub usuario@SSH-srv:/home/usuario/.ssh/authorized_keys

Listo. Con esto, ya podemos iniciar una sesión desde "Datos-srv" en "SSH-srv" mediante clave pública, sin contraseña. Es decir, ya podemos introducir el comando rsync anterior sin necesidad de introducir una contraseña, por lo que ya podemos automatizarlo.

Actividad 3. Crea un directorio llamado /mnt/datos/ en tu servidor. Después crea 10 MB de datos en su interior en archivos de 1 MB, tal y como hemos hecho en veces anteriores con dd. A continuación realiza las siguientes tareas:

  • Genera un par de claves pública/privada para SSH. Después transfiere la clave pública al servidor de compañero para poder iniciar sesión sin necesidad de introducir la contraseña. Toma una captura llamada Act3.1-rsync.png, donde se pueda ver cómo generas el par de claves pública/privada, y cómo copias la clave pública en el servidor de tu compañero.
  • Realiza una sincronización de los archivos en /mnt/datos, al servidor de tu compañero. Toma una captura llamada Act3.2-rsync.png, donde se pueda ver la transferencia realizada.