Copias de seguridad inmutables con ZFS: readonly y políticas de snapshots que realmente resisten

Qué significa “inmutable” en el mundo ZFS (y qué no)

En el marketing de backups, “inmutable” a menudo significa “pusimos una bandera y nos sentimos reconfortados.” En producción, inmutable significa algo más estrecho y comprobable:
los datos que te importan no pueden ser alterados ni eliminados dentro de una ventana de retención definida, incluso si un atacante o un operador obtiene el nivel habitual de acceso.

Con ZFS no obtienes un único interruptor mágico de inmutabilidad. Obtienes capas:

• Snapshots te dan consistencia en un punto en el tiempo y versionado barato.
• Datasets readonly reducen escrituras accidentales y evitan toda una clase de momentos “ups”.
• Holds y delegación de permisos pueden prevenir la eliminación de snapshots por operadores por defecto.
• Topologías de replicación pueden hacer que el servidor de backup sea “más tonto” (bueno) y reducir el radio de daño.
• Controles offline o de eliminación demorada (a menudo fuera de ZFS) son lo que hace llorar al ransomware.

Esto no es inmutabilidad ZFS:

• No protegen contra root en el host de backup. Si un atacante posee root y tiene las llaves, puede destruir tu pool. Tu trabajo es hacer eso más difícil, menos frecuente y detectable.
• No sustituye a copias fuera de sitio. El fuego y la inundación no se preocupan por snapshots.
• No está garantizado solo por “readonly=on”. Aún puedes destruir snapshots y datasets a menos que diseñes en contra de ello.

El objetivo operacional es aburrido: asegurar que siempre puedas restaurar alguna copia reciente y limpia dentro de tu ventana RPO, y que puedas probarlo rutinariamente.
“Aburrido” es un cumplido en ingeniería de backup.

Hechos y contexto histórico que moldean diseños reales de backup

• ZFS nació en Sun para eliminar la división “gestor de volúmenes + sistema de archivos”. Por eso los snapshots y la suma de comprobación son de primera clase, no añadidos.
• Copy-on-write es el truco habilitador. Los snapshots de ZFS son baratos porque los bloques se comparten hasta que cambian.
• ZFS suma comprobaciones de datos y metadatos de extremo a extremo. Esto hizo que la “corrupción silenciosa” fuera un problema solucionable, no una leyenda urbana.
• Los snapshots no son backups—por sí solos. Se almacenan en el mismo pool. La pérdida del pool equivale a pérdida de snapshots. Esta distinción se ha ignorado desde que se inventaron los snapshots.
• Los primeros adoptantes de ZFS aprendieron que “scrub” es un calendario, no una emoción. Los scrubs regulares encuentran sectores malos mientras aún tienes redundancia.
• El send/receive incremental se convirtió en el caballo de batalla del DR con ZFS. Es básicamente un diario de bloques cambiados entre snapshots.
• Las convenciones de nombres de snapshots se volvieron una industria propia. Porque cuando estás en pánico durante un incidente, escogerás el snapshot equivocado a menos que el nombre sea obvio.
• “Backups inmutables” se pusieron de moda tras la madurez del ransomware. Los atacantes aprendieron a borrar backups primero y luego cifrar. Los defensores aprendieron a dejar de facilitar la eliminación.

Una idea para tener en la pared: paraphrased idea “La esperanza no es una estrategia,” atribuida a James Cameron, repetida en operaciones porque duele de verdad.

Un modelo práctico: origen escribible, destino casi solo append

La arquitectura fiable más simple es asimétrica:

1. Origen (producción): datasets escribibles, snapshots frecuentes, emisor de replicación.
2. Objetivo de backup (vault): recibe snapshots, los mantiene readonly, los retiene y minimiza quién puede eliminarlos.
3. Objetivo secundario opcional (offsite): recibe desde el vault o directamente desde el origen, según límites de confianza.

El punto no es hacer el origen inmutable. El origen es donde corren las aplicaciones. Cambia constantemente. Tu trabajo es hacer que el destino sea difícil de manipular,
manteniendo las restauraciones prácticas. Si las restauraciones son difíciles, la gente no las probará. Si la gente no las prueba, estarás interpretando la recuperación ante desastres.

Modelo de amenazas, sin rodeos

