ZFS snapdir=visible: Auditar instantáneas sin enfadar a los usuarios

Hay un tipo particular de pánico que golpea a una organización cuando alguien dice: «Necesitamos auditar los archivos tal y como estaban el martes pasado», y el equipo de almacenamiento responde, «Claro, pero solo root puede ver las instantáneas». No es tanto una limitación técnica como una elección de política—y como la mayoría de decisiones de política en almacenamiento, se convierte en un problema de UX en el momento en que los usuarios están involucrados.

snapdir=visible es uno de esos interruptores aparentemente pequeños de ZFS que cambia la forma en que la gente interactúa con un sistema de ficheros. Hecho correctamente, convierte la forense de instantáneas en una experiencia autoservicio y evita que tu on-call se convierta en una API humana de restauración de archivos. Hecho mal, se transforma en la «carpeta misteriosa» más confusa del mundo, rompe expectativas en clientes SMB/NFS y genera la clase de avalancha de tickets que te hace plantearte dedicarte a la agricultura.

Qué hace realmente snapdir (y qué no hace)

Las instantáneas de ZFS no son «copias de seguridad» en el sentido clásico de un servidor de ficheros. Son vistas de solo lectura y en un punto en el tiempo de un dataset. Internamente son referencias de metadatos a bloques que ya existen; ZFS usa copy-on-write, así que los bloques referenciados por instantáneas se conservan hasta que ninguna instantánea (ni ningún fichero vivo) los referencia más.

La propiedad del dataset snapdir controla cómo se exponen las instantáneas a través del espacio de nombres del sistema de ficheros. Específicamente:

• snapdir=hidden (valor por defecto en muchos entornos): el directorio .zfs existe conceptualmente pero no es visible en listados de directorios.
• snapdir=visible: el directorio .zfs aparece en la raíz del punto de montaje del dataset, típicamente como /.zfs dentro de ese dataset, con un subdirectorio snapshot que contiene cada instantánea como un árbol de directorios navegable.

Lo que no hace: no concede permisos. No sobreescribe bits de modo POSIX, ACLs o reglas de compartición SMB. No convierte mágicamente el contenido de las instantáneas en escribible. Tampoco transforma las instantáneas en datasets independientes que puedas montar donde quieras. Esto importa porque muchas expectativas tipo «los usuarios ahora pueden ver instantáneas» se derrumban en «los usuarios pueden ver nombres de instantáneas pero no los archivos que quieren», lo cual empodera menos y genera más enfado.

Dos sentencias de sabiduría desde producción: visibilidad no es acceso, y acceso sin una historia es caos. Si activas la visibilidad sin explicar qué deben hacer los usuarios con ello, lo explorarán como un niño en una sala de servidores: con curiosidad y sin sentido de las consecuencias.

Por qué mostrar las instantáneas

El argumento de venta es simple: auditorías más rápidas y menos restauraciones. La realidad es matizada: cambia la forma de la respuesta a incidentes y desplaza parte de la complejidad de los SRE hacia los usuarios. Eso puede ser una victoria—siempre que lo limites con valores por defecto sensatos, formación y salvaguardas.

Casos de uso donde snapdir=visible destaca

• Revisiones de auditoría y cumplimiento: «Muéstrame cómo estaba esta carpeta el día 1». Los usuarios pueden navegar instantáneas para verificar presencia/ausencia de artefactos sin abrir un ticket.
• Recuperación autoservicio: recuperar un archivo borrado pasa a ser copiar desde una instantánea, no «esperar al equipo de almacenamiento».
• Comparación forense: comparar dos puntos en el tiempo por deriva de configuración o manipulación de datos. Las instantáneas de ZFS te dan una vista consistente.
• Reducir el radio de impacto de una restauración: los usuarios pueden restaurar solo lo que necesitan, en vez de solicitar un retroceso amplio (que es el equivalente de arreglar un reloj con una maza).

Casos de uso donde causa problemas

• Datasets compartidos con permisos desordenados: los usuarios ven árboles de instantáneas pero no pueden leer la mayoría por las ACLs. Esto genera tickets de «copias de seguridad rotas».
• Comportamientos extraños en clientes SMB/NFS: algunos clientes tratan los directorios que empiezan por punto como ocultos; otros no. Indexadores y herramientas de backup pueden recorrerlos inesperadamente.
• Entornos multiinquilino: exponer nombres de instantáneas puede filtrar información (nombres de proyectos, fechas de incidentes, políticas de retención) aunque el acceso a los datos esté bloqueado.

