Backups automáticos en un VPS: por qué la mayoría lo hace mal

La diferencia entre backup y esperanza

La mayoría de los tutoriales de backup se quedan en “instala esto y programa un cron”. Eso no es un sistema de backup. Es una esperanza automatizada. Un backup real tiene que cumplir tres condiciones: ser externo al servidor, ejecutarse sin intervención y avisarte si falla. Si falta cualquiera de las tres, no tienes backup — tienes una ilusión de seguridad. Los backups son una de las 5 señales de que tu web necesita mantenimiento.

Los snapshots del proveedor de hosting son útiles como red de seguridad adicional, pero no son un backup. No controlas cuándo se hacen, cuánto tiempo se retienen ni si incluyen todo lo que necesitas. Depender exclusivamente de ellos es asumir un riesgo innecesario.

Qué backupear y qué no

El error más común es intentar copiar todo el servidor. Es lento, caro y absurdo. El sistema operativo se reinstala en minutos. Las imágenes de Docker se descargan de nuevo. Los logs se regeneran.

Lo que sí tiene que estar en el backup:

Datos de los sitios: el contenido que se sirve, uploads, bases de datos exportadas
Configuración de la infraestructura: los docker-compose.yml de cada stack (si usas volúmenes Docker para datos persistentes, asegúrate de exportarlos)
Certificados TLS: el archivo donde Traefik guarda los certificados de Let’s Encrypt
Scripts operativos: todo lo que automatiza el servidor, incluyendo los propios scripts de backup y monitorización

Lo que no merece backup:

Sistema operativo (se reinstala)
Contenedores e imágenes Docker (se descargan)
Logs y cachés (se regeneran)
Código fuente de las webs (vive en Git)

El setup: rsync + Storage Box + cron + Telegram

Mi sistema de backup es deliberadamente simple. rsync copia los datos cada noche a un servidor de almacenamiento externo accesible por SSH. rsync es eficiente porque solo transfiere los archivos que han cambiado desde la última ejecución.

El script de backup se ejecuta como root a las 3:00 AM con cron:

0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

El flujo es secuencial y predecible:

Exporta los volúmenes Docker que contienen datos persistentes (como n8n) a un archivo comprimido
rsync de los datos de los sitios al Storage Box
rsync de los certificados TLS
rsync de la configuración de los stacks
rsync de los scripts operativos
Notificación por Telegram del resultado

Si todo va bien, silencio. Si algo falla, recibo un mensaje de Telegram con el paso exacto que falló. Esta política de “silencio = éxito” evita la fatiga de alertas — cuando suena el bot, es que hay un problema real.

Las alertas son la mitad del sistema

Un backup sin alertas es un backup que falla en silencio. He visto casos donde el cron dejó de funcionar hace meses y nadie se dio cuenta hasta que necesitaron restaurar. Por eso el script está diseñado para que el fallo sea imposible de ignorar.

Las credenciales del bot de Telegram están centralizadas en un solo archivo de entorno. Todos los scripts del servidor — backup, monitorización, checks de SSL — leen de ahí. Cuando hay que rotar el token, se cambia en un único sitio.

El paso que nadie da: probar la restauración

Aquí está la verdad incómoda: la mayoría de la gente que tiene backups nunca ha probado a restaurar. Y un backup que no se ha probado no es un backup — es una esperanza con cron.

Mi rutina de verificación:

Semanal: reviso los logs para confirmar que no hay errores silenciosos
Mensual: verifico que los archivos en el Storage Box están completos y son recientes
Trimestral: simulo una restauración completa en un entorno limpio y mido el tiempo

La prueba trimestral es la más reveladora. La primera vez que la hice descubrí que me faltaba backupear los scripts operativos — tenía los datos pero no la automatización que los gestionaba. Desde entonces, los scripts también se copian.

El resultado real

Si mi VPS desaparece mañana, puedo tener todo funcionando en un servidor nuevo en menos de una hora. No porque sea rápido, sino porque el proceso de restauración está documentado y probado. Cada pieza tiene su sitio, cada paso está verificado.

Eso es lo que diferencia un backup profesional de un tutorial copiado de internet: no es el rsync ni el cron. Es la disciplina de probar que funciona antes de necesitarlo. Si quieres profundizar en estrategias de backups externos, también tengo un artículo sobre rsync para backups fuera del servidor.

Si gestionas un VPS y quieres asegurar también el acceso, te puede interesar cómo eliminé SSH público usando Cloudflare Tunnel. Y si todavía estás decidiendo qué tipo de alojamiento necesita tu negocio, tengo una comparativa entre hosting compartido y VPS pensada para no técnicos. Los backups son solo una parte del mantenimiento profesional que tu web necesita.

Si prefieres que alguien gestione los backups y monitorización de tu VPS de forma profesional, puedo encargarmede todo el sistema mientras tú te centras en tu negocio.