Backups de servidores Linux en 2026: la regla 3-2-1 explicada con casos reales

La conversación incómoda

La mayoría de empresas a las que entramos a hacer una auditoría tienen "backups". El problema empieza cuando preguntamos lo siguiente:

• ¿Cuándo se hizo el último que has restaurado de verdad?
• ¿Sabes cuánto tardarías en levantar tu web si el servidor desapareciera ahora mismo?
• ¿Tu copia de seguridad está en el mismo servidor que la base de datos?

La respuesta más común a la tercera es "sí". Y ahí ya tenemos el problema: si el servidor cae, te quedas sin web y sin backup.

La regla 3-2-1 en lenguaje claro

La regla 3-2-1 no es nueva. Lleva décadas siendo el estándar y sigue vigente en 2026 porque resuelve el 95% de los desastres reales:

• 3 copias de tus datos: el original más dos copias.
• En 2 medios distintos: por ejemplo disco local del servidor + almacenamiento externo. No vale tres carpetas en el mismo disco.
• 1 copia fuera de las instalaciones: en otro datacenter, otra región o un proveedor distinto. Esta es la que te salva si arde la sala de servidores o si tu proveedor desaparece.

En 2026, "fuera de las instalaciones" suele significar un bucket de S3, Backblaze B2 o un servidor en otro proveedor cloud. Lo importante no es la tecnología, es el aislamiento.

Qué hay que copiar exactamente

Esto es donde más metemos la pata. Un backup "del servidor" no significa nada si no detallas qué incluye:

El error clásico es respaldar la web y olvidarse de /etc. El día que toca reinstalar, descubres que reconstruir manualmente nginx, fail2ban, postfix y sudoers cuesta más que perder los datos.

Las herramientas que usamos en 2026

No hay una "mejor herramienta", hay la que encaja con tu caso:

• restic — Backups encriptados, deduplicados e incrementales. Soporta nativamente S3, B2, Azure, GCS, SFTP y disco local. Es nuestra primera opción en proyectos nuevos.
• borgbackup — Similar a restic, con compresión y deduplicación muy buenas. Idóneo si el destino es un servidor SSH con almacenamiento propio (no cloud).
• rsnapshot — Veterano, sencillo, basado en rsync y hardlinks. Bueno para copias rápidas a NAS local. No encripta, así que el destino debe ser de confianza.
• percona xtrabackup o mariabackup — Para bases de datos MySQL/MariaDB grandes donde el mysqldump ya tarda demasiado.
• mydumper / myloader — mysqldump paralelizado. Sigue siendo lo más cómodo para bases de hasta unos cientos de GB.

Si tu stack incluye Docker, suma un volcado periódico de los volúmenes (docker run --rm -v vol:/data -v $(pwd):/dest alpine tar czf /dest/vol.tgz /data) y no des por hecho que la imagen del contenedor es suficiente.

El paso que casi nadie hace: la restauración de prueba

Un backup que no se ha restaurado nunca no es un backup, es una esperanza. Te lo decimos en serio: la mitad de las veces que hemos abierto una copia "que llevaba años funcionando" hemos encontrado uno de estos:

• Volcados de SQL truncados sin que nadie se enterase.
• Permisos del filesystem que impiden leer la mitad de los ficheros.
• Ficheros enormes excluidos por una regla vieja del .rsync-filter.
• Versiones de software incompatibles entre el origen y el destino.

La prueba mínima razonable: una vez al trimestre, levantar un servidor de pega, restaurar el backup más reciente y verificar que la web arranca y la base de datos se puede consultar. Si la empresa es crítica, una vez al mes.

Encriptado y retención: las dos preguntas que no se hacen

Encriptado. Si tu backup viaja a un proveedor externo sin encriptar, estás regalando tu base de datos a quien comprometa esa cuenta. restic, borg y duplicity encriptan por defecto; rsnapshot y rsync, no. La clave de encriptado debe guardarse en un sitio distinto al backup (un gestor de contraseñas del equipo sirve).