Broma #1: Hacer visibles las instantáneas sin un plan es como esconder las llaves de repuesto bajo el felpudo y luego sorprenderse cuando todo el mundo mira allí.

Cómo se comporta el directorio .zfs en la práctica

Cuando configuras snapdir=visible en un dataset, ZFS expone un directorio especial en la raíz de ese dataset: .zfs. Bajo él normalmente obtienes:

• .zfs/snapshot/ — directorios con nombres de cada instantánea, cada uno conteniendo un árbol completo del sistema de ficheros tal como estaba en el momento de la instantánea.

Algunos comportamientos relevantes operativamente:

• El árbol de la instantánea es de solo lectura. Los usuarios pueden copiar desde él, pero no modificar dentro del árbol.
• Los permisos se evalúan igual que en el dataset activo. Si un usuario no podía leer /data/hr/payroll.xlsx ayer, tampoco podrá leerlo en .zfs/snapshot/yesterday/data/hr/payroll.xlsx.
• Es por dataset. Si tienes datasets anidados, cada dataset tiene su propia vista .zfs. Esto puede confundir cuando los usuarios atraviesan puntos de montaje y de repente ven listas de instantáneas diferentes.
• No es un directorio normal. Algunas herramientas lo tratan de forma extraña: comportamiento de recursión, números de inode y semánticas de recorrido pueden sorprender a utilidades antiguas.

También hay un comportamiento social sutil: cuando los usuarios descubren .zfs/snapshot, empiezan a tratarlo como una «máquina del tiempo». Está bien—hasta que la retención expira y la «máquina del tiempo» se queda sin combustible. Si quieres menos correos enfadados, comunica la retención como una característica del producto («mantenemos 30 instantáneas diarias») en lugar de como una propiedad mágica del universo.

Hechos y contexto histórico que conviene saber

Un poco de contexto ayuda a tomar mejores decisiones. Aquí tienes una serie de hechos concretos que repetidamente importan en despliegues reales:

1. Crear instantáneas es barato porque mayormente solo registran metadatos; el gran coste aparece más tarde cuando las instantáneas mantienen bloques antiguos vivos.
2. Copy-on-write es la razón por la que funcionan las instantáneas: ZFS nunca sobrescribe en el lugar; los cambios escriben bloques nuevos y las instantáneas mantienen referencias a los bloques antiguos.
3. El directorio .zfs es sintético: no se almacena como ficheros normales; es una vista virtual proporcionada por ZFS.
4. La visibilidad fue diseñada para flujos de trabajo administrativos y más tarde se convirtió en un mecanismo de recuperación autoservicio en muchas organizaciones—a menudo sin un plan formal de UX.
5. «Fugar nombres de instantáneas» es algo real: aunque los datos estén protegidos, los nombres pueden revelar nombres en clave de proyectos, fechas de incidentes o pistas relacionadas con RR. HH. si los incluyes en los nombres.
6. Las instantáneas recursivas pueden crear una ilusión de completitud: instantanear un dataset padre no incluye automáticamente a todos los datasets hijos a menos que lo hagas explícitamente o uses flags recursivos.
7. SMB “Previous Versions” es una función separada de snapdir=visible; puedes soportar una, la otra o ambas, y se comportan de forma distinta.
8. Las instantáneas no son copias de seguridad si el pool falla o el ransomware encripta el dataset activo y replicas bloques encriptados. Las instantáneas son una red de seguridad local, no un plan de recuperación ante desastres.
9. La política de retención es política de capacidad: «mantener más instantáneas» es indistinguible de «comprar más disco», solo que con menos reuniones de compras.

Tres mini-historias del mundo corporativo (dolor, ironía, salvación)

1) Incidente causado por una suposición errónea: «Visible significa recuperable»

Un gran recurso compartido interno tenía borrados frecuentes tipo «ups». El equipo de almacenamiento activó snapdir=visible para reducir tickets de restauración. En un día, la cola de helpdesk mejoró—hasta que un analista de cumplimiento intentó recuperar un fichero de una instantánea y obtuvo «Permiso denegado». Escalaron, asumiendo que las instantáneas eran «archivos de respaldo» y por tanto accesibles a los auditores por diseño.

La suposición equivocada era sutil: el rol del analista concedía acceso de lectura a algunos informes vía una capa de aplicación, no vía permisos del sistema de ficheros. En el mundo activo, la app mediaba el acceso. En el mundo de la instantánea, el usuario consultaba directamente los permisos POSIX y las ACLs, que eran más estrictas. El usuario podía listar nombres de instantáneas pero no podía recorrer directorios clave.

