Bacula: backup inmutable anti-ransomware sin coste por TB

Por qué tu backup es lo primero que va a tocar un atacante

En marzo, Bacula Systems publicó un artículo con un título que lo deja todo dicho: la infraestructura de backup vale más para un atacante que una cuenta de administrador de dominio. Y no es un titular para vender; es lo que están viendo los equipos de respuesta a incidentes desde hace un par de años.

Si hablas con cualquiera que haya pasado por una recuperación de ransomware "de las feas", el patrón se repite una y otra vez:

Fíjate en lo que pasa entre el día 11 y el 15. El atacante dedica días enteros a neutralizar tu backup antes de pulsar el botón del cifrado. Porque sabe algo que nosotros a veces olvidamos: si el backup sobrevive intacto, él pierde la partida. Por eso la pregunta correcta de 2026 ya no es "¿tenemos backups?" — esa la tenemos resuelta desde hace 20 años. La pregunta incómoda, la que duele, es: ¿esos backups se pueden destruir desde dentro de mi propia red?

Si la respuesta honesta es "sí, probablemente", no estás solo. La mayoría de entornos que auditamos parten de ahí.

"Backup inmutable" sin marketing de por medio

Hay un problema con el término "backup inmutable": se ha convertido en la palabra favorita del departamento de marketing de cualquier fabricante. Todos lo usan, todos lo prometen, y significa cosas distintas según quién lo diga.

Vamos a la definición que cuenta, la técnica: un backup es realmente inmutable cuando, una vez escrito, nadie puede modificarlo ni borrarlo hasta que expire su retención. Ni tú. Ni el admin con el password maestro. Ni un atacante que se ha hecho root en el servidor de backup. Nadie. Y eso se consigue de tres formas — las tres sólidas, las tres soportadas por Bacula desde el primer día:

Si nunca habías oído el concepto 3-2-1-1-0, apuntatelo porque lo vas a ver mucho en los próximos meses. Es la evolución del clásico 3-2-1 de toda la vida: tres copias, en dos medios distintos, una offsite… una inmutable, y cero errores de verificación. Ese "1-0" del final es lo nuevo. Ya no vale con tener copias — tienen que ser imposibles de alterar, y alguien tiene que estar verificándolas sin que hagas nada. Bacula hace las dos cosas automáticamente, como parte de su rutina normal.

Qué tiene Bacula que otros no

Bacula lleva en producción más de 20 años. No es un proyecto nuevo ni una promesa; está corriendo ahora mismo en bancos, en ministerios, en hospitales, en operadoras de telecomunicaciones y en laboratorios científicos que manejan petabytes. Su edición comercial, Bacula Enterprise 18.0.8, acaba de sumar funciones específicas anti-ransomware: BGuardian (que detecta cuando alguien intenta envenenar el catálogo), un BWeb Security Center para tener todo a la vista, y soporte nativo para Microsoft 365, Nutanix AHV y snapshots CSI de Kubernetes. Vamos, lo que una empresa espera encontrar en 2026.

Pero lo que lo hace especialmente sólido para este juego no es el listado de features. Son cuatro decisiones de diseño que tomaron hace años y que ahora se pagan solas:

• Todo está separado por diseño. El director que orquesta, el catálogo que indexa, los storage daemons que escriben, y los clientes que se protegen — cuatro procesos distintos que pueden vivir en hosts distintos con credenciales independientes. Comprometer uno no te da los otros tres.
• El catálogo vive en PostgreSQL de verdad. Una base de datos real, con sus backups, sus réplicas, sus permisos, auditable como cualquier otra base de datos crítica. Puedes ponerla detrás de un firewall distinto del plano de datos. Puedes encriptarla. Puedes replicarla a otro sitio.
• Se verifica a sí mismo. Bacula vuelve a leer los backups periódicamente, compara checksums y te avisa si algo no cuadra. Si alguien ha metido mano, te enteras antes del día malo, no durante.
• Es open source de verdad. El formato de los volúmenes está documentado. Si mañana desaparecemos nosotros, o desaparece Bacula Systems, tus backups se siguen pudiendo recuperar con las herramientas de la comunidad. Eso es propiedad real de tus datos, no un eslogan.

Esa arquitectura no es glamurosa. No sale bien en una presentación de ventas. Pero es exactamente la que necesitas cuando alguien, dentro de tu red, está intentando hacerte todo el daño que puede.

La parte del dinero (y por qué Bacula sale a cuenta)

Hablemos claro de precio, porque es ahí donde Bacula hace más ruido. La diferencia con Veeam, Veritas o Commvault no es de descuento — es de modelo. Los tres grandes te cobran por volumen: por terabyte protegido, por workload, por host, por socket. Cuanto más creces, más pagas. Es un modelo fantástico para el fabricante, y cada vez más doloroso para el cliente.

Bacula Systems factura por número de clientes y por funcionalidades. Puedes duplicar el dato protegido durante el año y el coste no se mueve. Y Bacula Community, la edición open source, directamente no tiene licencia — pagas solo el trabajo de los ingenieros que te lo ponen a punto y te lo mantienen.

En las migraciones que hemos hecho, el ahorro suele estar entre el 60% y el 85% en la factura anual de backup el primer año. El pico lo vemos en entornos medianos, de 20 a 200 TB protegidos, que es donde los modelos por capacidad pegan más fuerte. Y lo interesante es que el ahorro se va ampliando con el tiempo: Bacula no te castiga por crecer, así que cada año que pasa la diferencia con el modelo antiguo se hace mayor.

Cinco decisiones que marcan la diferencia