• Eliminación accidental: un admin destruye snapshots o datasets, o un trabajo de limpieza se descontrola.
• Ransomware con credenciales: el atacante obtiene llaves SSH, tokens de API o admin de dominio y apunta a la infraestructura de backup.
• Host de backup comprometido: el atacante obtiene root en el vault y trata de destruir la retención.
• Corrupción: RAM mala, discos que mueren, HBAs inestables o firmware problemático—ZFS puede detectar, pero solo si haces scrub y monitorizas.

Tus defensas deben coincidir con la amenaza. Readonly protege contra escrituras accidentales. Holds y delegación protegen contra la eliminación por usuarios “normales”.
Para “root en el vault” necesitas separación (dominio de autenticación distinto, MFA, llaves limitadas), monitorización y, idealmente, una copia offline/offsite.

Datasets readonly vs snapshots: la diferencia que importa a las 2 a.m.

Dataset readonly significa que no puedes modificar archivos en la vista de sistema de archivos vivo de ese dataset (mountpoint). Es una barandilla.
Es excelente para objetivos de backup: recibes snapshots replicados y luego mantienes el dataset readonly para que nadie “edite rápidamente una configuración” dentro de la copia de backup.

Snapshots son vistas inmutables del dataset en un momento. Pero “inmutable” aquí significa que los bloques no cambiarán; no significa que un usuario privilegiado no pueda destruir el objeto snapshot.
La eliminación es el verdadero enemigo en escenarios de ransomware.

De qué protege readonly

• Ediciones aleatorias al dataset de backup por humanos curiosos.
• Servicios mal configurados que accidentalmente escriben en el punto de montaje del backup.
• Algunas clases de malware que simplemente cifran sistemas de archivos montados y escribibles.

De qué no protege readonly

• zfs destroy en snapshots/datasets por alguien con privilegios de ZFS.
• Destrucción del pool (zpool destroy), retirada de dispositivos o sabotaje de la importabilidad.
• Streams de replicación que sobrescriben tus expectativas (por ejemplo, receives forzados que retroceden).

Si solo recuerdas una cosa: readonly es para escrituras; holds/delegación son para eliminaciones.

Broma #1: Readonly es como poner tus sobras en la nevera de la oficina con tu nombre. Ayuda, pero no detiene a alguien hambriento y decidido.

Política de snapshots que no se pudre: nombres, cadencia, retención

Las políticas de snapshots se pudren cuando son ingeniosas. Evita la ingeniosidad. La política debe ser:
predecible, buscable y fácil de razonar durante una restauración.

Convención de nombres: elige una y nunca improvises

Usa un prefijo que codifique “gestionado por política” y una marca temporal que ordene lexicográficamente. Ejemplo:
auto-YYYYMMDD-HHMM para snapshots frecuentes, y daily-YYYYMMDD para niveles de retención más largos.

Puedes mantener múltiples niveles en el mismo dataset siempre que tu herramienta de retención los entienda. Si lo haces manualmente, mantenlo simple:
horario por 48 horas, diario por 30 días, semanal por 12 semanas, mensual por 12 meses. Ajusta según RPO/RTO y la realidad de capacidad.

Cadencia: ajusta a los ritmos del negocio, no a tus preferencias personales

• Bases de datos: las snapshots frecuentes importan, pero la consistencia importa más. Coordina con quiesce a nivel de aplicación o usa réplicas.
• Directorios personales: horario suele ser suficiente. La gente borra archivos durante el día; quieres rollbacks fáciles.
• Imágenes de VM: snapshot cerca de ventanas de cambio y antes de parches. También haz snapshots con suficiente frecuencia para cubrir “ups actualizamos lo equivocado”.

Retención: lo que guardas es lo que puedes restaurar

La retención es un ejercicio de presupuesto de almacenamiento con consecuencias. Tu política de retención debe caber en el pool con margen, o se autodestruirá:
los snapshots llenarán el pool, el rendimiento caerá, las asignaciones fallarán y alguien “temporalmente” eliminará snapshots para recuperar espacio.
“Temporalmente” es cómo mueren las políticas de backup.

No confundas número de snapshots con seguridad

Diez mil snapshots no son más seguros que cincuenta si no los replicas, verificas y proteges contra eliminación.
Grandes cantidades de snapshots también pueden ralentizar operaciones como listar snapshots y algunas tareas administrativas. ZFS maneja muchos snapshots bien,
pero tus humanos y tus herramientas quizá no.

Prevención de eliminaciones: holds, delegación y radio de explosión administrativo