El incidente se volvió político porque parecía que almacenamiento había «roto el proceso de auditoría». En realidad, almacenamiento expuso la realidad: el rol de auditor nunca tuvo acceso directo al sistema de ficheros. La solución no fue técnica al principio—fue vocabulario. El equipo escribió una nota interna corta: «Las instantáneas exponen la historia del sistema de ficheros; no elevan privilegios.» Luego añadieron un «grupo de auditores» con ACLs de solo lectura en datasets específicos y crearon un proceso documentado para aprobaciones temporales de acceso.

Tras eso, la ganancia fue real: las auditorías se hicieron más rápidas y el on-call dejó de hacer restauraciones artesanales a las 2 a. m. Pero la lección clave quedó: un toggle de funcionalidad no es un proceso.

2) Optimización que salió mal: «Hagamos todo visible en todas partes»

Un equipo de plataforma decidió estandarizar: todos los datasets tendrían snapdir=visible. Su objetivo era consistencia y menos casos especiales. Lo desplegaron un viernes por la tarde porque el cambio era «solo una propiedad». (Si buscas una señal del universo: esa fue la señal.)

El lunes por la mañana trajo diversión. Un conjunto de agentes indexadores de archivos—desplegados originalmente para acelerar la búsqueda empresarial—empezó a rastrear los árboles .zfs/snapshot. Cada instantánea parecía un universo entero de archivos. Los indexadores no entendían que eran vistas históricas y reindexaron felizmente el mismo contenido docenas de veces entre instantáneas. La CPU en la granja de indexadores subió, el tráfico de red aumentó y el clúster de almacenamiento vio muchas más lecturas de metadatos de lo habitual.

Peor aún, algunos equipos usaban herramientas que tratan cualquier árbol de directorios como contenido candidato a backup. Unos cuantos «scripts de backup caseros» (del tipo que se escribe una vez, nunca se vuelve a probar y se mantiene por superstición) siguieron .zfs y dispararon las ventanas de copia. Nadie quiso admitirlo, pero la «optimización» había creado un impuesto en varios sistemas.

La reversión fue rápida: deshabilitar visibilidad en compartidos amplios y luego reactivar selectivamente donde la recuperación autoservicio importaba y los clientes eran bien comportados. La solución a más largo plazo fue configurar indexadores y herramientas de copia para excluir /.zfs, y crear datasets con intención clara: los compartidos de usuarios obtuvieron una política de exposición de instantáneas curada, mientras que los datasets de máquinas se mantuvieron ocultos.

Broma #2: La forma más rápida de encontrar un rastreador olvidado es darle un laberinto infinito y verlo correr.

3) Una práctica aburrida pero correcta que salvó el día: «Un límite de dataset pequeño y nombres previsibles»

Un equipo de ingeniería almacenaba artefactos de build y paquetes de lanzamiento en ZFS. Eran estrictos con el diseño de datasets: cada línea de producto tenía su propio dataset y los permisos eran consistentes. La nomenclatura de instantáneas seguía un estándar aburrido: auto-YYYYMMDD-HHMM, creadas por hora y podadas diariamente.

Un día, un responsable de lanzamientos descubrió que un binario firmado había desaparecido del directorio «final». El miedo inmediato fue compromiso. Necesitaban responder a dos preguntas: ¿cuándo desapareció y quién tenía acceso? Porque snapdir=visible estaba habilitado en ese dataset, el equipo de lanzamiento pudo navegar instantáneas de inmediato, encontrar la última instantánea donde el archivo existía y estrechar la ventana a una hora concreta.

El equipo de almacenamiento aún intervino, pero ahora la pregunta no fue «por favor restaura todo». Fue «hemos identificado la ventana de desaparición; ¿pueden correlacionarla con logs de auditoría SMB y confirmar que no hubo problema del pool?» Ese es el tipo de ticket que quieres: acotado, basado en evidencia y rápido.

El resultado final fue mundano: un trabajo de automatización tenía un patrón de limpieza demasiado amplio. Pero la investigación evitó el drama porque los límites de dataset eran limpios, los nombres de instantáneas previsibles y la exposición intencional. No fue ingeniería heroica; fue buena higiene que produjo dividendos.

Tareas prácticas: comandos, salidas e interpretación

A continuación tienes tareas reales que puedes ejecutar en producción para implementar, auditar y solucionar problemas de snapdir=visible. Cada una incluye en qué fijarte para que no sea solo spam de comandos.

Task 1: Check current snapdir setting on a dataset

