577 - El cron lo carga el diablo

577 - El cron lo carga el diablo

Realizar copias de #seguridad en #Linux y #Docker utilizando #cron o #systemd y como monitorizar la actividad con herramientas como #OpenObserve

1:25
-3:15

El día que se me ocurrió la idea de levantar OpenObserve para controlar los contenedores Docker y otros procesos en mi VPS principal, me tenía que haber dado un premio. Con el paso del tiempo esta herramienta se ha convertido en una fuente increíble de resolución de errores y problemas. El último de ellos ha sido precisamente un error cometido con el cron. Y esto es precisamente de lo que te voy a hablar hoy.

El cron lo carga el diablo

Un paseo por el pasado

No solo es importante automatizar el proceso de realizar copias de seguridad, sino que también es importante tener un testigo de que estas copias se están realizando.

Inicialmente podrías pensar que con que me avise cuando falle es suficiente. Sin embargo esto tiene mas peligro que un caramelo en la puerta de un colegio. Puede ser que tu sistema de aviso no esté funcionando y por eso no te avisa.

La mejora solución, para mi, es que los avisos sean siempre, es decir, tanto cuando funciona como cuando falla. Así, por ejemplo, yo tengo establecido una copia de seguridad todos los días, y me notifica siempre. De esta manera tengo una notificación de cuando se ha realizado la copia de seguridad, y si esta copia ha sido satisfactoria o no.

Inicialmente, comencé con notificaciones a Telegram, pero esto no era lo mas efectivo, porque pierdes la visión de conjunto. En este sentido decidí cambiar este sistema por otro mas efectivo.

Sobre OpenObserve

Y justo en ese momento, cuando me dí cuenta que Telegram no era la mejor opción para las notificaciones pensé encontré ZincSearch. Que era el precursor de OpenObserve.

Si no conoces ZincSearch u OpenObserve, indicarte que son herramientas similares a ElasticSearch. Si tampoco conoces ElasticSearch, indicarte que se trata de una base de datos no relacional.

Básicamente se trata de una herramienta donde puedes guardar datos como si no hubiera un mañana, y sin una estructura definida. En general se trata de guardar documentos json, con toda la información que tu necesitas.

El problema que me econtraba con ElasticSearch es que tiene un consumo de recursos desproporcionado, lo que lo hacía inviable para tenerlo en mi VPS.

En el caso de OpenObserve va un paso mas allás de ElasticSearch, en el sentido de que tiene una interfaz gráfica integrada en la misma aplicación. Pero es que además tiene un consumo de recursos sensiblemente inferior OpenObserve al consumo de ElasticSearch. Y si esto todavía te parece poco, OpenObserve te permite realizar búsquedas utilizando SQL, como si de una base de datos relacional se tratara. ¿Que mas se puede pedir?.

Con OpenObserve tener una visión global de, por ejemplo, dos semanas vista de tus copias de seguridad, es algo realmente sencillo. De esta manera, no tienes que ir en el día a día, sino que puedes hacer algo mucho mas general.

Sobre copias de seguridad

Actualmente además de notificaciones de distintos procesos que tengo automatizados, como puede ser la publicación en redes sociales, las copias de seguridad son un proceso vital para mi. De esta forma, y tal y como te describía anteriormente, tengo notificaciones cada vez que realizo una copia de seguridad, tanto si es satisfactoria como no.

En este sentido tengo dos procesos que se encargan de realizar copias de seguridad de mis bases de datos. Por un lado, las de MariaDB, que básicamente se refieren a las bases de datos de las páginas web que tengo en WordPress y bajo Docker, mariabdb-backup. Y por otro lado otro contenedor Docker postgres-backup, que se encarga de lo mismo, pero, en este caso, lo hace de las bases de datos PostgreSQL, que son mi ojito derecho.

Estas dos imágenes Docker tienen la posibilidad de ejecutar procesos cuando se disparan determinados eventos. En este sentido, yo lo tengo para que me notifique cuando se realiza cada una de las copias de seguridad, y directamente lo publica en OpenObserve.

Estos contenedores docker tienen implementado una versión de cron, que me permite programar las copias de seguridad.

Sobre cron vs systemd timer

Hace algún tiempo publiqué un tutorial sobre Systemd, y en particular sobre los Timer de Systemd, que me gustan particularmente mas que crond, porque me permiten una mayor granularidad, y por eso lo adopté preferentemente.

Sin embargo, en el VPS, lo que quiero es tener el menor número de aplicaciones instaladas. Cada aplicación instalada en el VPS es susceptible de mantenimiento y de vulnerabilidades. Minimizando el número de aplicaciones minimizo el número de riesgos.

Por otro lado, si bien, los timer son realmente cómodos y te dan mucha granularidad, lo cierto es que están en la propia máquina, mientas que un contenedor Docker con su configuración, lo tienes en un directorio y puedes hacer fácilmente copia de ellos. Y esto es precisamente lo que me hizo decantarme por tener cron en un contenedor.

Sobre cronirs

Y ¿Como tener un cron en un contenedor? De esto precisamente he hecho varias tentativas. Empezando pro el propio crond, hasta implementar el mio propio en Rust, del que te hablo en el episodio 453 titulado Backups de bases de datos en Docker programadas.

La ventaja de cronirs, que es como llamé a mi aplicación es que te permite controlar hasta segundos, aunque generalmente esto es raramente necesario. Pero era una interesante solución, y sobre todo, y que demonios, yo soy el padre de la criatura.

Sobre el cron lo carga el diablo

Hasta aquí te he contado como hago para tener un control de que es lo que sucede con mis copias de seguridad, pero no te he contado que es lo que me sucedió. La cuestión, es que si conoces crontab, sabrás como se programa.

Para que te hagas una idea, si quieres realizar una copia de seguridad cada 24, la programación sería la siguiente,

0 */24 * * *

Esto lo que indica es que en el minuto 0 cada 24 horas. Y esto del minuto cero es importante, por lo que te mostraré a continuación. Porque, sin embargo, en mi caso lo que había puesto era,

0 */24 * * *

0 */24 * * *

Esto lo que indica es que se ejecute cada minuto cada 24 horas. Por ponerte un ejemplo, se ejecutará una vez cada minuto entre las 23 y las 24 horas. Una auténtica locura.

Sobre crontab.guru

En general utilizo crontab.guru para ajustar mis expresiones de cron. Sin embargo, en ocasiones paso de hacerlo porque estoy tan acostumbrado, que simplemente me confío, y entonces fallo de primero de cron. Así que mas vale asegurarse que cometer un error tan absurdo.

De cualquier forma, como te decía lo interesante es poder ver un gráfico con las copias de seguridad de un solo vistazo, porque si no, solo hubiera visto la última, y hubiera pensado que todo iba correcto, y no es así.

1 comentario en “El cron lo carga el diablo

  1. KA
    karlggest hace 4 meses

    No entiendo el comentario de que «están en la propia máquina, mientas que un contenedor Docker con su configuración, lo tienes en un directorio»
    (Ya de paso, en mientas puedes corregir la r).

    O sea, los temporizadores y los servicios de systemd se guardan en las carpetas correspondientes (para un backup lo suyo es en la carpeta de usuario)

    Salud!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *