En 1956 John Huston dirige Moby Dick, una adaptación de la novela homónima escrita por Herman Melville en 1851, con el mítico Gregory Peck en el papel del capitán Ahab.
Ahab, un desfigurado marino de semblante aterrador y mueca perdida, emprende una búsqueda obsesiva del gran cachalote blanco.
Durante la misma pierde una pierna lo que convierte su caza en una odisea de odio y venganza que sólo puede acabar con la muerte a arponazos del mítico animal.
«Thar she blows!» o «¡Por allí resopla!» es el grito del vigía que alerta a la tripulación del ballenero Pequod y coloca a Ahab en un estado de locura ante el posible avistamiento del gran monstruo marino.
Basada en la experiencia de Melville como marinero, la novela se inspira en hechos reales. Un barco ballenero, el Essex, fue atacado y hundido por un cachalote albino en 1820 y sus tripulantes vagaron hasta ser rescatados en la isla Henderson, en el Pacífico Sur.
El simbolismo del gran monstruo blanco que infringe daño y aterroriza a cualquiera que se cruza en su camino con intención de cazarlo se perpetúa hasta nuestros días.
Lejos de monstruosos animales marinos e historias míticas sobre su captura hoy en día en cualquier departamento tecnológico de cualquier empresa podréis oír historias que igualan o superan el terror que sentían Ahab y su tripulación cuando oían resoplar a su gran ballena blanca.
La ballena blanca de nuestros días se llama pérdida de datos y está sumergida y al acecho en cada uno de nuestros servidores, de nuestros equipos de trabajo y centros de datos.
Entre mis cometidos, como administrador de sistemas en Grupo Trevenque, está el cazar a la gran ballena blanca o al menos mantenerla lejos de nuestros dominios.
Para ello, os iré presentando un conjunto de herramientas de backup que harán de afilados arpones ante la temida pérdida de datos y os ayudarán a disfrutar la historia del ballenero y su capitán desde el relajado punto de vista de quien disfruta una obra maestra de la literatura o una genial película.
¿Preparados? Levemos anclas y comencemos la travesía hacia aguas más tranquilas.
Restic, sublimando el concepto del repositorio.
Restic es una herramienta de backup desarrollada por Alexander Neumaan que tiene como base de su diseño la siguiente filosofía:
- Facilidad de uso: Las copias de seguridad tienen que ser fáciles de hacer si no caeremos en la posibilidad de obviar su realización.
- Rapidez: Nadie hace copias si tardan demasiado, deben ser también rápidas de recuperar.
- Veracidad: Las copias han de ser confiables, la máxima de una copia de seguridad es que valga para algo cuando se restaure y sea fiel al contenido copiado.
- Segura: Si lo que copiamos no lo hacemos con seguridad probablemente estemos incrementando los problemas de nuestra información.
- Eficiencia: Un sistema de copias ha de ser eficiente para saber cuándo almacena la misma información varias veces y no desperdicie espacio innecesariamente.
- Gratuito: Restic es una herramienta de licenciada bajo la cláusula BSD 2-CLause License.
¿Y qué tiene que ver aquí el concepto repositorio? me preguntaréis.
Restic trata cada trabajo de copia como un repositorio, debemos inicializarlo y realizar un backup sobre él y esto nos permitirá operarlo mediante la utilidad de consola Restic para hacer de forma fácil, rápida, veraz, segura y eficiente nuestras copias de seguridad.
Como repositorio o destino final de nuestra copia podemos utilizar múltiples tipos, como por ejemplo: un directorio local, un servicio SFTP, una cuenta en Amazon S3 o Google Cloud. Estoy seguro que lo veremos mejor con un ejemplo:
Supongamos que ya tenemos Restic instalado en nuestro sistema:
# Inicializamos el repositorio en nuestra carpeta local ~/backup ➜ restic init --repo backup enter password for new repository: enter password again: created restic repository 55c7852eb8 at backup Please note that knowledge of your password is required to access the repository. Losing your password means that your data is irrecoverably lost.
Con esto ya hemos agregado como destino de nuestras copias el directorio ~/backup de nuestro home, ahora vamos a realizar una primera copia.
# ~/trabajo es nuestra carpeta a copiar, es donde reside nuestra valiosa información ➜ restic -r ~/backup --verbose backup ~/trabajo open repository enter password for repository: repository 55c7852e opened successfully, password is correct lock repository load index files start scan on start backup on scan finished in 4.679s: 127 files, 768.395 KiB Files: 127 new, 0 changed, 0 unmodified Dirs: 3 new, 0 changed, 0 unmodified Data Blobs: 114 new Tree Blobs: 4 new Added: 535.172 KiB processed 127 files, 768.395 KiB in 0:04 snapshot a8cd83ad saved
Como habéis visto hemos guardado el contenido de ~/trabajo en nuestro repositorio con la herramienta Restic y nuestra clave del repositorio, también nos ha dado una información extra al respecto del trabajo: tiempo de copia, ficheros, directorios y tamaño total. También tenemos un id a8cd83ad que nos permite saber en qué estado está nuestro repositorio.
Y si modificamos o agregamos algún fichero al directorio ~/trabajo, ¿volverá a hacer el mismo proceso? Veámoslo.
# Agregamos un fichero modificado.md al directorio ~/trabajo. ➜ restic -r ~/restic/backup --verbose backup ~/restic/trabajo open repository enter password for repository: repository 55c7852e opened successfully, password is correct lock repository load index files using parent snapshot a8cd83ad start scan on start backup on scan finished in 3.241s: 128 files, 768.395 KiB Files: 1 new, 0 changed, 127 unmodified Dirs: 0 new, 3 changed, 0 unmodified Data Blobs: 0 new Tree Blobs: 4 new Added: 1.475 KiB processed 128 files, 768.395 KiB in 0:03 snapshot ab68ea24 saved
Et voilá, hemos cambiado un fichero, ha copiado sólo un fichero, ¡magia!, como podéis ver hemos obtenido un id distinto del repositorio y podríamos verificar qué ha pasado entre los dos trabajos de copia de la siguiente forma:
➜ restic -r ~/restic/backup diff a8cd83ad ab68ea24 enter password for repository: repository 55c7852e opened successfully, password is correct comparing snapshot a8cd83ad to ab68ea24: + /home/fjfunes/trabajo/modificado.md Files: 1 new, 0 removed, 0 changed Dirs: 0 new, 0 removed Others: 0 new, 0 removed Data Blobs: 0 new, 0 removed Tree Blobs: 4 new, 4 removed Added: 2.150 KiB Removed: 1.855 KiB
Ahí está, en la segunda copia que hemos hecho se ha añadido el fichero «modificado.md» que hemos copiado en el directorio ~/trabajo/. ¿Y si lo borramos? ¿Qué podría pasar? ¿Resoplaría la Ballena Blanca?
Veamos que no:
# Borramos el fichero modificado.md y recuperamos una copia del fichero ➜ rm ~/trabajo/modificado.md ➜ restic -r ~/backup restore ab68ea24 --target ~/recuperado enter password for repository: repository 55c7852e opened successfully, password is correct restoring <Snapshot ab68ea24 of at 2018-06-01 22:47:37.2123459 +0200 DST by fjfunes@trevenque> to /home/fjfunes/recuperado # Buscamos el fichero ➜ recuperado cd trabajo/ ➜ trabajo ls modificado.md nextcloud13 rancher ➜ trabajo ls -larth total 0 drwxrwxrwx 1 fjfunes fjfunes 4,0K jun 1 22:36 .. drwxrwxrwx 1 fjfunes fjfunes 4,0K jun 1 22:37 rancher drwxrwxrwx 1 fjfunes fjfunes 4,0K jun 1 22:38 nextcloud13 -rw-rw-rw- 1 fjfunes fjfunes 0 jun 1 22:46 modificado.md drwxrwxrwx 1 fjfunes fjfunes 4,0K jun 1 22:46 . ➜ trabajo pwd /home/fjfunes/trabajo
Hemos recuperado nuestra copia en el directorio ~/recuperado y tenemos todo el repositorio disponible. Si quisiésemos ver que guarda nuestro repositorio podríamos hacer lo siguiente:
restic -r ~//backup snapshots enter password for repository: repository 55c7852e opened successfully, password is correct ID Date Host Tags Directory ---------------------------------------------------------------------- a8cd83ad 2018-06-01 22:40:20 fjfunes@trevenque /home/fjfunes/trabajo ab68ea24 2018-06-01 22:47:37 fjfunes@trevenque /home/fjfunes/trabajo ---------------------------------------------------------------------- 2 snapshots
Como podemos ver, tenemos dos snapshots del host local y el directorio que se ha copiado, la hora y su id. Podremos operar estos snapshots borrándolos, purgándolos o comprobando su integridad para cerciorarnos que no se ha producido ninguna alteración en la copia.
También podemos hacer que los snapshots se auto purgen y borren siguiendo patrones temporales. Por ejemplo, podemos necesitar que nuestra copia se mantenga durante un número de días específico. También podríamos querer que sólo se guardasen un número específico de snapshots o los últimos n-snapshots.
Un dato que se nos había quedado olvidado en el tintero y que parece trivial es que todas nuestras copias están cifradas con una clave que debemos introducir cuando trabajamos con el repositorio, esto es:
restic -r ~/restic/backup/ key list enter password for repository: repository 55c7852e opened successfully, password is correct ID User Host Created ---------------------------------------------------------------------- *eee185a2 fjfunes fjfunes@trevenque 2018-06-01 22:32:21 ----------------------------------------------------------------------
Estas y otras operaciones, así como el uso de distintos destinos como repositorio están documentados en la página de la herramienta, así que no os será difícil indagar y mejorar el uso de la misma y adecuarla a vuestras necesidades. Por ejemplo, ejecutándola automáticamente mediante scripts.
¿Habéis notado eso? No, no es la cola de una ballena blanca que lanza espuma de mar sobre vuestros valiosos datos, es la fresca sensación de tenerlos a buen recaudo gracias a nuestra querida herramienta Restic.
En la próxima entrega de esta serie de posts sobre herramientas de backup, hablaremos de Bacula. Una de las cosas que más me intrigó cuando la conocí fue el curioso logotipo de su página web y el lema que había en ella:
«It comes in the night and sucks the essence from your computers.»
