Backup a prueba de ransomware: por qué elegimos Kopia y Backblaze B2
Un backup que un atacante de ransomware puede cifrar o borrar no vale nada. Ese fue el único requisito que dictó toda la decisión, y nos llevó a una conclusión inequívoca tras comparar 11 motores de backup de código abierto y cuatro proveedores de almacenamiento.
Cuál es realmente el problema — «cosechar y luego cifrar»
En un ataque de ransomware moderno, el atacante obtiene privilegios en el dispositivo y luego hace dos cosas: cifra los archivos, y borra o cifra también los backups para que no puedas restaurar. Si tu agente de backup guarda las claves del almacenamiento, el atacante que tomó el control del dispositivo también las tiene, y borra el backup. Así que la primera pregunta no es «con qué rapidez haces el backup», sino «¿puede borrarse el backup en absoluto?».
Qué comparamos — 11 motores de código abierto
Recorrimos todo el panorama: restic, BorgBackup, Kopia, Duplicati, Duplicacy, rclone, UrBackup, Bareos, Proxmox Backup Server, ZFS y Clonezilla. De cada uno comprobamos: dedup + cifrado del lado del cliente, soporte para Windows (incluido VSS para archivos abiertos), escritura directa a S3 y, sobre todo, Object-Lock real.
| Motor | Cifrado + dedup | Object-Lock (ransomware) | Licencia comercial |
|---|---|---|---|
| Kopia | ✓ | ✓ Compliance nativo | Apache-2.0 |
| restic | ✓ | Aún no lanzado | BSD |
| BorgBackup | ✓ | solo append-only | BSD |
| Duplicati | ✓ | Sobrescribe archivos | MIT |
| Duplicacy | ✓ | Parcial | Uso comercial prohibido |
| Proxmox Backup | ✓ | Object-Lock lo corrompe | AGPL |
Por qué elegimos Kopia
Kopia es hoy el único motor que hace a la vez dedup + cifrado del lado del cliente y soporta Object-Lock en modo Compliance contra almacenamiento S3. restic es excelente y popular, pero su soporte de Object-Lock aún no se ha lanzado. Borg es potente en Linux, pero no tiene soporte real para Windows ni Object-Lock contra S3. Duplicacy queda descalificado por licencia (no puede incrustarse en un producto comercial). El veredicto técnico fue claro.
Además: Kopia es un único binario (Go), se ejecuta en Windows (con VSS), Mac y Linux, de modo que gestionamos un solo motor en toda la flota, con salida JSON fácil de orquestar desde el agente.
Y por qué Backblaze B2 — y no Cloudflare R2
Ya trabajamos sobre Cloudflare, así que R2 era la opción obvia. Pero indagamos a fondo y descubrimos: los «bucket locks» de R2 no son la API Object-Lock de S3, y no tienen ninguna garantía de compliance probada de que «una clave comprometida no pueda borrar». Eso no cumple nuestro listón WORM.
| Almacenamiento | Object-Lock real | Coste de egress (restauración) | $/TB/mes |
|---|---|---|---|
| Backblaze B2 | ✓ Compliance | Gratis vía la CDN de Cloudflare | ~7 $ |
| Wasabi | ✓ | Limitado | ~7 $ |
| AWS S3 | ✓ (el estándar) | 0,09 $/GB | ~23 $ |
| Cloudflare R2 | No probado | ~gratis | ~15 $ |
B2 ofrece WORM real, el almacenamiento más barato y egress gratuito vía la CDN de Cloudflare, de modo que las restauraciones son casi gratis. R2 se queda con nosotros para los datos de la aplicación y una copia secundaria barata, pero no para la pata inmutable.
Cómo lo probamos — no nos fiamos del marketing
Cada afirmación se verificó contra una fuente primaria: la documentación oficial de cada motor, las discusiones de la comunidad sobre Object-Lock y las licencias. Dos hallazgos críticos los descubrimos precisamente gracias a esta lectura: (1) restic sigue sin soportar lock, y (2) Proxmox Backup puede corromper el datastore si le habilitas Object-Lock. Sin esta comprobación habríamos elegido mal.
Dónde somos honestos: restauración completa a un servidor virtual
Los motores de archivos (Kopia/restic) restauran datos, no una máquina arrancable. «Levantar todo el entorno en una VM con un clic» es exactamente donde Veeam/Datto/Proxmox superan al código abierto. Nuestra decisión: construir los archivos + el núcleo inmutable sobre Kopia + B2 (donde ganamos en precio y soberanía), y para la restauración completa del servidor, integrar/revender un motor comercial en lugar de construir desde cero. La honestidad supera a las promesas.
Cómo lo seguimos mejorando: control de calidad continuo
Un backup que no se prueba = esperanza, no un plan. Por eso, cada ~3 semanas se ejecuta una prueba de restauración automática: el sistema restaura una muestra del backup, verifica un checksum contra un valor conocido y reporta éxito/fallo a la puntuación organizativa. Un fallo = una alerta inmediata. Además, reevaluamos la elección de motor y bucket cada trimestre: restic podría lanzar Object-Lock, y R2 podría añadir compliance-WORM real, y entonces lo reconsideraremos. La decisión no está congelada.
Este artículo describe consideraciones de diseño y decisiones tecnológicas. Los precios y las capacidades de licencia son válidos a mediados de 2026 y pueden cambiar. No hay aquí claves, secretos ni detalles de configuración sensibles.
← Todos los artículos