Si tu amenaza de backup incluye ransomware, debes asumir que el atacante intentará eliminar snapshots. Necesitas al menos uno de:
holds, delegación de permisos que impida la destrucción de snapshots, o un sistema separado que haga cumplir la retención fuera de banda.
Idealmente: todo lo anterior, en capas.

Holds ZFS: el cinturón de seguridad infravalorado

Un hold previene la destrucción de un snapshot hasta que se libere el hold. Eso no es “inmutabilidad absoluta”, pero es una defensa fuerte contra
la eliminación accidental y contra atacantes que no tienen el conjunto específico de privilegios (o que no notan los holds).

Los holds son operativamente agradables porque son explícitos e inspeccionables. Puedes etiquetar holds con nombres como policy o vault.
Úsalos en el lado del vault para hacer cumplir ventanas de retención.

Delegación: menos personas deben poder destruir backups

Demasiadas organizaciones ejecutan el objetivo de backup con el mismo grupo de admins que la producción. Es conveniente. También es como darle al atacante un trato doble.
Divide roles:

• El usuario de replicación puede receive snapshots pero no puede destruir los antiguos.
• Operadores de backup pueden listar y restaurar, pero la eliminación de snapshots está protegida.
• Un rol break-glass puede quitar holds, con MFA y registro de auditoría.

Readonly en el vault sigue siendo útil

Incluso con holds, establece el dataset recibido como readonly. La mayoría del ransomware y la mayoría de los accidentes son aburridos: cifran archivos que pueden escribir.
Haz que “escribir” sea difícil y reduces la lista de víctimas.

Replicación bien hecha: patrones send/receive y modos de fallo

La replicación ZFS es poderosa porque copia snapshots exactamente, incluidas propiedades (cuando quieres), y puede ser incremental.
También es lo suficientemente afilada como para cortarte.

Patrón A: Origen crea snapshots, el vault recibe (predeterminado recomendado)

El origen toma snapshots según un horario. El vault tira o el origen empuja. El vault retiene snapshots más tiempo que el origen.
El dataset del vault es readonly y está protegido contra eliminación. Este es el estándar y funciona.

Patrón B: El vault crea snapshots del dataset recibido (útil para “historial lado vault”)

A veces quieres snapshots en el vault (por ejemplo, copias “daily-cold”) independientemente de lo que haga el origen.
Está bien, pero complica las restauraciones: ahora tienes dos espacios de nombres de snapshots y debes ser preciso sobre qué envías y qué retienes.

Modo de fallo: receives forzados y retrocesos inesperados

Las herramientas de replicación a veces usan flags que pueden retroceder el objetivo para que coincida con el stream del origen. Esto puede eliminar snapshots más nuevos del lado objetivo
o destruir historial local del vault si eres descuidado. Tu vault debe ser aburrido: principalmente recibir, retener y servir restauraciones.
Evita trucos bidireccionales “ingeniosos” a menos que verdaderamente los necesites.

Modo de fallo: cadena incremental rota

El send incremental requiere que la snapshot base exista en ambos lados. Si alguien borra una snapshot necesaria en el vault, tu siguiente replicación falla,
y la “solución” se convierte en un reenvío completo. Los reenvíos completos son caros, lentos y suelen ocurrir en el peor momento.

Broma #2: La replicación incremental es como el chisme de oficina—borra un detalle clave y de repente todos tienen que empezar desde el principio.

Tareas prácticas con comandos: qué ejecutar, qué significa, qué decides

Estas son tareas operativas reales. Ejecútalas en el host correcto (origen o vault) y trata la salida como un punto de decisión.
Cada tarea incluye: comando, salida de ejemplo, qué significa y qué haces a continuación.

Task 1: Confirmar dataset readonly en el vault

cr0x@server:~$ zfs get -H -o property,value readonly vault/backups/prod
readonly	on

Significado: El mount vivo del dataset no es escribible.
Decisión: Si está off, actívalo ahora en el dataset del vault (no en datasets de producción que las aplicaciones necesitan escribir).

Task 2: Forzar readonly (lado vault)

cr0x@server:~$ sudo zfs set readonly=on vault/backups/prod
cr0x@server:~$ zfs get -H readonly vault/backups/prod
readonly	on

Significado: Nuevas escrituras a través del mountpoint quedan bloqueadas.
Decisión: Si algún proceso necesita escribir, no debería usar el dataset del vault. Arregla el flujo de trabajo, no la bandera.

Task 3: Listar snapshots con tiempo de creación para verificar la cadencia

