La próxima evolución del backup

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...

"No te preocupes, tengo una copia en un disco y la otra en la habitación de al lado" - Tu casa ↑

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.

Se colgó

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!

Comentarios Imprimir

El retorno de Encuentro

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.

Encuentro

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.

Chucky el asesino de softwares

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á.

Comentarios Imprimir

Encuarentenades

Muy a fines de Febrero viajé a Frankfurt para una semanita de laburo como tantas otras. El bardo del coronavirus ya amenazaba pero no había explotado.

Dos semanas antes de ese viaje nos habían dicho que el sprint se seguí haciendo, no se cancelaba. Luego una semana antes nos contaron que todes les trabajadores de China y alrededores (no recuerdo exactamente las zonas) NO iban a venir al sprint. Y dos días antes de viajar bajaron la comunicación de "si querés NO venir, podés".

Yo viajé, con muchas precauciones. Canonical hizo mucho hincapié en todas las medidas de seguridad al respecto. Desde recomendar no saludarnos con contacto físico, hasta poner a disposición alcohol en gel en todos los espacios todo el tiempo. Ayudó también que tuvimos todos habitaciones individuales, aunque esa decisión se había tomado meses atrás por otras razones.

Típicos árboles de jardines cerveceros

Volví el fin de semana siguiente. Ya se hablaba mucho más del tema. Pero no se lo tomaba tan en serio. Yo tomé la decisión de aislarme de adultes mayores (mis mamá, mi papá, otres amigues), pero no mucho más.

Incluso ese lunes (yo volví el domingo) hice tenis, y el martes batería. El miércoles ya se hablaba sobre que les que viajamos deberíamos estar aislados, entonces corté toda interacción con el mundo exterior. El jueves hablé con la escuela de les chiques y decidimos que elles dejen de ir (la cuarentena general para estudiantes fue declarada el lunes siguiente).

Todo muy rápido.

Eso fue hace cuarenta días. Y acá seguimos, encuarentenados.

Yo estoy laburando como siempre, en ese sentido no me cambió nada: lo mio es 100% remoto desde hace mucho. Moni, como trabaja en Salud, sigue yendo a laburar (aunque con actividades y horarios distintos). Y les pibes con tarea enviada por la escuela (usando Google Classroom, y con reuniones por Zoom).

En verdad, tengo menos tiempo libre que antes, ya que no sólo laburo todo el día y tengo a les pibes en casa (como a principios de Enero, digamos), sino que encima les tengo que ayudar/asistir con sus actividades extras...

Este bardo la agarró a Male en su cumpleaños, encima :(. Hicimos todo lo posible para que la pasara bien. Muchas videollamadas, actividades especiales como una búsqueda del tesoro (siguiendo pistas por toda la casa), hicimos que ella defina los menús de mediodía y noche, cocinamos unas galletitas de limón, y hasta eligió una peli para ver ("Gremlins", que tuvo que ser al día siguiente, porque nos quedamos sin tiempo).

Creemos que la terminó pasando bien. Incluso hace unos días alguien en una videollamada le preguntó cómo había pasado su cumple y contestó algo como "al principio triste pero después estuvo excelente" :D.

En el desayuno, y buscando las pistas

Y no fue ni va a ser el único cumple así, no. Hace unos días cumplió mi vieja, un bajón que lo haya tenido que pasar sola :(. Le hicimos una merienda en videoconferencia, con familia que se fue conectando, le cantamos el feliz cumple, etc. :) Y ahora en Mayo cumple un montón de gente de mi familia, incluídes Moni y yo.

En fin, es un bajón, pero nos la bancamos porque nos parece que el aislamiento social preventivo es uno de los métodos más efectivos para manejar esto. Para cerrar, les recomiendo esta otra página de El Gato y La Caja, especialmente el gráfico de "trayectoria".

Comentarios Imprimir

Retomando efectivamente CDPedia

Hace un par de meses les contaba que iba a hacer un experimento social alrededor de un grupo de trabajo para poner al día CDPedia.

¡¡En el formulario que puse para que se anoten se inscribieron 80 personas!! Obviamente el grupo tenía que ser más chico (máximo 10 inscriptes, y tantos porque tengo a Dave y SAn que me dan una mano co-mentoreando).

Entonces me puse a analizar las propuestas, me quedaron tres grupos: unes cuatro que entraron directamente, unes 20 que "pasaron a la final", y el resto que quedaron directamente afuera. Para eses que pasaron a la final, hice un análisis más fino, teniendo una entrevista por videoconferencia de unos 10 minutos.

Todo eso llevó un buen tiempo, claro, y mi idea de arrancar en Marzo se fue evaporando. Luego endurecieron la cuarentena, y ahí también se fue diluyendo la posibilidad de hacer la primer reunión, el arranque, de forma presencial con todo el grupo.

Paisaje de Frankfurt

A principio de mes puse las cartas sobre la mesa y elegimos. Las alternativas eran esperar indefinidamente hasta poder arrancar presencial, esperar a luego de semana santa para ver qué pasaba, o cortar por lo sano y planear esa primer reunión de forma virtual. Optamos por esto último.

Hicimos una reunión previa para probar la herramienta que ibamos a usar para comunicarnos y asegurarnos que nuestras compus y configuraciones de audio/video funcionen ok, y ya el sábado pasado tuvimos el kickoff.

Nos juntamos virtualmente por seis horas (tres a la mañana, cortar una hora para el almuerzo, y tres a la tarde), con algunos mini-breaks más o menos cada hora.

Hubo una bienvenida y charla informal, nos presentamos cada une, les conté en detalle los objetivos de todo esto: aprender Python nivel básico / intermedio, o mejorar el nivel que tienen, ganar experiencia de trabajo en grupo (tanto remoto como presencial), aprender herramientas como control de versiones o manejo de issues, conocer prácticas modernas de desarrollo (tests, pep8, git, colaboración grupal), y tener una experiencia de trabajo como un "profesional de primer nivel".

Y, obviamente, ¡laburar en CDPedia! Esto lo separé en tres grupos principales: actualizar el código (pep8, tests, inglés, python3, etc), hacer cosas que teníamos planeadas (fixes, features), y hacer/anotar cosas que se nos ocurran que están buenas.

Después (y especialmente luego de almorzar) nos metimos con el control de versiones, Github, y el proyecto en sí. Charlamos de procesos, de comandos, les expliqué todo el proceso de la CDPedia, vimos algo de código, y lo más importante: cada une realizó el proceso en su máquina para obtener una imagen resultado (en modo test, poco contenido).

Esto último llevó tiempo porque la CDPedia no tiene muy afilado el tema de entornos y dependencias, pero lo fuimos sacando entre todes para los distintos casos.

Y no llegamos a ver los issues actualmente cargados, porque se nos terminó el sábado "laboral".

Estos días estuve acomodando y revisando los issues pendientes, marcando muchos como ideales para este experimento, y haciendo algunas cositas de soporte operacional, como migrar el mecanismo principal de comunicación del proyecto al nuevo Discourse de PyAr.

Y ayer viernes tuvimos la primer reunión semanal donde sí nos metimos con estos issues, charlamos un poco de lo que había visto cada une, y sentamos las bases para que en la segunda semana ya puedan empezar a producir código.

A les chiques les vi entusiasmades, ojalá puedan meterse de lleno y aprender un montón. Ojalá que se diviertan :)