Retención. No tiene sentido guardar 100 backups diarios. Sí tiene sentido aplicar una política tipo:

• 7 backups diarios.
• 4 backups semanales.
• 12 backups mensuales.
• 2 backups anuales.

Total: 25 puntos de restauración cubriendo dos años, con ocupación manejable. restic y borg lo hacen con un solo comando (forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 2).

Tres casos reales (anonimizados)

Caso 1 — La tienda online sin backup externo. Cliente con una tienda PrestaShop facturando bien. Backups diarios... en el mismo VPS, en /home/backups. Un fallo de disco del proveedor dejó el servidor inaccesible 18 horas. El backup también. Se perdieron 6 días de pedidos porque la última copia "que pudimos recuperar" era de antes. Solución posterior: restic + Backblaze B2 + restauración de prueba mensual.

Caso 2 — El backup que tardaba 14 horas en restaurarse. Servidor con base de datos de 80 GB. Backups con mysqldump simple. El día del incidente, restaurar tardó toda la noche y media mañana. Cambiamos a mariabackup + restic. Restauración bajó a 25 minutos.

Caso 3 — Los ficheros que nadie sabía que existían. Migración de un servidor antiguo. El backup que nos pasaron incluía /var/www y /etc/mysql. Faltaban: una carpeta /data/legacy con 12 GB de PDFs históricos, los certificados Let's Encrypt en /etc/letsencrypt, y un cron que se invocaba desde otra máquina por SSH. Aprendimos a auditar la máquina viva con lsof + find antes de definir el alcance del backup.

Cuánto cuesta tener esto bien

Para un VPS medio con web + base de datos pequeña:

• restic o borg: gratis.
• Backblaze B2 o equivalente: alrededor de 6 € al mes por 1 TB almacenado.
• Un sistema automatizado y revisado: lo configuramos en una jornada de trabajo y queda funcionando con cron + alertas por email.

Comparado con el coste de perder una semana de pedidos, o de tener un cliente importante caído un día, es probablemente la mejor relación coste/beneficio de toda tu infraestructura.

Lista mínima de verificación

Si no quieres leerte todo el artículo, este es el resumen accionable:

• Tienes al menos 3 copias de los datos críticos.
• Una copia está fuera del servidor de producción (otro proveedor, otra región).
• Tu backup incluye base de datos, código, /etc, claves SSH y certificados.
• El backup va encriptado si viaja a un servicio externo.
• Tienes política de retención automática (diarios, semanales, mensuales).
• Has restaurado una copia de prueba en los últimos 3 meses.
• Tienes alertas si el backup falla (no basta con cron, hace falta saberlo).

Si has marcado menos de 5, hay trabajo que hacer.

Preguntas frecuentes

¿Es suficiente con el snapshot del proveedor de cloud? No. Los snapshots viven en la misma cuenta y el mismo proveedor. Si pierdes acceso a la cuenta (factura impagada, hack, error de borrado), se van también. Sirven como capa rápida, pero no como copia única.

¿RAID es un backup? No. RAID te protege de la rotura de un disco, no de un borrado accidental, un ransomware, un fallo de aplicación o un error humano. Son cosas distintas.

¿Vale con git para el código? Para el código sí, si todo está commiteado. Pero no cubre uploads de usuarios, base de datos ni configuración. Necesitas la pieza complementaria.

¿Hace falta cifrar si el destino es un servidor mío en otro datacenter? Sí. Cifrar es barato y te protege en caso de que ese servidor caiga en malas manos por cualquier motivo. No se pierde nada por cifrar siempre.

Conclusión

Tener backups buenos no es complicado, pero exige sentarse una jornada a pensar el alcance, elegir herramientas, automatizarlo y dejarlo monitorizado. Lo que sale caro es no hacerlo, y descubrirlo el peor día posible.

Si quieres que repasemos los backups de tu infraestructura, identifiquemos huecos y dejemos un sistema 3-2-1 funcionando, hablamos sin compromiso.