cr0x@server:~$ zfs list -t snapshot -o name,creation -s creation -r tank/prod | tail -5
tank/prod@auto-20251226-0100  Fri Dec 26 01:00 2025
tank/prod@auto-20251226-0200  Fri Dec 26 02:00 2025
tank/prod@auto-20251226-0300  Fri Dec 26 03:00 2025
tank/prod@auto-20251226-0400  Fri Dec 26 04:00 2025
tank/prod@auto-20251226-0500  Fri Dec 26 05:00 2025

Significado: La cadencia de snapshots es consistente; los nombres ordenan por tiempo.
Decisión: Si hay huecos, revisa cron/systemd timers, logs de la herramienta de snapshots y la salud del pool (los snapshots fallidos pueden ser síntoma).

Task 4: Comprobar presión de retención vía uso de espacio por snapshot

cr0x@server:~$ zfs list -t snapshot -o name,used,refer -s used -r tank/prod | head -5
NAME                         USED  REFER
tank/prod@auto-20251220-0100  48G   1.2T
tank/prod@auto-20251218-0300  41G   1.2T
tank/prod@auto-20251222-0900  39G   1.2T
tank/prod@auto-20251224-1800  35G   1.2T

Significado: Algunos snapshots retienen grandes cantidades de bloques antiguos (alto USED).
Decisión: Los snapshots con gran USED suelen ser “antes de una reescritura masiva”. Guárdalos si están dentro de la política; de lo contrario, poda por nivel, no por corazonada.

Task 5: Verificar holds en snapshots del vault

cr0x@server:~$ zfs holds vault/backups/prod@daily-20251201
NAME                               TAG     TIMESTAMP
vault/backups/prod@daily-20251201   policy  Fri Dec  1 00:05 2025

Significado: Un hold llamado policy previene la eliminación.
Decisión: Si no hay holds y confías en holds para inmutabilidad, añádelos sistemáticamente (idealmente vía automatización).

Task 6: Aplicar un hold a un snapshot que no debes perder

cr0x@server:~$ sudo zfs hold policy vault/backups/prod@daily-20251201
cr0x@server:~$ zfs holds vault/backups/prod@daily-20251201
NAME                               TAG     TIMESTAMP
vault/backups/prod@daily-20251201   policy  Fri Dec 26 05:40 2025

Significado: El snapshot ahora está protegido contra zfs destroy hasta que se libere el hold.
Decisión: Usa holds para niveles de retención, retenciones legales o congelados por incidentes. Documenta quién puede liberarlos.

Task 7: Probar que un snapshot no puede ser destruido por los holds

cr0x@server:~$ sudo zfs destroy vault/backups/prod@daily-20251201
cannot destroy snapshot vault/backups/prod@daily-20251201: snapshot has holds

Significado: La protección funciona.
Decisión: Si esto no falla como se espera, tu “inmutabilidad” es mayormente una sensación. Arréglalo antes del próximo incidente.

Task 8: Comprobar quién puede destruir snapshots (delegación)

cr0x@server:~$ sudo zfs allow vault/backups/prod
---- Permissions on vault/backups/prod --------------------------------
Local+Descendent permissions:
user repl-user create,mount,receive
user backup-ops mount,snapshot,send
user breakglass destroy,hold,release

Significado: La delegación de permisos restringe acciones destructivas a cuentas específicas.
Decisión: Si tu usuario de replicación tiene destroy, estás a una llave comprometida de arrepentimiento. Quítalo.

Task 9: Verificar salud del pool (porque replicación no arreglará discos malos)

cr0x@server:~$ zpool status -x
all pools are healthy

Significado: No hay fallos conocidos ahora.
Decisión: Si ves dispositivos degradados/faulted, arregla hardware primero. Los backups en un pool enfermo son solo entrega más lenta de corrupción.

Task 10: Comprobar resultados recientes de scrub

cr0x@server:~$ zpool status vault
  pool: vault
 state: ONLINE
  scan: scrub repaired 0B in 03:12:44 with 0 errors on Sun Dec 22 03:30:12 2025
config:

        NAME        STATE     READ WRITE CKSUM
        vault       ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

Significado: Se ejecutó scrub, no reparó nada, no encontró errores de checksum.
Decisión: Si no se programan scrubs, prográmalos. Si el scrub encuentra errores repetidamente, investiga discos, cableado y RAM.

Task 11: Confirmar que snapshots de replicación existen en ambos lados

