Anécdota: ¡Out of Memory! ¡Sacrifiquen a los niños!

Los mensajes de error en linux pueden ser algo fatalistas. Out of Memory, Sacrifice child puede sonar como sacrifiquen a los niños y no me sorprenderia llegar a esa conclusion si hay un proceso que juzga y asesina en caso de que escasee la memoria RAM.

Esto puede ser una lección sobre como las copias de respaldo pueden salvar vidas.

Tabla de Contenido

Introducción

Administrar un servidor propio es una buena forma de obtener practica y experiencia, por lo que he ido recopilando información sobre el tema como la vez en la que un sitio web de WordPress cayó por una actualización.

Debido a diversas circunstancias, actualmente tengo dos instancias VPS de idénticas características, cada una destinada a diferentes propósitos que en la practica resultan difusos; una para experimentos, otra para servicios web persistentes(paginas, blogs, herramientas)

Yo no tengo experiencia administrando servidores de forma profesional, pero a medida que he ido aprendiendo cosas, he caído en cuenta de que es necesario tener tanto una IP publica, como un equipo permanentemente conectado a la red, para lograr algunas cosas así que he ido aprendiendo cosas nuevas vez tras vez. Algunas, a costa de todos mis datos almacenados.

La historia de hoy comienza con un error común, que he subestimado al pensar que no pasaría nada:

Sep 29 12:52:46 archvb systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
Sep 29 12:52:46 archvb systemd[1]: mariadb.service: Failed with result 'exit-code'.
Sep 29 12:52:46 archvb systemd[1]: Failed to start MariaDB 10.4.8 database server.

Este error se solucionaba simplemente reiniciando el servicio, pero esta vez, en lugar de encender el servicio, la respuesta fue esta:

Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.

Este error no me resultaba nuevo puesto que también es un error normal, pero resultaba inesperado debido a que al volver a intentar reiniciar el servidor, salía de nuevo el mismo error. Algo no estaba yendo bien.

Mi falta de experiencia me condujo a hacer lo mismo que incluso un profesional haría; buscar en Google.

Por supuesto, Google me respondió de la misma forma fatalista como lo haría con una persona preocupada por su salud, solo que en mi caso, todas las soluciones pasaban por borrar la base de datos por completo e iniciar de cero. Terror y depresión instantánea.

Dado que esa instancia la utilizo para hacer experimentos, no hay muchos datos que valgan la pena ahí. A lo mucho los Logs del sistema domótico y los del bot para descargar música, que en general solo es información estadística (que ya perdí en otro evento catastrófico anterior). El problema era que también cree una instancia de Nextcloud, especialmente complicada de mantener.

Entre practica y practica le había tomado cariño y agregando plugin, empecé a agregar datos que puedo rescatar sin problema alguno. Lo complicado era volver a configurar todo Nextcloud de cero.

Busque en los logs del sistema tratando de entender lo que sucedía, pero no he habilitado un log de archivo por parte del servicio. Por supuesto, la carpeta estaba vacía.

¡Out of Memory! ¡Sacrifiquen a los niños!

citando de la base de conocimientos de neo4j.com:

The Out Of Memory Killer or OOM Killer is a process that the linux kernel employs when the system is critically low on memory. This situation occurs because the linux kernel has over allocated memory to its processes.

El Asesino para liberar memoria u OOM Killer, es un proceso que el kernel de Linux emplea cuando el sistema esta críticamente bajo de memoria. Esta situación ocurre porque el kernel de Linux ha sobre asignado memoria a sus procesos.

Linux Out of Memory killer – Neo4s knowledge base

Echándole un ojo al dmesg, encontré este mensaje:

[11668880.114121] Out of memory: Kill process 25000 (mariadbd) score 96 or sacrifice child
[11668880.118537] Killed process 25000 (mariadbd) total-vm:1085072kB, anon-rss:97060kB, file-rss:0kB, shmem-rss:0kB

Esta información solo confirmaba mis sospechas, pero seguía sin dar con una solución. Decidí entonces apagar todos los servicios para empezar a borrar los archivos como decían las instrucciones. Hasta que se me ocurrió intentar por ultima vez levantar el servicio de mysqld. ¡Y se levantó!

A salvo. ¿Ahora que?

No es la primera vez en la que mi servidor cae. Pero si es la primera en la que lo hace tras optimizarlo y mimarlo tanto, por lo que pensé que lo mejor seria realizar un respaldo regular de las bases de datos para empezar. ¿Pero donde?

• Es posible crear una tarea programada con CRON para extraer una copia de seguridad en el mismo servidor, pero ¿de que serviría si esta cae junto a el?

• Para empezar, de todas formas, comenzare haciendo una copia de seguridad local regular.

• Es posible, mediante SSH, crear una copia de seguridad en un equipo físico, también con CRON. Hacerlo de forma regular permite poder restaurar hasta algún punto en el que no haya arruinado algo al travesear con las configuraciones.

• Debo investigar si es posible utilizar otros servicios en la nube para crear respaldos. Tal vez Google Drive o OneDrive, puesto que tampoco tengo algo tan valioso como para pagar un servicio en la nube.

• Y por supuesto, Todos los respaldos deben ser automáticos. Hacerlo de forma manual es probablemente mas inseguro que no hacerlo.

Consideraciones

Por el momento estoy investigando como hacer respaldos regulares, Locales, pero regulares, utilizando el cliente de consola MySQL y el automatizado de procesos CRON. Y realmente me esta gustando CRON. No entiendo por que le tuve tanto miedo si ha sido tan fácil de usar. Aunque tengo que conceder que todo lo que se maneje por consola es aterrador y mas si es poco o nada intuitivo.