cr0x@server:~$ zfs get -H -o name,property,value,source snapdir tank/projects
tank/projects	snapdir	hidden	default

Interpretación: Está usando el valor por defecto (hidden). Si el origen es local, alguien lo configuró explícitamente; si es inherited, lo controla un dataset padre.

Task 2: Enable snapdir=visible (single dataset)

cr0x@server:~$ sudo zfs set snapdir=visible tank/projects
cr0x@server:~$ zfs get -H snapdir tank/projects
tank/projects	snapdir	visible	local

Interpretación: El dataset mostrará ahora un directorio .zfs en su punto de montaje. Esto no cambia la retención de instantáneas, no crea instantáneas ni altera permisos.

Task 3: Verify .zfs exists and is visible in the mountpoint

cr0x@server:~$ ls -la /tank/projects | head
total 12
drwxr-xr-x  6 root root    6 Dec 24 10:01 .
drwxr-xr-x  4 root root    4 Dec 24 09:58 ..
drwxr-xr-x  2 root root    2 Dec 24 10:01 .zfs
drwxr-xr-x 18 root root   18 Dec 24 09:59 engineering
drwxr-xr-x 11 root root   11 Dec 24 10:00 finance

Interpretación: Si .zfs no está presente, confirma que estás listando el punto de montaje del dataset (no un directorio padre) y que el dataset está montado.

Task 4: List snapshots via ZFS CLI (ground truth)

cr0x@server:~$ zfs list -t snapshot -o name,creation,used,refer,mountpoint -r tank/projects | head
NAME                                   CREATION                USED  REFER  MOUNTPOINT
tank/projects@auto-20251224-0900        Wed Dec 24 09:00 2025   12M   1.20T  -
tank/projects@auto-20251224-1000        Wed Dec 24 10:00 2025   18M   1.21T  -

Interpretación: USED es cuánto espacio único está reteniendo esa instantánea (bloques no referenciados en otro sitio). Si USED crece, la retención tiene un coste directo en capacidad.

Task 5: List snapshots by browsing .zfs

cr0x@server:~$ ls -1 /tank/projects/.zfs/snapshot | head
auto-20251224-0900
auto-20251224-1000

Interpretación: Si la CLI de ZFS muestra instantáneas pero .zfs/snapshot está vacío, probablemente no estás en el dataset que crees (confusión por datasets anidados), o la ruta del cliente cruza un límite de punto de montaje.

Task 6: Copy a deleted file back from a snapshot (safe self-serve restore)

cr0x@server:~$ cp -av /tank/projects/.zfs/snapshot/auto-20251224-0900/engineering/readme.txt \
> /tank/projects/engineering/readme.txt
'/tank/projects/.zfs/snapshot/auto-20251224-0900/engineering/readme.txt' -> '/tank/projects/engineering/readme.txt'

Interpretación: Usa cp (o rsync) para restaurar en el árbol activo. No intentes escribir dentro del árbol de la instantánea; es de solo lectura y fallará.

Task 7: Confirm a user’s ability to traverse snapshot directories

cr0x@server:~$ sudo -u alice ls -la /tank/projects/.zfs/snapshot/auto-20251224-0900/finance
ls: cannot open directory '/tank/projects/.zfs/snapshot/auto-20251224-0900/finance': Permission denied

Interpretación: Esto suele ser el comportamiento correcto. Significa que la instantánea respeta los mismos permisos que el árbol activo. Si los usuarios esperan acceso, necesitas una discusión sobre ACLs/permisos, no un toggle de almacenamiento.

Task 8: Find what’s consuming space due to snapshots (high-level)

cr0x@server:~$ zfs list -o name,used,avail,refer,ratio,mountpoint tank/projects
NAME          USED  AVAIL  REFER  RATIO  MOUNTPOINT
tank/projects 3.41T 2.12T  1.21T  1.68x  /tank/projects

Interpretación: USED incluye bloques retenidos por instantáneas. Si REFER es estable pero USED sube, las instantáneas (o clones) están manteniendo datos antiguos.

Task 9: See snapshot space consumption per snapshot

cr0x@server:~$ zfs list -t snapshot -o name,used,refer -s used -r tank/projects | tail -5
tank/projects@auto-20251220-0900  1.9G  1.08T
tank/projects@auto-20251221-0900  2.3G  1.10T
tank/projects@auto-20251222-0900  3.1G  1.14T
tank/projects@auto-20251223-0900  4.8G  1.18T
tank/projects@auto-20251224-0900   12M  1.20T