Comentarios Imprimir

Liberando dos pequeñas utilidades

Desde que empecé a trabajar en Canonical (hace más de diez años) fuí recorriendo distintas "grandes etapas".

Una de ellas fue la aventura del "teléfono Ubuntu", en la cual mi participación era en el equipo con el que armamos una determinada infrastructura en la nube para dar soporte a programejos que corrían en el teléfono (que se llamaban scopes).

Parte de esa infrastructura era más o menos aburrida: sólo éramos un pasamanos de otros servicios, como por ejemplo en el caso del clima (como podrán imaginar, no predecíamos el clima nosotros, sino que usábamos The Weather Channel (si recuerdo correctamente)).

Pero había una parte de esa infrastructura que fue fascinante construir: eso que llamábamos "scopes scope", que era basicamente darle soporte a un "buscador genérico" que había en el teléfono. Estaba buena porque vos podías buscar algo y nosotros inferíamos un montón de eso, y te dábamos información y ofrecíamos/recomendábamos otros scopes del teléfono.

Por ejemplo, si ponías "metallica", nos dábamos cuenta que era una entidad en sí misma, y te dabamos la info de Wikipedia sobre Metallica. Pero también nos dábamos cuenta que era una banda y te dábamos acceso a música y videos, y te tirábamos busquedas relacionadas para que investigues (por ejemplo, la discografía). Si ponías "Roma" te ofrecíamos información de esa ciudad, y te dábamos acceso a que veas su mapa, el clima, etc.

Metallica

No sólo eso, sino también teníamos algunas utilidades, justamente sobre dos de las cuales les vengo a hablar hoy.

Una era un conversor de unidades genérico. Un par de ejemplos:

  • ponías 42 km a millas y te daba 42 kilometers = 26.0976 miles
  • ponías 217c en kelvin y te daba 217°C = 490.15K
  • ponías 2 cup cc y te daba 2 US cups = 473.1765 cubic centimeters

La otra, una calculadorita piola. Ejemplos:

  • ponías 5 + 2*pi y te daba 11.28318530717958623199592694
  • ponías e ** -1 / sin(55) y te daba -0.3679695299155818045728854210
  • ponías log2(64) y te daba 6

Les comento de estas utilidades que teníamos en el scopes scope porque cuando se decidió cancelar el proyecto del teléfono, empecé a mirar qué código me daba lástima perder.

El que hacía el análisis lingüístico que mencioné antes era repiola, pero en verdad era un bardo. Muy muy difícil de construir toda la parafernalia de pequeñas bases de datos preprocesadas para que anduviera. Y los que eran códigos "pasa manos" no eran divertidos. Y había otras cositas por ahí, pero meh.

Estas dos utilidades sí me entusiasmaron, así que pedí permiso para liberarlas. Me lo dieron, y en su momento las separé del código base en que estaban, y las puse en sendos proyectos en Launchpad, como primer paso.

Finalmente, en estos días de cuarentena las rescaté, llevé a github, migré a Python 3, le dí un poco de forma a cada proyecto en sí, y las terminé subiendo en PyPI: unitconv y pysimplecalc.

Tengan en cuenta que ambas utilidades las pueden usar tanto desde linea de comandos como importarlas como módulo y usarlas desde cualquier otro código Python.

Comentarios Imprimir