cr0x@server:~$ zfs list -t snapshot -o name -r tank/prod | grep auto-20251226-0500
tank/prod@auto-20251226-0500
cr0x@server:~$ zfs list -t snapshot -o name -r vault/backups/prod | grep auto-20251226-0500
vault/backups/prod@auto-20251226-0500

Significado: El punto en el tiempo existe en ambos extremos, así que los incrementales pueden continuar.
Decisión: Si falta en el vault, la replicación está atrasada o fallando. Si falta en el origen, tu trabajo de snapshots está fallando.

Task 12: Ejecutar un send/receive incremental (manual, explícito)

cr0x@server:~$ sudo zfs send -I tank/prod@auto-20251226-0400 tank/prod@auto-20251226-0500 | ssh backup-vault sudo zfs receive -u -F vault/backups/prod
cr0x@server:~$ ssh backup-vault zfs list -t snapshot -o name -r vault/backups/prod | tail -2
vault/backups/prod@auto-20251226-0400
vault/backups/prod@auto-20251226-0500

Significado: La replicación incremental tuvo éxito; el vault tiene el snapshot nuevo. Las flags importan:
-u recibe sin montar; -F puede rollback—úsalo solo cuando comprendas plenamente las consecuencias en el objetivo.
Decisión: Si necesitas -F regularmente, probablemente tengas un problema de higiene de cadena de snapshots. Arregla la eliminación y el nombrado.

Task 13: Medir rendimiento de replicación y detectar ganancias de compresión

cr0x@server:~$ sudo zfs send -nvP tank/prod@auto-20251226-0500 2>&1 | tail -3
send from @auto-20251226-0400 to tank/prod@auto-20251226-0500 estimated size is 17.2G
total estimated size is 17.2G
time        sent   snapshot

Significado: La estimación en seco muestra cuánto pesa el incremental.
Decisión: Si las estimaciones son constantemente enormes, tu carga tiene mucha reescritura. Ajusta la frecuencia de snapshots, excluye datasets con mucho churn o acepta la realidad de capacidad/red.

Task 14: Detectar “snapshots que retienen espacio” causando poco espacio libre

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint vault/backups/prod
NAME               USED  AVAIL  REFER  MOUNTPOINT
vault/backups/prod  38T   1.2T  1.4T   /vault/backups/prod

Significado: El dataset está cerca de capacidad (AVAIL pequeño). El rendimiento y las asignaciones pueden verse afectados.
Decisión: No “soluciones” esto borrando snapshots al azar. Aplica la política de retención, añade capacidad o mueve niveles fuera del pool.

Task 15: Comprobar sorpresas de reservation y refreservation

cr0x@server:~$ zfs get -H -o property,value reservation,refreservation vault/backups/prod
reservation	none
refreservation	none

Significado: No hay espacio reservado artificialmente.
Decisión: Si encuentras reservaciones grandes en un objetivo de backup, confirma que son intencionales. Las reservaciones pueden dejar sin espacio a otros datasets y provocar eliminaciones desesperadas.

Task 16: Verificar que realmente puedes restaurar (clonar un snapshot)

cr0x@server:~$ sudo zfs clone vault/backups/prod@auto-20251226-0500 vault/restore/prod-test
cr0x@server:~$ zfs list -o name,mountpoint,readonly vault/restore/prod-test
NAME                    MOUNTPOINT              READONLY
vault/restore/prod-test  /vault/restore/prod-test  off

Significado: Puedes materializar una vista punto en el tiempo para pruebas de restauración. Los clones son escribibles por defecto.
Decisión: Los flujos de restauración deben operar sobre clones, no sobre el dataset inmutable. Mantén el dataset del vault readonly; haz restauraciones por separado.

Guía de diagnóstico rápido: encuentre el cuello de botella primero, no al final

Cuando los backups se atrasan, a los equipos les encanta pelear sobre “red” vs “almacenamiento” vs “ZFS lento”. No discutas. Mide en orden.

Primero: ¿el pool está sano y no muriendo?

• Ejecuta zpool status. Si tienes errores READ/WRITE/CKSUM, tienes un incidente de fiabilidad, no un problema de ajuste.
• Comprueba si hay un scrub en ejecución. Scrub + replicación puede aplastar I/O en pools pequeños.

Segundo: ¿la capacidad es la restricción oculta?

• Revisa zfs list y el espacio libre del pool. Pools muy llenos fragmentan y se vuelven lentos, y la eliminación de snapshots puede convertirse en “la única solución” a la que la gente recurre.
• Inspecciona qué snapshots retienen espacio (zfs list -t snapshot -o used).