Interpretación: Las instantáneas antiguas suelen retener más bloques únicos, especialmente si el dataset tiene churn (imágenes de VM, salidas de build, bases de datos). Unas pocas instantáneas pesadas pueden dominar los costes.

Task 10: Detect “snapshot directory crawlers” using filesystem activity symptoms

cr0x@server:~$ sudo zpool iostat -v tank 2 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        8.10T  2.12T    980    210   118M  22.1M
  raidz2    8.10T  2.12T    980    210   118M  22.1M
    sda         -      -    160     35  19.7M  3.6M
    sdb         -      -    165     36  19.4M  3.7M
    sdc         -      -    162     34  19.6M  3.5M

Interpretación: Un aumento repentino en read IOPS y ancho de banda después de habilitar visibilidad suele apuntar a rastreadores (indexadores, antivirus, scripts de backup) recorriendo árboles de instantáneas.

Task 11: Check dataset mountpoints and nested dataset boundaries (avoids confusion)

cr0x@server:~$ zfs list -o name,mountpoint -r tank/projects
NAME                     MOUNTPOINT
tank/projects            /tank/projects
tank/projects/engineering /tank/projects/engineering
tank/projects/finance    /tank/projects/finance

Interpretación: Cada child dataset tiene su propio namespace de instantáneas y potencialmente su propia configuración snapdir. Los usuarios que crucen a /tank/projects/engineering verán .zfs para ese dataset, no las instantáneas del padre.

Task 12: Set snapdir via inheritance (apply to a subtree)

cr0x@server:~$ sudo zfs set snapdir=visible tank/projects
cr0x@server:~$ zfs get -H -o name,value,source snapdir tank/projects/engineering
tank/projects/engineering	visible	inherited from tank/projects

Interpretación: La herencia es tu amiga para la consistencia, pero también aumenta el radio de impacto. Para compartidos orientados a usuarios, considera ajustes locales explícitos y documenta la intención.

Task 13: Disable visibility (the “stop the bleeding” button)

cr0x@server:~$ sudo zfs set snapdir=hidden tank/projects
cr0x@server:~$ zfs get -H snapdir tank/projects
tank/projects	snapdir	hidden	local

Interpretación: Esto oculta .zfs de los listados de directorios otra vez. No elimina instantáneas; solo quita la superficie de UX.

Task 14: Verify snapshot retention and prune intentionally

cr0x@server:~$ zfs destroy tank/projects@auto-20251220-0900
cr0x@server:~$ zfs list -t snapshot -r tank/projects | grep auto-20251220-0900
cr0x@server:~$ echo $?
1

Interpretación: Eliminar instantáneas libera espacio solo si esos bloques ya no son referenciados por otras instantáneas o clones. Si el espacio no baja, probablemente tengas otras instantáneas reteniendo el mismo churn, o clones fijando bloques.

Task 15: Investigate clones pinning snapshot space

cr0x@server:~$ zfs get -H -o name,value origin -r tank/projects | grep -v '^-$'
tank/projects/engineering/testclone	tank/projects@auto-20251222-0900

Interpretación: Si datasets están clonados desde instantáneas, esas instantáneas (o sus bloques) pueden ser efectivamente indestructibles hasta que los clones se destruyan o promuevan. La visibilidad no causa esto, pero frecuentemente aparece durante auditorías de instantáneas.

Modelo de control de acceso: qué pueden ver y hacer realmente los usuarios

snapdir=visible cambia la descubribilidad, no la autorización. En la mayoría de despliegues POSIX, un usuario necesita:

• Permiso de ejecución (travesía) en cada directorio del camino para alcanzar un fichero en la instantánea.
• Permiso de lectura sobre el fichero para copiarlo fuera.
• Derechos ACL apropiados si usas ACLs NFSv4 o POSIX.

Eso significa que puedes usar visibilidad sin entregar nuevos poderes, pero también significa que los usuarios pueden sentirse «tentados» por nombres de instantáneas que no pueden usar. Un patrón práctico es separar datasets por audiencia:

• Compartidos de usuarios (home directories, compartidos de equipo): considera snapdir=visible más guía explícita sobre autoservicio, con exclusiones configuradas para rastreadores.
• Datasets de máquinas (bases de datos, imágenes VM, caches de CI): mantén snapdir=hidden a menos que tengas una razón fuerte; estos árboles son golosina para rastreadores y suelen tener mucho churn.
• Datasets de auditoría: si los auditores necesitan acceso, concédelo intencionalmente vía ACLs a un grupo de solo lectura; no confíes en «pueden verlo, así que debe estar permitido».

