Estrategia de Backups para Evitar Pérdida de Datos

La primera vez que tuvimos un fallo crítico en el almacenamiento de una de nuestras máquinas virtuales, el pánico fue real.
Estábamos convencidos de que todo estaba bajo control, pero descubrimos que el archivo de respaldo estaba corrupto justo cuando más lo necesitábamos.
Esa día entendimos que no basta con copiar archivos; necesitamos una estrategia de backups para evitar pérdida de datos que sea verificable y automática.
No queremos pasar tres días reconstruyendo una configuración de nginx o recuperando la base de datos de la radio desde cero.

Por qué el respaldo es vital para una radio independiente

Operar La MIX Radio y Radio OnE las 24 horas implica que cualquier caída prolongada es un problema visible.
En una emisora independiente, el contenido y la configuración del servidor son el corazón del negocio.
Si perdemos los scripts de Python que gestionan la automatización o las bases de datos de los oyentes, el daño no es solo técnico, sino operativo.
No tenemos un equipo de IT de diez personas para resolver desastres; somos nosotros contra el reloj.

La tensión real aparece cuando el hardware empieza a envejecer.
En nuestro homelab con Proxmox, manejamos discos que han trabajado sin descanso.
Sabemos que el fallo del disco no es una posibilidad, sino una certeza matemática.
Por eso, basar la continuidad de la radio en la esperanza de que el disco no falle es un error que solo se comete una vez.

Esto nos lleva a pensar que el respaldo no es un evento aislado, sino un proceso continuo.
No se trata de hacer un «clon» el domingo y olvidarse el resto del mes.
La verdadera seguridad reside en la redundancia y en la capacidad de volver al aire en pocos minutos, no en horas.

Cómo aplicamos la protección de datos en nuestro homelab

Para que nuestra estrategia de backups para evitar pérdida de datos funcione, dividimos la información según su criticidad.
No respaldamos el sistema operativo de una VM cada hora, porque eso llenaría el almacenamiento en un instante.
En cambio, priorizamos los datos dinámicos y los archivos de configuración manuales que nos costaron horas de sueño ajustar.

En Proxmox, utilizamos los snapshots para cambios rápidos. Si vamos a tocar una configuración delicada de Icecast en la VM 111, hacemos un snapshot previo.
Si algo rompe el servicio a las 2 de la mañana, volvemos al estado anterior en segundos.
Sin embargo, el snapshot no es un backup; es solo una fotografía temporal que vive en el mismo almacenamiento.

Para los respaldos reales, movemos los datos fuera del nodo principal.
Usamos un almacenamiento externo donde guardamos los backups de los contenedores (CT) y las máquinas virtuales.
Los archivos de configuración de Python y los scripts de Emily (gTTS) los versionamos en un repositorio privado.
De esta forma, aunque el servidor físico desaparezca, el código y la lógica de la radio siguen vivos en otro lugar.

Lo que nos funcionó y los errores que cometimos

Al principio intentábamos respaldar todo el disco duro de las VMs.
Fue un error grave porque los archivos resultantes eran gigantescos y el tiempo de restauración era eterno.
Aprendimos que es mucho más eficiente respaldar el volumen de datos por un lado y la configuración del sistema por otro.

Otro problema fue confiar en un solo disco externo conectado por USB.
Un día el cable falló y el backup se interrumpió sin que nos diéramos cuenta.
Ahora aplicamos la regla del 3-2-1: tres copias de los datos, en dos soportes diferentes y una de ellas fuera de la casa o en la nube.

Además, descubrimos que el backup más peligroso es aquel que nunca se prueba.
Pasamos meses haciendo copias automáticas hasta que un día intentamos recuperar un archivo de la base de datos y vimos que el proceso de compresión había dañado el archivo.
Ahora, una vez al mes, hacemos un simulacro de restauración en un entorno aislado para confirmar que todo vuelve a la vida correctamente.

La única forma de validar una estrategia de backups para evitar pérdida de datos es intentando recuperar el sistema desde cero.
Si no has probado la restauración, no tienes un backup, tienes un archivo que ocupa espacio.

Herramientas que mantenemos en nuestro flujo de trabajo

No usamos software corporativo complejo, sino herramientas que podemos controlar y monitorizar.
En el núcleo tenemos Proxmox, que gestiona los backups de las VMs y CT de forma nativa y programada.
Para la automatización de tareas menores, usamos scripts de Python que mueven logs y archivos críticos a carpetas de respaldo.

Para la orquestación de avisos, n8n es nuestra pieza clave.
Hemos creado un flujo que nos envía un mensaje a Telegram si el proceso de backup falla.
No tenemos que entrar cada mañana a revisar logs; el servidor nos avisa si algo salió mal.
Esto es fundamental cuando gestionas dos radios y un blog simultáneamente.

Para el almacenamiento de los scripts y la configuración de WordPress en fabiomartinez.com, usamos Git.
Nos permite volver a cualquier versión anterior del código si una actualización de Python rompe la integración con la API de Icecast.
Es una capa de seguridad extra que complementa la imagen completa del servidor.

Acciones concretas para implementar esta semana

Si no tienes un plan claro, no intentes montar una arquitectura compleja hoy mismo.
Empieza por identificar cuáles son los tres archivos o carpetas que, si desaparecen, dejarían a tu radio fuera del aire.
Probablemente sean tus archivos de configuración, tu base de datos y tus scripts de automatización.

Copia esos archivos en un disco externo o súbelos a una nube privada ahora mismo.
Luego, programa una tarea simple en tu servidor para que se repita cada noche.
Una vez que tengas eso, intenta borrar el archivo original y recuperarlo desde la copia.
Solo cuando logres hacer eso sin estrés, habrás dado el primer paso real hacia una infraestructura segura.