Hay comandos que uso para ver cómo está un sistema ahora mismo y comandos que uso para saber qué demonios pasó antes de que todo empezase a oler raro. zpool history es de los segundos.
En Proxmox, cuando ZFS empieza a hacer cosas inesperadas, la tentación es mirar CPU, RAM, discos, SMART, gráficas y cualquier panel que tenga colores. Lo entiendo. Yo también lo hago. Pero hay una pregunta que suele ahorrar mucho tiempo y bastante teatro: ¿alguien tocó algo en el pool?
No hablo solo de romperlo. Hablo de cambiar una propiedad, lanzar un scrub, crear un dataset, destruir un snapshot, mover un disco de una VM, importar un pool, añadir una caché o hacer una prueba rápida que luego nadie recuerda. El homelab tiene esa cosa maravillosa de que el culpable casi siempre eres tú, pero tú de hace tres días, con sueño y demasiada confianza.
Ahí entra zpool history.
| |
No es vistoso. No te da una gráfica bonita. No te va a decir si tu arquitectura vital está alineada con las mejores prácticas del sector, gracias a Dios. Te enseña el historial de operaciones registradas por ZFS sobre el pool. Fechas, comandos y contexto suficiente para saber si algo cambió.
Para mí es una herramienta de memoria. Y en un homelab con Proxmox, memoria hace falta.
la captura de este post#
La captura usa una salida saneada de un nodo Proxmox realista. He cambiado nombres de pool, datasets y máquinas para no enseñar estructura interna. El objetivo es ver el tipo de lectura que hago, no publicar el diario íntimo del storage.
La salida de ejemplo es esta.
| |
Esta salida cuenta una historia corta. Hubo un scrub, se creó un snapshot antes de una actualización, se cambió compresión en un disco de VM, se destruyó el snapshot, se creó un dataset para plantillas, se desactivó atime, se limpió el estado del pool y luego alguien revisó el estado.
No hay drama. Pero si una VM empezó a comportarse raro justo después del cambio de compresión, ya tengo una pista. Si un snapshot que esperaba encontrar ya no está, sé cuándo se destruyó. Si aparece un zpool clear, sé que alguien limpió errores visibles del pool y ahora tengo que mirar con más cuidado.
por qué miro historial antes de inventarme teorías#
Cuando algo va mal en Proxmox, es muy fácil construir una novela. La VM va lenta porque el nodo está cargado. O porque Ceph está raro. O porque el NVMe se está muriendo. O porque el kernel nuevo tiene una regresión. O porque el backup de madrugada dejó el sistema tonto. Todas pueden ser verdad, pero empezar por ahí suele llevarte a una hora de comandos y cara de idiota.
zpool history me baja el ego. Me pone delante acciones concretas.
Si veo esto:
| |
ya no estoy ante un misterio místico del almacenamiento. Estoy ante una decisión peligrosa que alguien tomó para ganar rendimiento o hacer una prueba. Si veo esto:
| |
ya sé que ese snapshot no desapareció por arte de magia. Si veo esto:
| |
y justo después empezaron los problemas, la caché entra en la lista de sospechosos.
La gracia es que el historial no opina. No interpreta. No intenta ayudarte con entusiasmo barato. Te da hechos. En un momento de diagnóstico, eso vale bastante.
qué registra y qué no registra#
zpool history registra operaciones administrativas de ZFS. No es un log completo del sistema. No sustituye a journalctl, no sustituye a SMART, no sustituye a las tareas de Proxmox y no te va a decir qué proceso escribió 80 GB de logs en una noche.
Lo que sí suelo encontrar ahí:
- Creación y destrucción de datasets.
- Snapshots manuales.
- Cambios de propiedades con
zfs set. - Scrubs lanzados manualmente.
- Imports y exports del pool.
- Operaciones de clear.
- Cambios de discos o vdevs.
- Algunos comandos lanzados por herramientas que usan ZFS por debajo.
Y lo que no espero encontrar:
- Cada escritura que hace una VM.
- Cada snapshot gestionado por una herramienta externa si no pasa por comandos registrados de forma visible.
- El motivo humano de un cambio.
- La identidad perfecta de quien lo hizo en todos los entornos.
- Una explicación completa de una degradación de rendimiento.
Esta distinción importa. Si le pides a zpool history que sea un SIEM, te vas a frustrar. Si lo usas como una libreta de cambios de ZFS, funciona muy bien.
mi forma rápida de leerlo#
No suelo lanzar el comando y leer desde el principio como si fuese una novela rusa. Voy a lo reciente.
| |
Con eso tengo una ventana suficiente para la mayoría de sustos. Si el problema empezó hoy, no necesito leer cambios de hace tres meses.
Cuando busco algo concreto, filtro.
| |
Esto me deja las operaciones que más me interesan durante un diagnóstico rápido. Cambios de propiedades, borrados, snapshots, scrubs y limpiezas de errores.
Si sospecho de una VM o dataset concreto, filtro por su nombre saneado.
| |
En Proxmox los discos de VM suelen aparecer como datasets o zvols con nombres bastante reconocibles. No siempre es bonito, pero ayuda.
el caso típico: una VM rara después de una actualización#
Imagina una VM que funcionaba bien, se actualiza por la mañana y por la tarde empieza a ir pesada. La CPU no está alta. La RAM no está llena. El nodo no parece saturado. La web de Proxmox no enseña nada escandaloso.
Lo normal es mirar qm status, qm config, zpool iostat, quizá logs de la VM. Yo añado zpool history pronto.
| |
Si aparece un snapshot pre-upgrade, bien. Alguien tuvo la prudencia mínima. Si aparece un cambio de compression, sync, recordsize, logbias o volblocksize, ya tengo que pensar más. No significa que ese cambio sea malo. Significa que el almacenamiento de esa VM no es el mismo que antes.
Con compression=zstd, por ejemplo, no me asusto. En muchos casos lo prefiero. Pero si la VM mueve una carga extraña, con bloques pequeños y mucha escritura, quiero correlacionarlo con zpool iostat y con el comportamiento real.
Con sync=disabled, sí me pongo más serio. Puede dar rendimiento aparente, pero cambia el perfil de riesgo. En un laboratorio puede tener sentido durante una prueba. En una VM que importa, me parece una forma elegante de fabricar arrepentimiento.
el caso incómodo: alguien limpió errores#
Una línea como esta me hace levantar la ceja.
| |
zpool clear limpia contadores de errores del pool. No arregla un disco por ciencia infusa. Puede ser correcto usarlo después de resolver un problema, claro. Pero si aparece sin contexto, yo no lo ignoro.
Cuando veo un clear, miro alrededor.
| |
Quiero saber si antes hubo errores, si el pool está ahora limpio y si el kernel registró problemas de I/O. Si todo está bien, perfecto. Si no, ese clear puede haber maquillado el contador que habría explicado el susto.
No es paranoia. Es higiene. En storage, limpiar el testigo antes de entender el incendio es mala idea.
cuidado con interpretar demasiado#
zpool history te dice qué se ejecutó. No siempre te dice por qué. Y eso cambia mucho.
Un zfs destroy puede ser una limpieza normal. Un zfs set atime=off puede ser una optimización sensata. Un zpool scrub puede ser mantenimiento rutinario. Un zpool clear puede estar perfectamente justificado. El comando no convierte a nadie en culpable.
Lo que hace es acotar el terreno. Si el problema empezó a las 08:10 y a las 08:06 alguien tocó propiedades del dataset, tengo una zona que revisar. Si el historial no muestra nada cerca de la hora del problema, quizá debo mirar procesos dentro de la VM, red, backups, kernel o el storage desde otra capa.
La herramienta evita dos errores muy comunes.
El primero es asumir que nada cambió. En homelab eso casi nunca es verdad. Siempre cambió algo, aunque fuese una actualización automática o una prueba rápida.
El segundo es asumir que todo cambio cercano causó el problema. Esa también es una trampa. Correlación no es causalidad, aunque a las dos de la mañana se parezca bastante.
cómo lo combino con otros comandos#
Para mí zpool history rara vez va solo. Lo uso como una pieza dentro de una secuencia corta.
Primero miro salud.
| |
Luego miro actividad si hay lentitud.
| |
Después miro historial.
| |
Y si el problema está en una VM concreta, cruzo con Proxmox.
| |
No es una receta universal. Es una forma de no perderme. Estado actual, carga actual, cambios recientes y configuración de la VM. Con esas cuatro piezas suelo saber hacia dónde tirar.
Si el historial enseña un cambio sospechoso, investigo ese cambio. Si no enseña nada, dejo de perseguir fantasmas de ZFS y subo o bajo de capa según toque.
propiedades que me interesan especialmente#
Cuando leo historial, hay propiedades que me llaman más la atención que otras.
compression me interesa porque puede afectar rendimiento y consumo. Normalmente uso compresión sin miedo, pero quiero saber cuándo se cambió.
atime me interesa en datasets con muchos archivos. Desactivarlo suele tener sentido, pero si alguien lo toca en medio de una prueba, lo apunto.
sync me interesa mucho. Cambiarlo puede alterar rendimiento y seguridad de escritura. Si veo sync=disabled, pregunto quién estaba jugando con fuego.
recordsize y volblocksize me interesan porque afectan cargas específicas. No son propiedades para tocar alegremente en discos de VM existentes.
mountpoint me interesa porque un dataset montado donde no toca puede generar efectos raros. No siempre rompe algo de forma evidente. A veces solo deja el sistema en ese estado desagradable donde todo parece casi bien.
No necesito memorizar todas las propiedades de ZFS. Necesito reconocer las que cambian comportamiento real.
qué hago si el historial está demasiado largo#
En pools con tiempo, el historial puede ser largo. No pasa nada. Uso filtros.
Para ver lo último:
| |
Para buscar destrucciones:
| |
Para snapshots:
| |
Para cambios de propiedades:
| |
Y si estoy documentando una incidencia, copio solo el fragmento relevante en mis notas. No hace falta guardar todo el historial. Hace falta guardar la parte que explica el cambio.
mi opinión después de usarlo bastante#
zpool history no es un comando glamuroso. Nadie monta un homelab para mirar historiales de ZFS como quien lee prensa deportiva. Pero cuando tienes Proxmox con varias VMs, snapshots, plantillas y discos moviéndose, acaba siendo una herramienta muy práctica.
Lo mejor que tiene es que te obliga a mirar hechos. Qué se lanzó, cuándo se lanzó y sobre qué pool o dataset. En troubleshooting eso vale más que una intuición elegante.
También tiene una virtud menos técnica: baja el nivel de culpa difusa. Cuando algo falla, es fácil pensar que Proxmox está raro, que ZFS es delicado o que el servidor está poseído. A veces sí. Muchas veces no. Muchas veces alguien cambió una propiedad, borró un snapshot o limpió un contador y se olvidó.
Yo lo tengo como comando de segunda línea. Primero salud, luego actividad, luego historial. Si algo cambió, ahí suele aparecer. Y si no aparece, también me ayuda, porque me permite dejar de mirar el pool como sospechoso principal.
En un homelab, saber cuándo dejar de mirar una cosa es casi tan importante como saber dónde mirar. Menos épico, más útil. Como casi todo lo que de verdad arregla problemas.