Una nota sobre nombres: los nombres de instantáneas se convierten en UI cuando los expones. Si tus nombres contienen espacios, bromas o nombres en clave de incidentes, básicamente estás escribiendo tu diario interno en la puerta. Usa nombres predecibles y aburridos. Lo aburrido escala.

Rendimiento e impacto operacional

En teoría, exponer .zfs/snapshot es solo un listado de directorios. En la práctica, cambia lo que usuarios y programas hacen, lo que cambia patrones de carga. La mayoría de «problemas de rendimiento» achacados a snapdir=visible son en realidad causados por uno de estos:

• Escaneos recursivos por indexadores, antivirus, agentes de backup o scripts tipo “find / -type f” que ahora incluyen instantáneas.
• Navegación intensiva en metadatos por usuarios que tratan los árboles de instantáneas como archivos de archivo y ejecutan muchos listados de directorio a través de muchas instantáneas.
• Confusión por límites de montado donde los usuarios atraviesan a datasets hijos y provocan conjuntos de instantáneas diferentes, multiplicando la navegación.

Operativamente, planifica para:

• Más lecturas de metadatos (especialmente si los usuarios navegan instantáneas antiguas con árboles de directorios grandes).
• Más presión de caché (ARC) si los árboles de instantáneas se recorren con frecuencia y no caben en memoria.
• Preguntas de soporte sobre «¿qué es esta carpeta .zfs?» y «¿por qué hay tantas copias?»

Un truco pragmático: trata snapdir=visible como un producto orientado a usuarios. Lánzalo con exclusiones (indexadores/backups), con una declaración de retención y con un snippet de «cómo restaurar tu archivo». Ahorrarás más horas que cualquier micro-optimización en recordsize.

Guía rápida de diagnóstico

Cuando alguien dice «las instantáneas van lentas» o «habilitar snapdir causó latencia», no tienes tiempo para debates filosóficos. Aquí tienes un orden rápido de operaciones que encuentra cuellos de botella con rapidez.

First: confirm what changed and where

1. Confirma el dataset y punto de montaje al que acceden los usuarios (los datasets anidados importan).
2. Confirma que snapdir está realmente en visible en ese dataset (y si es heredado).
3. Confirma si la queja es sobre listar nombres de instantáneas o sobre recorrer contenido de instantáneas.

cr0x@server:~$ zfs list -o name,mountpoint -r tank/projects
cr0x@server:~$ zfs get -H -o name,value,source snapdir tank/projects tank/projects/engineering

Second: check pool health and obvious saturation

1. Estado del pool (errores, resilvering) primero. Un pool degradado hace que cualquier función parezca culpable.
2. IOPS y ancho de banda en el pool durante la ventana del incidente.
3. Pistas de latencia: muchas lecturas con bajo throughput suelen indicar una tormenta de metadatos.

cr0x@server:~$ zpool status -x
all pools are healthy
cr0x@server:~$ zpool iostat -v tank 1 5

Third: look for snapshot tree crawlers and metadata storms

1. ¿Hay procesos haciendo recorridos amplios de directorios?
2. ¿Un indexador/AV/agente de backup actualizó su configuración recientemente?
3. ¿El dataset se exporta vía SMB/NFS y está siendo rastreado por clientes?

cr0x@server:~$ ps auxww | egrep 'find |updatedb|locate|rsync|backup|index' | head
cr0x@server:~$ sudo lsof +D /tank/projects/.zfs/snapshot 2>/dev/null | head

Interpretación: lsof +D puede ser costoso en árboles enormes; úsalo con cuidado. Si es demasiado lento, limítalo a una sola instantánea o usa comprobaciones dirigidas basadas en agentes conocidos.

Fourth: validate ARC pressure and memory contention

1. Si ARC está thrashing, las cargas de metadatos duelen más.
2. Confirma que no estás intercambiando; el intercambio convierte a ZFS en una pieza de performance art.

cr0x@server:~$ free -h
cr0x@server:~$ vmstat 1 5

Fifth: decide the mitigation

• Si los rastreadores son la causa: excluye /.zfs a nivel de herramienta y vuelve a probar.
• Si los usuarios hacen navegación pesada legítima: considera ofrecer un host de «restauración» dedicado o un flujo de trabajo documentado, o mantener la visibilidad solo en datasets seleccionados.
• Si el pool está saturado: puedes estar limitado por capacidad u IOPS independientemente de la visibilidad—arregla el pool, no el síntoma.