Instalar Bacula es razonablemente fácil. Hay paquetes para casi todo, la documentación es buena y en un par de horas tienes algo haciendo copias. Diseñar un Bacula que aguante a alguien con root en tu red ya es otra historia. Estas son las cinco decisiones que, por experiencia, separan un backup que funciona de un backup que también sobrevive:

1. Separa el plano de control del plano de datos

El director y el catálogo PostgreSQL tienen que vivir en una red administrativa distinta de los servidores que estás protegiendo. Con MFA para quien accede, y a ser posible con un enfoque zero-trust en los propios servidores de backup. Parece una obviedad, pero la mitad de instalaciones que vemos tienen el director colgando del mismo segmento de red que los clientes. Es como guardar la llave de la caja fuerte dentro de la caja fuerte.

2. Al menos dos repositorios independientes

Uno rápido, en disco o en Ceph con Object Lock, para los restores del día a día — el típico "me he cargado una BD a las 11 y la necesito a las 12". Y un segundo repositorio air-gap para retención larga, que puede ser tape LTO, o un Ceph aislado, o ambos. Es lo que hace que un atacante que se ha hecho dueño del primero no se lleve también el segundo. Volvemos a la regla 3-2-1-1-0 — no es un capricho de consultoría, es lo que marca la diferencia el día que pasa algo.

3. Verificación automática, todas las semanas

Bacula sabe volver a leer volúmenes ya escritos y comprobar que los checksums cuadran. Ese job de verificación debería correr semanalmente como mínimo. Es lo que te avisa de la manipulación, del bit rot, del fallo raro del hardware. Configurarlo son cinco minutos y te ahorra el peor día de tu carrera.

4. Retenciones bloqueadas en origen

La retención se define en el director cuando se escribe el volumen, y se sella en el medio en ese mismo momento. Una vez que un volumen está en una cinta WORM o en un bucket con Object Lock activo, ya no hay manera — ni por bconsole, ni por SQL, ni por el soporte del fabricante — de acortar su retención. Si alguien con privilegios de admin intenta borrar ese dato antes de tiempo, no puede. Ese es exactamente el punto.

5. Prueba los restores. De verdad.

Un backup que no se ha restaurado nunca no existe, existe solo en el papel. El ejercicio de recuperación hay que hacerlo, y hay que hacerlo bien: no restaurando una VM vacía de prueba, sino cargas representativas de lo que de verdad duele si se pierde. En SIXE esto lo metemos como parte del Plan de Recuperación ante Desastres, con pruebas calendadas al menos dos veces al año y con un informe que llega al comité de dirección. Porque si no llega al comité, no se hace.

Migrar desde Veeam sin perder el histórico

La objeción que nos llega siempre, en la primera llamada, es la misma. "Tenemos siete años de histórico en Veeam, no nos podemos permitir perderlo". Y es justa — en banca, sanidad o administración pública, la retención larga no es una preferencia, es un requisito regulatorio (ENS, ISO 27001, GDPR, normativa sectorial). Tranquiliza saber que una migración bien diseñada no pierde un solo byte.

La forma en la que lo hacemos se parece siempre un poco a esto:

1. Ventana de coexistencia. Durante varias semanas — a veces meses — tu Veeam o tu Veritas sigue haciendo lo suyo en paralelo con el Bacula nuevo. Tienes doble cobertura mientras dura la transición. Si algo sale raro en Bacula, el antiguo está ahí.
2. Restores reales, no de laboratorio. Antes de apagar el sistema antiguo, restauramos desde Bacula cosas que importan de verdad. No una VM de prueba; cargas representativas. Solo cuando esos restores validan el diseño, pasamos de fase.
3. Histórico en modo solo lectura. El dato viejo se mantiene accesible en modo consulta el tiempo que exija tu política de retención. Si en 2027 alguien pide un restore de 2023, sigue disponible. Lo nuevo ya vive en Bacula.

Este servicio de migración es probablemente lo que más nos están pidiendo últimamente — por la combinación de subidas de precio en el licenciamiento propietario y la nueva exigencia de backup inmutable que está empujando a mucha gente a replantear su estrategia. El detalle completo del servicio, con SLAs y casos reales, lo tienes en la página dedicada: Soporte técnico y migración a Bacula.

Por dónde empezar hoy mismo

Si has llegado hasta aquí y estás pensando "tendría que revisar nuestro backup", probablemente tengas razón. No hace falta arrancar un proyecto enorme para dar el primer paso. De hecho, lo más útil suele ser una auditoría corta que responda honestamente a tres preguntas:

• ¿Son mis backups realmente inmutables? Si un atacante con credenciales de admin en mi red quisiera destruirlos, ¿podría?
• ¿Se están verificando automáticamente? ¿O solo sabré si están corruptos el día que los necesite de verdad?
• ¿Cuánto estoy pagando al año por TB protegido, y qué cara tendrá esa factura dentro de tres años?

Las tres preguntas las puedes responder tú con tu equipo, sin llamar a nadie. Y si alguna de las respuestas no te gusta, hablamos. Sin comercial por medio, sin PowerPoint, directamente con alguien del equipo técnico que ha tenido las manos dentro de proyectos como el tuyo.

Para seguir leyendo

• 10 errores de arquitectura y ROI en la migración post-VMware — otro caso donde el modelo propietario obliga a replantearse decisiones que llevaban años aparcadas
• Migración de VMware a Proxmox VE — Bacula integra bien con Proxmox para backup consistente a nivel de VM, y muchas veces van de la mano
• Soporte técnico Ceph — si tu repositorio inmutable va a ser Ceph con Object Lock, aquí entra nuestra otra especialidad