Bitácora de Vuelo

La frase "hay que hacer backup" es una de esos mantras que uno repite y repite pero sobre los que raramente acciona.

A menos que, como a mí, se les haya roto hardware y hayan perdido información. Ya hace muchos años que hago backup y tengo distintos métodos para salvaguardar mi data.

Así y todo, no lo tenía 100% resuelto. Tengo mucha información que es imposible recuperar (ejemplo: ¡fotos!) en dos discos en casa y "en la nube", pero hay otro montón que sólo tenía localmente.

Y sí, uno piensa que en el caso de "se me prendió fuego la casa" o "me entraron a robar y se llevaron las compus" toda la información que no tenía backup externo pasa a un segundo plano en importancia. Pero no, porque aparte de que te pasó alguna de esas "catástrofes", encima perdiste la info esa, de la cual puede depender tu laburo...

En el pasado les comenté que tenía la intención de hacer backups externos en algo como Amazon Glacier, y hace un tiempo empecé a ver qué onda, calcular un poco qué costos tendría, etc.

Justo en esa época me aumentaron el precio del servicio que pago en Dropbox, en el que tengo 2 TB de almacenamiento, entonces tomé la decisión de usar Dropbox como "lugar remoto en dónde hacer backup": no tenía que contratar otro servicio, no tenía que incrementar mis costos al respecto, no tenía que aprender a usar otro backend, etc. Todo redondo.

Entonces apunté a un directorio bajo Drobox el rdiff-backup que venía ejecutando (que me dejaba copias diferenciales de mis datos importantes en otro disco).

Y ahí empezó un pequeño descalabro que más o menos pude manejar. Es que rdiff-backup me copió al Dropbox un trillón de pequeños archivos con variadísimos nombres. No es culpa de esa herramienta, claro, sino que es esa justamente la info que me interesa resguardar.

Pero Dropbox probó ser bastante flojito.

Por un lado, algo que ya sabía: hay un montón de limitaciones que tiene Dropbox con respecto a los nombres de los archivos. Parte de esas limitaciones son porque el sistema de archivos de Windows es más limitado, y Dropbox te transmite esas limitaciones incluso cuando une no esté replicando esos archivos en Windows.

Y luego se le complicó manejando el trillón de archivitos que le aparecieron de repente. No era un problema de "ancho de banda" (que no estaba saturada), sino de cantidad de archivos. Más allá que le tuve que levantar un límite del sistema operativo al proceso, tuve que matarlo y volver a levantarlo mil veces hasta que terminó de procesar todo. Ahora quedó más o menos andando: a veces se cuelga, y cuando arranca tarda un buen, buen rato en estar disponible.

Hace un par de semanas me cansé y opté por hacer algo al respecto.

Y armé un script en Python que lo que hace es agrupar archivos y directorios en "paquetes con nombres sanos", y después mete eso directamente en Dropbox. Ok, lo resumí demasiado, vamos con más detalles...

Al script se le pasa un archivo de configuración que tiene tres datos obligatorios:

• rootdir: el directorio raiz del árbol completo que se quiere hacer backup

• builddir: un lugar en donde se van a ir dejando todas las estructuras intermedias

• syncdir: el lugar final a donde copiar todo lo generado

Entonces al arrancar trabaja leyendo ese árbol desde rootdir, dejando unos comprimidos (.tar.gz) en builddir. Esos comprimidos son todos los archivos de ese directorio raiz, más cada uno de sus directorios (sub-árboles enteros), teniendo en cuenta siempre de sanitizar los nombres para que sean todos válidos para Dropbox.

Luego de recorrer todo, manda lo que armó al destino final en Dropbox (syncdir) directamente, sin usar rsync-diff, porque Dropbox ya me da la funcionalidad de "historial" de los archivos (para la cuenta que tengo, 30 días).

Dos "grandes detalles"...

