La duda es legítima: si un host o una VM de Proxmox cae en manos de ransomware, ¿se “infecta” también la copia de seguridad? Con Proxmox Backup Server (PBS) la respuesta, bien configurado, es tranquilizadora: las copias anteriores permanecen intactas. El motivo no es esotérico, sino arquitectura de almacenamiento: PBS trocea (chunking) los datos de la VM/CT en pequeños fragmentos (chunks) inmutables y direccionados por contenido. Cuando haces una nueva copia, únicamente se referencian los chunks ya existentes que no han cambiado y se añaden los nuevos; no se reescriben los viejos.
Eso implica que si realizas un backup después de que una VM esté cifrada por ransomware, ese backup concreto contendrá la VM cifrada… pero los snapshots de backup anteriores (sus índices y los chunks que referencian) no se modifican. Podrás restaurar la VM a un punto previo a la infección.
A partir de aquí, conviene separar qué hace y qué no hace PBS, y cómo reforzar el conjunto con ZFS, replicación y operativa para que ese “recuperé en 3 segundos” no sea un golpe de suerte, sino el resultado de un diseño consciente.
Qué hace PBS que ayuda frente a ransomware
- Chunks inmutables y direccionados por contenido. Cada trozo se almacena como un fichero identificado por su hash. Si los datos no cambian, se reutiliza el chunk; si cambian, se crea uno nuevo. Un backup posterior no puede “corromper” un chunk usado por backups anteriores.
- Deduplicación real. Como los chunks repetidos se comparten entre versiones, ahorras espacio y acortas ventanas de copia. Esto reduce la tentación de “purgar” porque el repositorio crece menos de lo esperado.
- Prune y Garbage Collection explícitos. Los chunks no se borran por sí solos: primero prunas versiones (retención), y después ejecutas GC para liberar los chunks huérfanos. Si no habilitas permisos de prune/GC a cuentas de servicio, se minimiza el riesgo de borrados malintencionados.
- Cifrado lado cliente (opcional). Puedes cifrar los backups en el cliente (PVE/proxmox-backup-client) con tu clave, de forma que el PBS no pueda leer los datos, lo que limita el impacto de una brecha en el servidor de copias.
- Verificación programable. Las tareas de Verify recalculan hashes y detectan corrupción o almacenamiento defectuoso antes de necesitar la restauración.
Conclusión: si el ransomware solo afecta a la VM o al host origen, la historia de backups en PBS queda a salvo y permite volver atrás.
Lo que no hace PBS (y por qué necesitas operativa)
PBS no es un cofre mágico: si un atacante consigue credenciales con permisos de administración sobre PBS, podría borrar índices o lanzar prunes agresivos… y, tras un GC, perderías versiones. Tampoco evita que un operador borre por error. Por eso, además de la arquitectura, necesitas controles de acceso, separación de funciones y (mejor aún) otra copia fuera de banda.
Buenas prácticas concretas
- Cuentas y permisos mínimos.
- La API key o usuario que usa PVE para enviar backups al PBS debe tener rol “Backup” (no Admin, no Prune).
- Reserva Prune y GC a una cuenta diferente (idealmente con MFA) y proceso aprobado.
- Segmentación y aislamiento.
- PBS en una red distinta, no unido al dominio/AD, con firewall explícito (solo desde PVE, IPs de administración y destinos de sincronización).
- Si usas ZFS en PBS, datasets dedicados, sin compartir shares de escritura al resto de la LAN.
- Retención sensata y verificación.
- Retén más allá de la mediana de “dwell time” del ransomware (30–90 días es habitual; ajusta a tu riesgo y espacio).
- Programa Verify semanal/mensual para no descubrir problemas el día de la catástrofe.
- Replicación pull y copias fuera de banda.
- Configura un PBS secundario (off-site) que “tire” (pull) de los backups del principal. El pull reduce la superficie: el origen no necesita credenciales que puedan empujar o borrar en el destino.
- Si tu riesgo lo exige, añade cinta (LTO) con Proxmox Tape Backup o un cold storage que puedas desconectar. La copia offline es lo único realmente inmune al ataque online.
- Monitorización y alertas.
- Alertas ante prunes inusuales, pérdida de verificación, espacio bajo o fallos de jobs.
- Registra eventos de login y cambios de ACL; activa 2FA en la UI de PBS.
ZFS, snapshots y “3 segundos”: qué pasó en ese vídeo
Lo que viste de “recuperé en tres segundos” con una VM Windows muy probablemente usó snapshots de ZFS gestionados por sanoid/syncoid. ZFS fotografía el estado de un dataset en un instante (snapshot). Volver atrás con zfs rollback pool/dataset@snap es instantáneo porque solo mueve punteros.
- A favor: velocidad de vértigo para deshacer cambios, y con syncoid puedes replicar snapshots a otro equipo ZFS (ideal para DR).
- Limitación: un snapshot no es backup por sí mismo; si el atacante consigue root en el host ZFS, puede destruir snapshots. Por eso la replicación a otro host (mejor desconectado o con recepción sólo-pull) es clave.
PBS vs snapshots ZFS no es un duelo; son capas complementarias:
- Snapshots ZFS = RTO muy bajo para volver rápido en el mismo almacenamiento/replicado.
- PBS = historial deduplicado, retención larga, verificación y cifrado opcional, pensado para recuperar en otro sitio si el primario cae.
Recuperación: de la teoría a la práctica
Restaurar una VM desde PBS (camino típico)
- Identifica el backup previo a la infección en la UI de PBS/PVE (por fecha/verify).
- Lanza Restore (desde PVE:
qmrestore/UI) y elige target storage. - Si el almacenamiento es rápido (NVMe) y el backup está deduplicado en el mismo PBS, la rehidratación va muy rápida.
- Arranca la VM restaurada desconectada de la red, valida integridad (AV, hashes, pruebas de aplicación) y, después, vuelve a conectar.
Rollback con ZFS (cuando aplica)
- Apaga la VM o detén I/O del dataset.
zfs rollback pool/VM-dataset@antes_ransom- Arranca y valida.
- Si usas syncoid, puedes traer el snapshot bueno de un replica target si el local fue destruido.
Pro tip: en VMs Windows, si vas a restaurar controladores de dominio o aplicaciones con estado, ten a mano guías específicas (USN rollback, authoritative restore, etc.). El backup recupera bits; la coherencia de AD/SQL/Exchange/… requiere su propia liturgia.
Checklist de hardening (imprimible)
- PBS en segmento de red dedicado, sin acceso de usuarios finales.
- Usuarios PBS con roles mínimos; PVE solo con Backup. MFA para Admin.
- Política de retención ≥ ventana de dwell time estimada.
- Verify periódico + alertas de fallo.
- Pull sync a PBS secundario / cinta offline.
- ZFS con snapshots y replicación (si procede).
- Backups cifrados (client-side) para cargas sensibles.
- WAF/Firewall delante de PBS; acceso por VPN/SSO.
- Ensayos de restore trimestrales (VM completas y ficheros).
- Documentación de runbooks (restore, borrados accidentales, pérdida de credenciales, caída completa de PBS).
Preguntas rápidas
¿Puede un ransomware cifrar el repositorio de PBS?
Si el atacante solo compromete la VM/host origen, no; PBS escribe nuevos chunks, no reescribe los viejos. Si obtiene acceso de escritura/administración en el servidor PBS, podría borrar/prunar; de ahí la importancia del principio de mínimo privilegio, pull replication y copias offline.
¿Necesito ZFS para usar PBS?
No. PBS funciona sobre ext4, xfs o ZFS. ZFS aporta snapshots/replicación y autocorrección (checksums + scrub), muy útiles en backup.
¿Qué retención es razonable?
Depende del negocio y el dwell time. Como base para ransomware: diario 30–60 días + semanal 3–6 meses + mensual 12 meses (ajusta a presupuesto y riesgo).
¿Por qué oigo historias de “recuperé en 3 segundos”?
Eso suele ser rollback de snapshot (ZFS), no una rehidratación completa desde backup. Es válido si el snapshot sobrevive y el almacenamiento no fue comprometido; por eso insistimos en replicar y en mantener backups independientes en PBS.
Moraleja. PBS te da historial inmutable y recuperación fiable frente a ransomware en el origen. ZFS te da velocidad con snapshots y replicación. Lo que salva el día no es una marca, sino el diseño: mínimos privilegios, copias pull/offline, verificación y ensayos. Con eso, el “restauré en tres segundos” deja de ser un vídeo viral y pasa a ser un procedimiento repetible.