Errores comunes: síntomas y soluciones

Mistake 1: Enabling visibility on broad shares without excluding crawlers

Síntomas: pico repentino en read IOPS, listados de directorio más lentos, CPU de indexador/AV en aumento, ventanas de backup que explotan.

Solución: vuelve a ocultar snapdir para detener la hemorragia, luego configura exclusiones en los rastreadores para /.zfs. Reactiva selectivamente en datasets donde sea útil.

cr0x@server:~$ sudo zfs set snapdir=hidden tank/projects
cr0x@server:~$ zpool iostat -v tank 2 3

Mistake 2: Assuming snapshots are readable by auditors because they’re visible

Síntomas: quejas de «Permiso denegado», escalado de auditoría, acusaciones de que almacenamiento «retuvo» datos.

Solución: alinea permisos/ACLs del sistema de ficheros con los requisitos de auditoría, o proporciona un flujo de trabajo mediado. Documenta que la visibilidad no eleva privilegios.

cr0x@server:~$ getfacl -p /tank/projects/finance | head -40

Mistake 3: Confusing parent dataset snapshots with child dataset snapshots

Síntomas: usuarios dicen «la instantánea que necesito no está», pero existe en otro sitio; listas de instantáneas inconsistentes según la ruta.

Solución: mapea límites de dataset y puntos de montaje; asegúrate de que la automatización de instantáneas cubre datasets hijos según lo previsto.

cr0x@server:~$ zfs list -o name,mountpoint -r tank/projects
cr0x@server:~$ zfs list -t snapshot -r tank/projects/engineering | head

Mistake 4: Snapshot naming that becomes a security or HR problem

Síntomas: los usuarios pueden inferir eventos sensibles por nombres de instantáneas; preguntas incómodas en auditorías; «¿por qué hay una instantánea llamada layoff-plan?»

Solución: estandariza en nombres neutrales (timestamp + política), guarda el «significado» en tu sistema de cambios, no en los nombres de instantáneas.

cr0x@server:~$ zfs list -t snapshot -o name -r tank/projects | head

Mistake 5: Treating snapshots as a replacement for backups

Síntomas: ausencia de copias fuera de ubicación, ransomware encripta datos activos y las instantáneas caducan o replican el estado encriptado, pérdida del pool es catastrófica.

Solución: mantén las instantáneas como rollback local; usa replicación y dominios de retención separados para copias de seguridad reales (y prueba las restauraciones).

cr0x@server:~$ zfs list -t snapshot -r tank | wc -l

Mistake 6: Letting snapshot retention drift until the pool is full

Síntomas: el pool alcanza alta asignación, el rendimiento se degrada, los borrados no liberan espacio «como antes», purga de instantáneas en emergencia.

Solución: monitoriza crecimiento de instantáneas, podar con intención y entiende los clones. Considera quota/refquota para limitar el daño por dataset.

cr0x@server:~$ zpool list
cr0x@server:~$ zfs list -o name,used,refer,avail -r tank/projects

Listas de comprobación / plan paso a paso

Checklist A: Safe rollout of snapdir=visible on a user share

1. Elige el/los dataset(s) intencionalmente. Prefiere compartidos de equipo o directorios home con permisos estables.
2. Confirma que existe automatización de instantáneas (horaria/diaria) y que la retención está documentada.
3. Estandariza nombres de instantáneas para que sean previsibles y aburridos.
4. Inventario de rastreadores: indexadores, antivirus, agentes de backup, analítica de archivos, herramientas de búsqueda. Planifica exclusiones para /.zfs.
5. Habilita visibilidad en un piloto (un dataset, un equipo).
6. Mide el impacto: iostat del pool, experiencia del cliente, tipos de tickets.
7. Publica una guía de autoservicio de dos minutos («copiar desde .zfs/snapshot/<snap>/ruta»).
8. Expande gradualmente, con un plan de reversión (snapdir=hidden).

Checklist B: Self-serve restore workflow (user-friendly, low-risk)

1. Encuentra el punto de montaje correcto del dataset (evita confusión por datasets anidados).
2. Navega .zfs/snapshot por la ventana temporal.
3. Localiza el archivo en el árbol de instantáneas.
4. Cópialo de vuelta al espacio activo con un nombre nuevo primero (seguridad).
5. Verifica el contenido y luego reemplaza el original si es necesario.

cr0x@server:~$ ls /tank/projects/.zfs/snapshot | tail -5
cr0x@server:~$ cp -av /tank/projects/.zfs/snapshot/auto-20251224-0900/engineering/spec.docx \
> /tank/projects/engineering/spec.docx.restored
cr0x@server:~$ ls -l /tank/projects/engineering/spec.docx*