Por un lado, hay archivos o directorios que quiero ignorar; un ejemplo típico en mi caso es ~/devel/reps, porque todo lo que tengo ahí está en github, o launchpad, o etc. Bueno, en ese archivo de configuración que mencioné antes se puede indicar una lista de "todo lo que se quiere ignorar".

Por otro lado, hay directorios que no tiene sentido empaquetar directamente, sino que conviene explorarlos un poco más. Por ejemplo, no tiene sentido empaquetar .local directamente, ni siquiera .local/share, sino que lo más piola es tener .local/share como directorios normales y empaquetar los quichicientos directorios que están ahí adentro, por separado. Para esto el archivo de configuración incluye algo llamado "niveles de agrupamiento": para dicho ejemplo tendríamos: .local: 2

La idea general es tener "paquetes", ni muy chicos (serían miles, en el extremo volveríamos a la situación original), ni demasiado grandes (porque si tenemos un paquete de 5GB, y entre backup y backup cambiamos un solo byte de eso, el archivo nos queda diferente). Por eso por ejemplo lo que hay adentro .local/share conviene empaquetarlo todo separado, porque lo más probable es que poco de eso cambie de backup a backup.

Para ayudarnos a analizar esa situación (y ver si nos conviene ignorar algo, o cambiar los niveles de agrupamiento de algún directorio), el script al terminar nos da un resumen de tamaños de archivos y sus estados con respecto al backup anterior. De esta manera podemos detectar si tenemos algún directorio grande que está cambiando todo el tiempo, y que quizás querramos discriminar en sus subdirectorios.

Si piensan usarlo, y se les complica con algo o necesitan algún detalle, me avisan!

No, no es la parte dos de una película clase B.

El programa Encuentro es un pedazo de software que permite buscar, descargar y ver contenido de Encuentro y otros canales; no distribuye contenido directamente, sino que permite un mejor uso personal de esos contenidos.

Lo arranqué al principio de la década pasada y tuvo muchas etapas. Me ayudó un montón de gente en el mismo, es que uno de los puntos claves era "entender" los distintos backends para poder bajar los videos, y pasaba que a veces cambiaban, y había que adaptarse.

Pero hace unos años pasó que se vinieron les chetes al gobierno, y fueron matando muchas cosas del Estado. Y mi Encuentro quedó desactualizado, y sin muchos backends para brillar, y fue perdiendo prioridad en mi sobreabultada lista de tareas. Encima tenía el fantasma flotando de dos migraciones complejas: saltar de Qt 4 a Qt 5, y de Python 2 a Python 3. Y no me daba meterme con eso solamente por amor al arte.

Entonces lo maté. Bueno, no, tampoco es que lo maté. Solamente dejé de meterle tiempo. Quedó ahí, flotando en el éter.

Fast forward al presente.

Hace algunas pocas semanas recibí un mail de un tal Santiago Torres Batán que quería agregarle a Encuentro el backend de Contar. Y era consciente de las dos migraciones que había que hacer, y las había explorado y todo.

Le expliqué un poco toda la burocracia que teníamos que sobrellevar para traer al coso esto de la muerte, y me ayudó a hacerla (pasándome comands, documentación, ideas).

Entonces lo primero que hicimos fue migrar el proyecto a git, y lo metimos en GitHub (tanto código como issues). Luego él propuso el branch para migrar de Qt 4 a 5 y de Python 2 a 3, con un detalle: había que aplicar ambos al mismo tiempo. Yo los barajé un poco, terminé metiendo el de Qt directamente, y el de Python así como estaba pero con otro branch mío atrás cambiando una miríada de detalles.

Ahora es un proyecto moderno. Bienvenido Encuentro al veinte veinte.

El próximo paso es actualizar los backends. Como les decía, Santiago ya está trabajando en Cont.ar, y luego hay que "limpiar" los otros que ya no funcionan más. Hay que ponerle amor en el futuro, pero (ahora) la base está.