Tercero: ¿la replicación está bloqueada por el estado de la cadena de snapshots?

• Confirma que las snapshots base existen en ambos lados.
• Busca errores “cannot receive incremental stream” en logs de trabajos; suele significar snapshots faltantes o historial divergente.

Cuarto: ¿es I/O, CPU o red?

• Si los sends son estimados grandes, la carga tiene mucho churn. Ningún ajuste convertirá “17G por hora” en “200M por hora”.
• Si usas cifrado o compresión en el stream, la CPU puede ser relevante. Perfila antes de cambiar ajustes.
• Si el vault está en discos más lentos que producción (común), los receives quedarán atrás. No es un bug; es tu arquitectura pidiendo paciencia.

Quinto: ¿te disparas en el pie con propiedades?

• Revisa sync, recordsize y compression en datasets del vault. No cargo-cultes ajustes de producción en backups.
• Tener cuidado con atime en datasets de backup; puede generar escrituras de metadatos inútiles si algo escanea el árbol.

Errores comunes: síntomas → causa raíz → corrección

Mistake 1: “Readonly significa inmutable”

Síntomas: Snapshots desaparecen durante un incidente; el dataset sigue readonly.

Causa raíz: Alguien con privilegios ZFS destruyó snapshots/datasets; readonly no lo detiene.

Corrección: Usa holds para niveles de retención, quita destroy de roles de replicación/operador y aisla el límite administrativo del vault.

Mistake 2: La replicación “falla” pero las restauraciones pierden datos

Síntomas: El objetivo tiene snapshots, pero los datos de la aplicación son inconsistentes o faltan archivos esperados recientes.

Causa raíz: El tiempo de snapshots no coincide con la consistencia de la app, o replicaste el subtree de dataset equivocado.

Corrección: Haz snapshots del dataset(s) correctos, coordina con quiesce de la app si es necesario, valida restauraciones con comprobaciones automatizadas y mantén un dataset de prueba de restauración.

Mistake 3: Reenvíos completos cada semana

Síntomas: El receive incremental falla; los trabajos recurren a full sends; la red se ve asediada.

Causa raíz: Snapshot base borrada en un lado, o el objetivo divergió por snapshots locales/cambios y rollbacks forzados.

Corrección: Protege snapshots base con holds, estandariza nombres, evita escrituras locales en datasets recibidos y deja de usar -F como modo de vida.

Mistake 4: El pool llega al 95% y todo se vuelve “ZFS lento”

Síntomas: Retraso en replicación, alta latencia, ENOSPC ocasional, eliminaciones de snapshots que tardan una eternidad.

Causa raíz: Planificación de capacidad ignoró crecimiento de snapshots; retención demasiado agresiva para el pool.

Corrección: Reduce retención por niveles, excluye datasets de alto churn, añade capacidad o mueve la retención a un pool de clase diferente.

Mistake 5: Dataset de backup montado y escaneado por antivirus/indexers

Síntomas: I/O de metadatos inesperado, receives se ralentizan, carga del host de backup se dispara.

Causa raíz: Datasets del vault montados y tratados como sistemas activos; los scanners tocan todo.

Corrección: Recibe con -u, mantén datasets del vault desmontados por defecto, monta solo para restauraciones e aísla clones de restauración.

Mistake 6: Existen holds pero la retención no funciona

Síntomas: Snapshots se acumulan para siempre; el pool se llena; nadie puede borrar nada.

Causa raíz: Holds aplicados sin ciclo de vida; no hay liberación automatizada tras la ventana de retención.

Corrección: Implementa tags de hold por nivel (ej., policy) y crea un proceso controlado para liberar holds cuando los snapshots salgan de ventana.

Mistake 7: “Replicamos, así que estamos seguros”

Síntomas: Tanto origen como vault contienen datos cifrados/corruptos tras una comprometida.

Causa raíz: La replicación copió fielmente cambios malos rápidamente; no hubo retraso, detección ni tier offline.

Corrección: Añade replicación demorada, niveles de retención más largos, detección de anomalías (churn inesperado) y una segunda copia con un límite de confianza separado.

Tres mini-historias corporativas desde las trincheras de backup

1) Incidente causado por una suposición errónea: “Readonly es inmutable”

Una empresa SaaS de tamaño medio ejecutaba ZFS tanto en producción como en un servidor de backup. Los datasets de backup tenían readonly=on y todos se sentían seguros.
Incluso tenían una diapositiva en la revisión trimestral de riesgos: “copias inmutables habilitadas.”

