Antes de empezar, nótese que en éste post me refiero a hosts físicos. Un título alternativo sería Backup completo de un host (sistema y datos). Ésto me surgió de la necesidad de tener un sistema de backup del mini PC multifunción (AP, firewall, LAMP, entorno de correo, almacenamiento en la nube...) que tengo en casa funcionando 24x7. Quería tener un backup no sólo de los datos (ciertamente lo más importante) sino de todo el sistema, porque restablecerlo en caso de desastre es una faena y actualmente no me sobra el tiempo. Hace poco, durante una tormenta, un rayo me dejó fritos el router de fibra + el interfaz de red del mini PC -en uso en ese momento- y no quiero ni imaginarme tener que empezar de cero.

Maneras de hacer ésto hay muchas y al final es cuestión de gustos. Lo primero que me viene a la cabeza es usar dd (actuar a nivel de bloque) para clonar un disco entero hacia otro, aunque si los discos origen y destino no son iguales, luego son necesarios reajustes de las particiones y sistemas de ficheros. Otra manera de actuar a nivel de bloque (ésta vez, usando sólo el espacio realmente ocupado e incluso evitando los reajustes de tamaños según el software) es usar algún sistema de clonado más precocinado, como Clonezilla, su hermano comercial Norton Ghost o afines. En lugar de ésto, he preferido actuar a nivel de ficheros usando rsync. Aunque hay otras recetas con cp o tar, yo elegí ésta por herramienta por la opción de incrementalidad y por conocerla mejor.

Ahondando un poco más en mis requisitos, a parte de querer disponer de un backup completo del host, quería poder ir actualizándolo periódicamente aprovechando ésta incrementalidad (acostumbra a ser más eficiente y a veces también más rápido). Ésto descarta en principio las soluciones que actúan a nivel de bloque. Querer hacer el backup con el host en producción también las descarta. Otras opciones como RAID1 o DRBD quedan descartadas por no querer invertir en más hardware y parecer desmesurado en un entorno personal. A parte, estoy concienciado por el tema del consumo eléctrico, climática y económicamente hablando (mi mini PC consume 13W en idle) :)

Aclarado ésto, mi solución pasa por usar un USB 2.0 del que ya dispongo, y periódicamente sincronizar al USB todo el sistema. Dejarlo conectado 24x7 con un cron evitaría olvidarse pero arriesgarse a que una incidencia en el equipo también le afecte (el USB siempre recibe alimentación aunque no esté montado). Mientras que la opción de conectarlo esporádicamente y lanzar la sincronización manualmente evita ésto pero podemos olvidarnos de hacerlo. La mejor opción queda en manos de cada uno.

Nota: Sé que hacer una sincronización de un sistema en funcionamiento puede causar inconsistencia en los datos, sobretodo cuando se trata de bases de datos, pero a parte de disponer de dumps de las mismas, en mi caso es bastante improbable porque reciben muy pocas escrituras y no es algo que me preocupe.

La orden de sincronización del sistema contra el USB sería tal que:

$ rsync -aH --delete / /media/usb0/

Y si llega el día en el que se produzca un desastre, éste sería el plan (los pasos a seguir) para migrar el sistema de ese USB a otro disco (nuevo) y poder usarlo como si fuera el original:

# Creamos (o reaprovechamos) una partición con un sistema de archivos limpio
$ fdisk -l /dev/sdb
Disposit.  Inicio Comienzo     Final  Sectores Tamaño Id Tipo
/dev/sdb1             2048 488397167 488395120 232,9G 83 Linux
$ mkfs.ext4 /dev/sdb1

# Montamos el disco, pinchamos el USB y sincronizamos los datos del USB al disco destino
$ mount /dev/sdb1 /mnt/
$ rsync -aH /media/usb0/ /mnt/

# Cuando ha acabado, podemos desmontar y extraer el USB y hacemos chroot al disco
$ mkdir /mnt/proc /mnt/dev /mnt/sys
$ mount -t proc none /mnt/proc
$ mount -o bind /dev /mnt/dev
$ mount -t sysfs sys /mnt/sys
$ chroot /mnt/ /bin/bash
chrooted$

# Adecuamos el fstab en el chroot
chrooted$ df -H 
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       246G   11G  223G   5% /
udev             11M     0   11M   0% /dev
chrooted$ blkid /dev/sdb1
/dev/sdb1: UUID="3225df51-7110-47d3-8df6-bf1e97ed46e7" TYPE="ext4" PARTUUID="000593c5-01"
chrooted$ vi /etc/fstab
UUID=3225df51-7110-47d3-8df6-bf1e97ed46e7 /               ext4    noatime,commit=300,errors=remount-ro 0       1
:wq

# Instalamos el GRUB en el chroot
chrooted$ grub-install /dev/sdb (ojo, cabe poner el disco correcto)
Installing for i386-pc platform.
Installation finished. No error reported.

chrooted$ update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.1.0-1-amd64
Found initrd image: /boot/initrd.img-4.1.0-1-amd64
Found linux image: /boot/vmlinuz-4.0.0-2-amd64
Found initrd image: /boot/initrd.img-4.0.0-2-amd64
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin
Found Debian GNU/Linux (stretch/sid) on /dev/sda1
done

# Finalmente salimos del chroot
chrooted$ sync
chrooted$ exit
$ umount /mnt/sys
$ umount /mnt/dev
$ umount /mnt/proc
$ umount /mnt/

Hecho ésto, ya deberíamos poder pinchar el disco en el nuevo host y hacerlo funcionar.