Checklist C: Audit workflow (prove “what existed when”)

1. Identifica dataset y ruta relevante.
2. Encuentra la instantánea más cercana al momento de interés (zfs list -t snapshot).
3. Comprueba existencia y metadatos en la vista de instantánea.
4. Si es necesario, hashea el fichero de la instantánea y la copia restaurada para mostrar integridad (hashear es una decisión operacional; puede ser costoso).
5. Registra el nombre de la instantánea y la hora de creación como ancla de evidencia.

cr0x@server:~$ zfs list -t snapshot -o name,creation -r tank/projects | tail -5
cr0x@server:~$ ls -l /tank/projects/.zfs/snapshot/auto-20251224-0900/finance/ledger.csv
cr0x@server:~$ sha256sum /tank/projects/.zfs/snapshot/auto-20251224-0900/finance/ledger.csv

Preguntas frecuentes

1) ¿Hace snapdir=visible que las instantáneas sean accesibles para todo el mundo?

No. Hace visible el directorio de instantáneas en los listados. El acceso al contenido de las instantáneas sigue dependiendo de permisos del sistema de ficheros y ACLs.

2) ¿Su activación ralentizará mi pool?

No directamente. El riesgo es de comportamiento: una vez visibles, herramientas y usuarios pueden recorrerlas, causando lecturas de metadatos y carga aumentada. Si excluyes rastreadores y lo aplicas selectivamente, el impacto suele ser modesto.

3) ¿Por qué los usuarios pueden listar nombres de instantáneas pero no abrir carpetas dentro de ellas?

Porque listar .zfs/snapshot puede estar permitido mientras que la travesía dentro de directorios protegidos está bloqueada por permisos de ejecución de directorio o ACLs. Esto es común en datasets con permisos mixtos.

4) ¿Cómo oculto las instantáneas otra vez sin borrar nada?

Configura snapdir=hidden en el dataset. Las instantáneas permanecen; simplemente dejan de aparecer vía .zfs.

cr0x@server:~$ sudo zfs set snapdir=hidden tank/projects

5) ¿Está .zfs presente también en datasets hijos?

Sí, cada dataset tiene su propio namespace de instantáneas y reglas de herencia de propiedades. Los datasets anidados son una fuente frecuente de confusión sobre «listas de instantáneas equivocadas».

6) ¿Pueden los usuarios borrar o modificar archivos dentro de las instantáneas?

No. El contenido de las instantáneas es de solo lectura. Los usuarios pueden copiar datos al sistema de ficheros activo si tienen permiso para escribir allí.

7) ¿Es esto lo mismo que “Previous Versions” en compartidos Windows?

No. «Previous Versions» en Windows suele implementarse por el servidor SMB mapeando instantáneas en esa UI. snapdir=visible expone instantáneas vía un directorio del sistema de ficheros. Puedes usar una, la otra o ambas; prueba el comportamiento del cliente cuidadosamente.

8) Si borro una instantánea, ¿recibiré el espacio inmediatamente?

No siempre. El espacio se libera solo cuando los bloques ya no son referenciados por ninguna instantánea, clone o el sistema de ficheros activo. Los clones son una razón común por la que la eliminación no recupera espacio.

9) ¿Cuál es la forma más segura de permitir que los usuarios restauren archivos sin darles demasiada cuerda?

Activa la visibilidad solo en datasets diseñados para navegación por usuarios, mantiene los nombres de instantáneas previsibles, publica un flujo de restauración y asegúrate de que los rastreadores excluyen /.zfs. Combínalo con quotas/refquotas para limitar el crecimiento en el peor caso.

Conclusión

snapdir=visible es un movimiento clásico de ZFS: una propiedad que convierte un primitivo de almacenamiento en una característica orientada a usuarios. La ingeniería es sólida, pero el resultado depende de cómo se comporten las personas y el software una vez que la puerta está abierta.

Si tratas la visibilidad de instantáneas como un producto—despliegue limitado, retención clara, nombres sensatos, exclusiones para rastreadores y un flujo de restauración documentado—obtendrás auditorías más rápidas, menos tickets de restauración y menos drama a medianoche. Si lo activas en todas partes y te olvidas, aprenderás qué herramientas en tu entorno están secretamente alimentadas por la recursión. En almacenamiento, los datos son predecibles; son los usuarios y sus scripts los que mantienen las cosas emocionantes.