Entonces una cuenta privilegiada fue comprometida. El atacante no se molestó en cifrar el dataset del vault. Simplemente borró los snapshots, porque borrar es más rápido que cifrar.
Producción fue afectada después y el equipo descubrió que su ventana de retención ahora era “desde que llegó el atacante.”

El postmortem fue incómodo de la mejor manera: nadie mintió, pero varias personas admitieron que asumieron que readonly implicaba no eliminable.
No es así. ZFS es preciso; los humanos no.

La remediación fue igual de precisa: holds de snapshot en el vault para niveles de retención, permisos delegados para que los usuarios de replicación no pudieran destruir nada,
y una cuenta break-glass separada con registro de auditoría y MFA. También decidieron: los hosts de backup no se unen al mismo dominio de identidad que producción.

2) Optimización que salió mal: “Ahorramos espacio podando agresivamente”

Un equipo de una gran empresa estaba bajo presión para reducir costes de almacenamiento. Reducieron mucho la retención de snapshots en el vault y además activaron un script de “limpieza”
que eliminaba snapshots más allá de cierto conteo, no por antigüedad. El script era rápido y las gráficas se veían bien. Por un tiempo.

Luego surgió un problema de corrupción de datos de bajo ritmo en una aplicación. No era obvio: unos registros estaban mal, luego más, luego la app hizo “correcciones útiles”
que en realidad empeoraban el dataset. Cuando alguien lo notó, el único punto de restauración limpio era más antiguo que la nueva ventana de retención.

Lo interesante: ZFS no tuvo la culpa. Su optimización eliminó lo único que puede salvarte de fallos lentos: el tiempo.
El ransomware es ruidoso. La corrupción y la lógica mala son silenciosas.

Revirtieron el cambio de retención, pero no a los números antiguos. Hicieron algo más responsable: retención por niveles con un pequeño conjunto de snapshots “gold” de larga vida
que se mantuvieron con holds, además de pruebas periódicas de restauración. Los costes subieron modestamente. La confianza en recuperación subió muchísimo.

3) Práctica aburrida pero correcta que salvó el día: simulacros rutinarios de restauración

Un equipo de servicios financieros hacía simulacros de restauración semanales. Cada viernes, alguien clonaba un snapshot del vault en un sandbox de restauración y ejecutaba una pequeña suite de comprobaciones:
conteo de archivos, comprobaciones de sanidad a nivel de aplicación y una lectura de integridad rápida en algunos archivos representativos.

No era glamuroso. La gente se quejaba de que tomaba tiempo. La dirección lo financiaba porque creaba un artefacto simple: un ticket que decía “restauración probada desde snapshot X.”
Ese ticket era evidencia aburrida y repetible.

Cuando los golpeó un incidente de robo de credenciales, el atacante intentó borrar snapshots y topó con holds. Luego intentó manipular el dataset montado y topó con readonly.
Mientras tanto, el equipo ya sabía qué snapshot restaurar porque lo habían probado recientemente. Restauraron limpiamente y siguieron adelante.

La lección no fue “teníamos mejor tecnología.” Fue “hicimos el trabajo aburrido.” En operaciones, el trabajo aburrido es cómo compras sueño.

Listas de verificación / plan paso a paso

Paso a paso: construir un vault ZFS “algo inmutable” con valores saneados

1. Define datasets y límites.
   Los datasets de producción son escribibles; los datasets del vault son solo receive y readonly.
2. Implementa cadencia de snapshots en origen.
   Mantén nombres consistentes. Asegura que las snapshots cubran tu RPO.
3. Replica al vault.
   Prefiere replicación explícita basada en snapshots. Evita flujos que requieran -F frecuente.
4. Configura datasets del vault readonly y, idealmente, desmontados por defecto.
   Monta clones de restauración en su lugar.
5. Aplica holds en snapshots del vault según niveles de retención.
   Usa una etiqueta como policy para que sea buscable y consistente.
6. Delegar permisos ZFS.
   Cuenta de replicación: receive, no destroy. Operadores: acciones de restauración, no anulaciones de retención.
7. Programa scrubs y monitoriza errores.
   Los scrubs sirven para detectar errores latentes antes de que se conviertan en bloques faltantes durante una restauración.
8. Planifica capacidad con margen.
   No ejecutes el pool del vault cerca del lleno. La retención de snapshots necesita holgura.
9. Prueba restauraciones rutinariamente.
   Clona un snapshot, móntalo, valida y registra el resultado.
