Mostrando entradas con la etiqueta Backup. Mostrar todas las entradas
Mostrando entradas con la etiqueta Backup. Mostrar todas las entradas

domingo, 7 de marzo de 2010

Backups off-site cifrados truecrypt

   En todos los proyectos hay distintas etapas. Primero te das cuenta de que la forma de realizar los backups es poco óptima y segura y decides que sería mejor tener un raid 1 para protegerte de los fallos en disco. Un tiempo después empiezas a pensar que eso está muy bien, pero qué ocurre si te roban el ordenador (con sus 2 discos del raid), se incendia, inunda o viene un tornado y te quedas sin casa. Pues que has perdido todos tus preciados datos. En ese momento piensas en un backup off-site, es decir, fuera de tu casa. Hay muchos servicios online, pero cuando tienes cientos de gigas de información que almacenar, pueden suponer muchos euros al mes.
Al final, una solución puede ser hacer el backup a un disco externo y llevar ese disco a otro sitio: la oficina, la casa de tus padres,... y cada cierto tiempo traerlo a casa, sincronizar los datos pendientes y volverlo a llevar. Pero, ¿qué ocurre si ese disco externo se pierde o roban en casa de tus padres?, que todo el mundo vería tu información. La solución para esto, el cifrado.

   Así es cómo lo voy a hacer. Tengo un disco duro de 120 GB que usaba antes de ampliar el raid y que ahora tengo en una caja externa usb. Para el cifrado, utilizo Truecrypt, del que ya he hablado varias veces y que me parece una solución estupenda.
  • Creamos el dispositivo cifrado. En lugar de crear un archivo .tc voy a cifrar toda la partición. Nos pedirá que seleccionemos los algoritmos, que introduzcamos una clave y que "aporreemos" el teclado para generar las claves con cierta aleatoriedad. No elegimos sistema de archivos puesto que sólo podemos escoger FAT y nosotros formatearemos posteriormente a ext3. Este proceso puede durar mucho tiempo en función del tamaño del disco, en mi caso fueron unas dos horas.
    shian:~# truecrypt -c /dev/sda1
  • Una vez finalizado el proceso, montamos el volumen cifrado indicando que no tiene filesystem.
    shian:~# truecrypt --filesystem=none /dev/sda1 /mnt/ext_backup
  • Vemos dónde se ha mapeado el dispositivo y lo formateamos. Ojo no hay que elegir /dev/sda1 puesto que sino sobreescribiríamos el volumen cifrado y tendríamos que empezar de nuevo.
    shian:~# truecrypt -l   
    1: /dev/sda1 /dev/mapper/truecrypt1

    shian:~# mkfs.ext3 /dev/mapper/truecrypt1
  • Desmontamos el volumen y lo montamos en su ubicación definitiva con el sistema de archivos ya creado. Ahora ya podríamos empezar a copiar todos nuestros datos en él.
    shian:~# truecrypt -d /dev/sda1

    shian:~# trucrypt /dev/sda1 /mnt/ext_backup

    shian:~# df -h
    S.ficheros Tamaño Usado Disp Uso% Montado en
    /dev/mapper/truecrypt1 113G 17G 91G 16% /mnt/ext_backup
  • Para la sincronización he hecho un script muy sencillo con rsync que copia los datos de la partición del raid donde los deja el proceso de backup al volumen cifrado. Sólo muestro dos directorios, pero el comando es el mismo para todos.
    #!/bin/bash
    echo "Asegurate de que esté montado el volumen cifrado!!!!"
    echo "CTRL+C para cancelar"
    read

    DATA_HOME=/mnt/raid/datos/doraemon/current
    BACKUP_DST=/mnt/ext_backup
    LOG_FILE=/root/log_externalBackup/$(date +%Y%m%d_%H%M)_externalBackup.log
    FINAL_LOG_DST=/mnt/ext_backup/logs

    rsync -avpz --stats "$DATA_HOME/media/sda2/Fotos" $BACKUP_DST > $LOG_FILE
    rsync -avpz --stats "$DATA_HOME/media/sda2/Musica" $BACKUP_DST >> $LOG_FILE

    cp $LOG_FILE $FILE_LOG_DST/
  •    Y listo, con esto estaría todo terminado. Ya sólo hay que lanzar el script y esperar a la sincronización. La primera vez tardará varias horas en función del volumen de datos, pero posteriormente la copia no debería tardar demasiado.

       Tal vez esta solución no sea la más limpia y elegante, puesto que los datos no están al día, hay que acordarse de traer y llevar el disco externo (con un par de notas en Google Calendar se soluciona), pero sin duda es más barata y tienes más control de tus datos :-P

    domingo, 20 de mayo de 2007

    Backups con Rsync

       Después de mi entrada anterior sobre el sistema de backup que voy a utilizar, quiero ampliar un poco la información diciendo que después de haber tenido un rato para terminarlo de configurar completamente he lanzado el backup completo de los 21 GB de datos. El resultado con rsync ha sido muchísimo mejor de lo que me esperaba a priori ya que ha tardado apenas 40 minutos en realizar la copia frente a las 3 horas que tardó BackupPC. Estoy encantado con haber elegido finalmente rsync y aunque finalmente no tenga todos los añadidos de BackupPC creo que ha sido la mejor elección.
       Muchas veces, lo más simple es lo mejor y en este caso, un pequeño script me ha solucionado todos los problemas.

    lunes, 14 de mayo de 2007

    Rsync vs BackupPc vs Link-Backup

       Llevo las últimas semanas buscando y probando distintos sistemas de copias de seguridad para poder tener los backups centralizados en casa en una única máquina, hacerlos de una manera eficiente, fiable y organizada. Los requisitos que debe cumplir el sistema son los siguientes:
  • Debe funcionar bajo linux: Voy a reutilizar mi antiguo Duron instalándole la nueva Debian Etch y quiero montar un raid 1 para tener fiabilidad en el backup.
  • Se deben poder hacer backups de máquinas windows y linux: Tengo que hacer backups de mi sobremesa con Ubuntu y del portatil de mi mujer con windows XP.
  • Debe permitir backups totales, parciales e incluso un histórico o versionado de archivos: Realmente lo único imprescindible es hacer un backup completo la primera vez e irlo ampliando con backups incrementales posteriores. Si además puedo tener un versionado de todos los archivos o almacenarlos en directorios distintos según el día, pues mejor que mejor.
  • No debe requerir tener el servidor encendido 24x7: No quiero un sistema de backup que deba tener encendido todo el día puesto que la idea es hacer un backup completo la primera vez y luego, según sea el trabajo diario encenderlo y hacer incrementales de vez en cuando.
  • Posibilidad de utilizar una interfaz gráfica (GUI): Más que para su utilización y/o configuración, para ver los archivos que se han almacenado de una manera fácil y cómoda.

  •    Así, con estas premisas me puse a buscar por internet y a leer foros y me quedé con tres herramientas para hacer pruebas y decidir cual era la mejor para mi: Rsync, BackupPC y Link-Backup.

    Rsync: Es un clásico en sistemas Unix/Linux. Entre las muchas opciones que permite sirve para realizar una copia de toda la información y posteriormente actualizar sólo los fragmentos que se modifican de los archivos. Cuando digo los fragmentos que se modifican de los archivos me refiero a que posteriormente, si de un archivo de 300 MB sólo modificamos una parte, sólo esa parte será enviada en la siguiente copia.
       En aspectos negativos decir que no tiene GUI de consulta de archivos.

    BackupPC: Me ha sorprendido mucho esta herramienta y además según he podido leer hay mucha gente que la utiliza con muy buenos resultados. De todos mis requisitos el único que no cumple es el de no poder apagar el servidor puesto que una vez al día ejecuta tareas de reorganización de índices y además el servidor decide cuando quiere hacer la copia de las máquinas (aunque es cierto que se pueden ejecutar backups bajo demanda). Tiene GUI para su utilización (que no configuración), versiona los archivos, permite backups completos y parciales y permite guardar la información de máquinas windows y linux. La recuperación de los archivos también está muy bien puesto que permite restaurarlos en su localización inicial, en otra máquina e incluso crear un zip con los archivos que queramos.
       Para funcionar utiliza rsync y crea hard links para reducir la utilización de espacio en el servidor. Así, la primera vez que hacemos un backup transfiere el archivo completo pero en posteriores copias, si detecta que el archivo es el mismo lo único que hace es crear un hard link, por lo que no consume más espacio en disco, pero sí inodos. Esto último, en función del sistema de archivos que utilicemos y del número de máquinas a gestionar puede traernos problemas.

    Link-Backup: Es una utilidad muy parecida a BackupPC aunque no tan "vistosa". Se trata de un script escrito en python y que también utiliza rsync para realizar la transferencia de los ficheros. Permite backups completos e incrementales y también utiliza hard links para reducir el espacio ocupado en disco. No tiene interfaz gráfica aunque en la web del autor hay disponible un pequeño cgi que sirve de interfaz gráfica para poder navegar por los distintos backups.

       Como tanto BackupPc como Link-Backup se basan en rsync y además aportan funcionalidad adicional, me centré directamente en estas dos herramientas.

       Comencé por BackupPC. Lo descargué, lo instalé y para la configuración, que fue muy sencilla, seguí este tutorial. Posteriormente cambié la configuración para utilizar rsyncd (el demonio rsync) en lugar de las transferencias cifradas por ssh. Después de un par de pequeñas pruebas transfiriendo unos cuantos archivos configuré todos los directorios a guardar y lancé el backup. En total fueron 21 GB y la copia tardó poco más de 3 horas. Durante este tiempo tuve a la vista el monitor de red de la máquina origen para comprobar la utilización de la red y he de decir que no se aprovechaba todo el ancho de banda ni mucho menos y apenas se llegó a utilizar el 40-50%. Una vez terminado el backup completo lancé el backup incremental para comprobar que se chequeaban todos los archivos y al no tener que transferir ninguno la copia se haría en pocos minutos. Al final, la copia incremental tardó 65 minutos! por lo que pensé que debía tener algo mal configurado. Estuve buscando algo más de información por internet y la conclusión a la que llegué es que BackupPC tiene que reconstruir toda la estructura de directorios, crear los hard links y actualizar su catálogo con la información de los ficheros. Además, debe calcular CRCs de los archivos para decidir si han cambiado y es necesario transferirlos de nuevo.

       El uso y configuración de Link-Backup es más sencillo todavía, sólo hay que tener python instalado para ejecutar el script. La sintaxis es similar a la del comando scp (usuario@maquina:/directorio) y no posee demasiadas opciones de configuración. Como no quería que me pasase lo mismo que con BackupPC, hice una prueba con un directorio de sólo 4 GB y los resultados fueron muchísimo mejores. Durante la transferencia la utilización de la red era de prácticamente el 90-100%, por lo que el tiempo del primer backup se redujo muchísimo. Después volví a ejecutar de nuevo el script y esta vez sí, en 5 segundos terminó indicando que no había nada que copiar.
       Luego instalé el cgi para tener la posibilidad de navegar por los backups y aunque la interfaz gráfica no se puede ni comparar con la de BackupPC, para el uso que yo quiero me sirvía.
       Cuando ya me iba a decidir por esta herramienta me dí cuenta que no era capaz de indicarle que realizara la copia de más de un directorio a la vez y crease un catálogo único, así que después de unas cuentas pruebas intentándolo, la descarté.

       Busqué alguna herramienta más por internet como Bacula pero requiere el servidor encendido y que el origen de los backups sea el servidor, por lo que también la descarté.

       Finalmente, me decidí por la opción de crearme yo mis propios scripts de backup utilizando rsync con la opción de crear hard links para ocupar menos espacio en el disco y crear un snapshot en cada ejecución.

       El script que realiza el backup se llama desde los clientes indicándole el nombre de la máquina origen por medio de ssh:
    ivan@doraemon:~$ ssh rsync@shian /home/rsync/scripts/backup.sh doraemon

       El contenido del script es el que muestro a continuación. Está algo hardcodeado porque no he sido capaz de pasarle como parámetro la lista de directorios al rsync. El problema está en que si es más de un directorio tiene que ir entre comilla simple ' y aunque "escape" el caracter con \ no funciona el rsync. Lo que hace el script es calcular el último snapshot y crear la nueva copia basándose en la anterior. Así, cada vez que lo ejecutamos se crea un nuevo directorio backup.X con la falsa ilusión de que es un backup completo por la magia de los hard links.
    #!/bin/bash

    # Comprobación de los parámetros
    if [ -z $1 ] ; then
    echo Uso `basename $0` hostname
    exit 1
    fi

    # Destino del backup
    DEST_DIR=/mnt/raid/datos

    HOST=$1
    FULL_DEST_DIR=$DEST_DIR/$HOST

    # Calculo del último snapshot del backup y del nuevo
    LAST_SNAPSHOT=`ls -ltr $FULL_DEST_DIR | tail -1 | awk {'print $8'} | cut -d . -f 2`
    ((NEW_SNAPSHOT=LAST_SNAPSHOT+1))

    # En función de la máquina de la que queramos hacer el backup, ejecutamos con unos u otros parámetros
    if [ $HOST == "doraemon" ] ; then
    rsync -av --delete --link-dest=$FULL_DEST_DIR/backup.$LAST_SNAPSHOT/ ivan@doraemon:'/Dir1 /Dir2 /Dir3' $FULL_DEST_DIR/backup.$NEW_SNAPSHOT > $FULL_DEST_DIR/files_$NEW_SNAPSHOT.txt
    mv $FULL_DEST_DIR/files_$NEW_SNAPSHOT.txt $FULL_DEST_DIR/backup.$NEW_SNAPSHOT/files.txt
    elif [ $HOST == "dorami" ] ; then
    rsync -av --delete --link-dest=$FULL_DEST_DIR/backup.$LAST_SNAPSHOT/ ana@dorami:'/MisDocs' $FULL_DEST_DIR/backup.$NEW_SNAPSHOT > $FULL_DEST_DIR/files_$NEW_SNAPSHOT.txt
    mv $FULL_DEST_DIR/files_$NEW_SNAPSHOT.txt $FULL_DEST_DIR/backup.$NEW_SNAPSHOT/files.txt
    else
    exit 2
    fi

       Lo único necesario es configurar el acceso por ssh sin password desde mi pc con linux (doraemon) y el portatil de mi mujer (dorami) al servidor de backup (shian) y desde éste a los clientes puesto que el backup parte de shian. Sé que es algo engorroso tener que configurar la conexión ssh sin password en ambos sentidos, pero prefiero hacerlo así porque quiero que el momento en el que se realice el backup se decida en el lado cliente.

       Instalé en el portatil de mi mujer Cygwin y lo configuré como sigue para conectarme por ssh sin tener que utilizar ninguna clave:
  • Primero, en windows, desde cygwin generamos el par de claves pública/privada:
    $ ssh-keygen -t dsa -b 1024
    Generating public/private dsa key pair.
    Enter file in which to save the key (/cygdrive/c/Documents and Settings/ana/.ssh/id_dsa): INTRO
    Enter passphrase (empty for no passphrase): INTRO
    Enter same passphrase again: INTRO
    Your identification has been saved in /cygdrive/c/Documents and Settings/ana/.ssh/id_dsa.
    Your public key has been saved in /cygdrive/c/Documents and Settings/ana/.ssh/id_dsa.pub.
    The key fingerprint is:
    7b:9a:c6:e9:ee:f1:2e:b0:00:fc:68:c6:58:2b:d6:a0 ana@dorami.casa
  • Copiamos la clave pública al servidor de backup:
    $ scp id_dsa.pub rsync@shian:/home/rsync/.ssh/id_dsa_ana.pub
    Password:
    id_dsa.pub 100% 605 0.6KB/s 00:00
  • Ahora nos conectamos al servidor de backup con el usuario rsync y añadimos la clave pública en el archivo de claves autorizadas para poder conectarnos por ssh sin necesidad de password:
    rsync@shian:~$ cat ~/.ssh/id_dsa_ana.pub >> ~/.ssh/authorized_keys
  • En este momento ya nos podemos conectar por ssh sin password desde la máquina windows (dorami) al servidor de backup (shian):
    $ hostname
    dorami

    $ ssh rsync@shian
    Last login: Fri 11 21:50:47 2007 from doraemon
    rsync@shian:~$
  • Para afinar un poco más la configuración y eliminar el agujero de seguridad de permitir sesiones por ssh con el usuario utilizado para el backup, editamos el archivo de claves autorizadas y añadimos al principio la limitación de sólo poder conectarnos desde esa máquina, no permitir redirección de puertos y no permitir sesiones interactivas, quedando así:
    rsync@shian:~$ cat .ssh/authorized_keys
    from="dorami.casa",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss AAAAB3Nza................y6SzRKqzW6V9PpwQ== ana@dorami.casa
  • De esta manera, si ahora intentamos conectarnos por ssh al servidor, obtenemos el siguiente error:
    $ ssh rsync@shian
    stdin: is not a tty

  •    Repetí los pasos desde mi máquina aunque obviamente sin la parte de capar el acceso por ssh ;-). Adicionalmente hay que hacer lo mismo para configurar las conexiones sin password pero desde el servidor hacia los clientes.

       Ahora, para finalizar, lo que hago es crear un script en cygwin para lanzar el backup y otro script .bat para crear un acceso directo en windows para que mi mujer pueda ejecutar sus backups sin ningún problema.
    # En cywin
    $ cat backupAna.sh
    #!/bin/sh
    ssh rsync@shian /home/rsync/scripts/backup.sh dorami


    # En windows
    @echo off
    REM EjecutaBackup.bat
    echo Ejecutando backup...
    C:\cygwin\bin\bash --login -i /usr/local/bin/backupAna.sh
    pause

       Y esto es todo, mi mujer puede lanzar su backup cuando quiera y yo desde mi máquina tengo un script similar.

       Como conclusiones finales me quedo con un cierto mal sabor de boca por no haber elegido BackupPc puesto que me parece la solución más completa aunque también es cierto que los tiempos de backup incrementales son bastante elevados. Aunque bastante menos elegante, la solución del script manual es mucho más eficiente y cómoda para mi.