zfs diff es uno de esos comandos que no uso todos los días, pero cuando lo necesito me evita una tarde de mirar carpetas como si estuviera buscando al culpable en una película mala. Sirve para comparar un snapshot con el estado actual de un dataset, o dos snapshots entre sí, y ver qué archivos se han añadido, cambiado, renombrado o borrado.
En Proxmox lo uso sobre todo con datasets de verdad. Datasets de backups, plantillas, ISO, contenedores o carpetas que viven en ZFS como sistema de archivos. No lo vendo como solución universal porque no lo es. Si estás mirando un disco de VM como zvol, no esperes que te diga “ha cambiado este fichero dentro de Debian”. ZFS ve bloques, no entra en el sistema de archivos invitado como un duende con linterna.
Pero cuando el dataset sí contiene archivos visibles, zfs diff es muy cómodo. Me da una lectura rápida antes de borrar snapshots, antes de hacer rollback y, sobre todo, antes de culpar a la aplicación equivocada.
El patrón básico que uso es este.
| |
Eso compara el snapshot con el estado actual del dataset.
También puedo comparar dos snapshots.
| |
La salida parece seca, pero se lee bastante bien cuando entiendes los símbolos.
la captura de este post#
La captura usa una salida saneada de un dataset de ejemplo en Proxmox. No hay IPs, nombres reales ni rutas privadas. La idea es enseñar cómo leo yo el cambio entre dos momentos.
Esta es la salida saneada que usé para generar la captura:
| |
No necesito más para orientarme. Hay un fichero modificado, uno añadido, uno eliminado y uno renombrado. Si yo había hecho una limpieza de plantillas, la salida encaja. Si no había tocado nada, entonces tengo una pista bastante clara de que algo o alguien sí lo hizo.
qué significan las letras#
La primera columna es lo que más miro.
| |
M significa que el archivo existía antes y existe ahora, pero su contenido o metadatos han cambiado. No siempre implica un cambio enorme. A veces basta con permisos, propietario o timestamps.
+ significa que aparece en el segundo punto de comparación y no estaba en el primero. Esto es muy útil cuando un script deja basura temporal o cuando una aplicación genera archivos nuevos sin avisar.
- significa que estaba antes y ya no está. Si estoy revisando una limpieza manual, perfecto. Si aparece sin que nadie recuerde haber borrado nada, ahí ya levanto una ceja.
R significa rename. Es especialmente cómodo porque me evita interpretar un borrado y un añadido como si fueran dos acciones distintas cuando en realidad el fichero solo se movió.
No es una auditoría legal. No me dice quién lo hizo. Para eso tendría que combinarlo con logs, zpool history, historial de shell, tareas de Proxmox o lo que toque. Pero sí me dice qué ha cambiado entre dos puntos.
por qué lo uso antes de borrar snapshots#
Una mala costumbre muy humana es mirar snapshots antiguos, ver que ocupan algo de espacio y pensar “esto ya no vale para nada”. Luego lo borras y justo después descubres que ese snapshot era el único sitio donde quedaba una versión buena de algo.
Con zfs diff puedo hacer una comprobación rápida.
| |
Si la salida es pequeña y reconocible, normalmente sigo adelante. Si veo un montón de cambios que no esperaba, paro. No porque el comando me lo ordene, sino porque me acaba de enseñar que mi memoria era peor que el sistema de archivos. Suele pasar.
También lo combino con zfs list -t snapshot para ver cuánto espacio retiene cada snapshot.
| |
La columna USED no significa “tamaño completo del snapshot”. Significa cuánto espacio se liberaría si eliminas ese snapshot, teniendo en cuenta referencias compartidas con otros snapshots. Esto confunde a mucha gente al principio. A mí también me confundió.
Si zfs diff muestra pocos cambios y USED es pequeño, borrar suele tener poco misterio. Si USED es grande y el diff muestra borrados importantes, no lo borro sin entenderlo.
dónde tiene sentido en Proxmox#
En mi caso tiene sentido en datasets tipo filesystem. Por ejemplo, un dataset donde guardo ISOs, plantillas, exports, backups manuales o datos de un contenedor si lo tengo montado de forma visible.
Ejemplos genéricos.
| |
Donde no me parece tan útil es en discos de VM puros. Proxmox suele guardar discos ZFS como volúmenes. Ahí el sistema de archivos está dentro de la VM. ZFS puede hacer snapshot del volumen, claro. Puede replicarlo, enviarlo, restaurarlo y protegerlo. Pero zfs diff no va a abrir ext4, xfs o NTFS dentro del invitado para enseñarte cambios de archivos.
Este matiz importa. He visto demasiadas expectativas raras alrededor de ZFS. ZFS es buenísimo, pero no es un forense universal. Si quiero saber qué cambió dentro de una VM, entro en la VM, reviso logs, uso herramientas del sistema invitado o tiro de backups de aplicación.
Para datasets visibles, en cambio, zfs diff va fino.
mi flujo normal antes de tocar un dataset#
Cuando voy a ordenar algo, hago un snapshot con un nombre aburrido y entendible.
| |
No me gustan los nombres crípticos. En un homelab nadie te da puntos por llamar a un snapshot snap_final_v2_ok. Quiero leerlo dentro de tres semanas y entender por qué existe.
Después hago el cambio. Muevo plantillas, limpio temporales, borro un ISO duplicado o ajusto lo que sea.
Luego comparo.
| |
Si veo lo esperado, perfecto. Si no, puedo decidir si mantengo el snapshot unos días o si vuelvo atrás con calma. Lo importante es que ya no estoy operando a ojo.
Cuando quiero dejar otro punto limpio después del cambio, creo un segundo snapshot.
| |
Eso me gusta especialmente cuando estoy documentando una intervención. El primer snapshot marca el antes. El segundo marca el después. El diff cuenta lo que ha pasado.
cuidado con snapshots enormes#
zfs diff puede tardar si el dataset tiene muchísimos cambios. No suele ser dramático, pero tampoco conviene ejecutarlo esperando una respuesta instantánea en un árbol gigantesco con millones de ficheros.
En datasets de homelab normales va sobrado. En datasets con backups, caches o millones de archivos pequeños, ya voy con más paciencia. Si tarda, no significa que esté roto. Significa que le he pedido comparar mucho estado.
También hay otro detalle. Si el dataset está recibiendo cambios mientras haces el diff, la lectura puede ser menos cómoda. Para revisar algo delicado prefiero un momento de poca actividad, o comparar dos snapshots cerrados en vez de snapshot contra estado vivo.
Por eso me gusta esta forma.
| |
Dos snapshots. Dos puntos quietos. Menos ruido.
no sustituye a zpool history#
zfs diff me dice qué cambió en archivos. zpool history me dice qué comandos administrativos se ejecutaron en el pool. Son herramientas distintas.
Si veo que desapareció un fichero, zfs diff me lo enseña. Si quiero saber si alguien hizo zfs destroy, zfs set o zfs rename, miro zpool history.
Ya escribí sobre zpool history en Proxmox porque me parece una de las mejores formas de reconstruir decisiones de storage. Lo uso mucho cuando algo huele a “esto lo toqué yo, pero no quiero admitirlo todavía”.
También lo cruzo con zfs get cuando sospecho que el problema no es un archivo cambiado, sino una propiedad rara heredada o local.
cuándo no pierdo tiempo con este comando#
No lo uso para todo. Si estoy revisando salud del pool, miro zpool status. Si quiero rendimiento, tiro de zpool iostat. Si quiero propiedades, zfs get o zpool get. Cada herramienta tiene su sitio.
zfs diff entra cuando mi pregunta es concreta: qué cambió entre este momento y aquel.
Si la pregunta es otra, no fuerzo el comando. Parece obvio, pero en homelab es facilísimo convertir una herramienta útil en un martillo para todo. Yo he perdido horas así. Un comando te da una pista, tú te emocionas y acabas intentando resolver DNS con una llave inglesa.
mi conclusión#
zfs diff es pequeño, feo y bastante más útil de lo que parece. No te da contexto humano, no sabe quién hizo el cambio y no mira dentro de discos de VM como si fueran carpetas normales. Pero cuando trabajas con datasets ZFS visibles, te da una respuesta rápida a una pregunta muy práctica.
¿Qué cambió?
Antes de borrar snapshots, antes de hacer rollback o antes de tocar una limpieza que ya no recuerdo bien, prefiero ejecutar un diff y ver la realidad. Mi memoria de administrador de madrugada no es una fuente fiable. ZFS, por suerte, suele ser bastante menos creativo.