10. Practica el break-glass.
    Define quién puede liberar holds, cómo se audita y cómo evitar la cultura de “todos son root” en el vault.

Lista operacional: antes de reclamar “copias inmutables”

• ¿Puede una cuenta no breakglass destruir snapshots del vault? Si sí, no eres inmutable.
• ¿Se aplican y son visibles los holds? Si no, confías en que los humanos se comporten bajo estrés.
• ¿Está el vault montado y escribible en algún sitio? Si sí, espera que intentos de cifrado tengan éxito.
• ¿Tienes al menos una copia fuera del dominio de confianza primario? Si no, estás a un admin de dominio comprometido de dolor.
• ¿Has restaurado desde el vault en los últimos 30 días? Si no, tienes creencias, no backups.

Preguntas frecuentes

¿Un snapshot ZFS es realmente inmutable?

Su contenido es inmutable (copy-on-write), pero el objeto snapshot puede ser destruido por alguien con los privilegios adecuados.
Si necesitas “no puede ser eliminado”, usa holds y restringe destroy.

¿Readonly=on detiene el ransomware?

Detiene el cifrado directo de sistemas de archivos montados. No detiene la eliminación de snapshots, la destrucción del pool o a un atacante privilegiado.
Usa readonly como una capa, no como línea de meta.

¿Debo tomar snapshots en el vault o en el origen?

Por defecto, haz snapshots en el origen y retención en el vault. Snapshots en el vault pueden ser útiles para niveles adicionales, pero añaden complejidad y pueden confundir restauraciones.

¿Cuál es la forma más segura de restaurar sin debilitar la inmutabilidad?

Clona el snapshot a un dataset de restauración separado y móntalo. Mantén el dataset recibido del vault readonly y, idealmente, desmontado.

¿Cómo interactúan los holds con las políticas de retención?

Los holds bloquean la eliminación hasta que se liberen. Un sistema de retención debería aplicar holds para snapshots dentro de la ventana de retención y liberarlos cuando caduquen,
para luego eliminar snapshots de forma limpia.

¿Los usuarios de replicación pueden restringirse solo a recibir?

Sí. Usa zfs allow para delegar solo lo necesario (típicamente receive, quizá create) y evita conceder destroy.
Luego verifica con la salida de zfs allow.

¿Por qué a veces la replicación requiere un reenvío completo?

Los streams incrementales requieren una snapshot base común. Si la base falta en cualquiera de los lados o el historial del objetivo divergió, el receive incremental falla y se requiere un full send.
Protege las snapshots base y deja de borrar snapshots a la ligera.

¿Cuántos snapshots son “demasiados”?

Depende de la carga y las herramientas. ZFS puede manejar muchos snapshots, pero las herramientas administrativas, trabajos de replicación y humanos pueden sufrir.
Mantén niveles razonables y poda con política, no con pánico.

¿Cuál es el indicador único de que mi vault de backup está poco saludable?

Errores de checksum persistentes o scrubs que reparan repetidamente. ZFS te está diciendo que la integridad de datos está comprometida.
Trátalo como urgente: investiga hardware, firmware, cableado y memoria.

¿Sigue siendo necesario offsite si mi vault es “inmutable”?

Sí. La inmutabilidad trata sobre manipulación y eliminación, no sobre pérdida de sitio, robo o desastres.
Quieres al menos una copia en un dominio de fallos distinto.

Conclusión: pasos siguientes que puedes hacer esta semana

Si quieres copias inmutables con ZFS que aguanten bajo presión, deja de buscar un único control y empieza a superponer defensas:
readonly para escrituras, holds para resistencia a eliminación, delegación para reducir el radio de daño y replicación que no dependa de heroísmos.

1. En el vault, ajusta datasets recibidos readonly=on y recibe con -u para que no se monten casualmente.
2. Implementa holds para snapshots dentro de tu ventana de retención y demuestra que no puedes destruir snapshots con holds.
3. Quita destroy de cuentas de replicación y de operadores; resérvalo para un rol break-glass con auditoría.
4. Haz un simulacro de restauración: clona un snapshot, móntalo y valida algo significativo (no solo “montó”).
5. Revisa la salud del pool y la programación de scrubs tanto en origen como en vault. Si la integridad está tambaleante, la inmutabilidad es académica.

Haz esas cinco cosas y tu postura de backup pasará de “esperanza y capturas de pantalla” a “medida y sobrevivible.” Ese es el juego completo.