Hay una clase de problemas en Proxmox que no empieza con un error rojo. Empieza con una decisión pequeña tomada demasiado rápido. Subir RAM a una VM sin mirar cómo está definida. Reiniciar un nodo pensando que no vive nada importante ahí. Mover un disco entre storages sin comprobar snapshots, bus, guest agent o espacio real. Entrar en un LXC como si fuera una VM pequeña y olvidar que comparte más de lo que parece con el host.
Hay una escena bastante común en un homelab con Proxmox. Abres el panel, algo tarda más de la cuenta, una consola no entra, una tarea se queda rara o un nodo aparece con datos que no parecen frescos. La tentación es culpar a la web. Total, es lo que tienes delante.
Yo intento no hacerlo. El panel de Proxmox es solo la cara visible de varias piezas distintas. Puede fallar el acceso HTTP y el cluster seguir bien. Puede cargar la web y estar pmxcfs medio tocado. Puede ir todo bien en apariencia y tener pvedaemon tragándose errores justo debajo.
Uso zfs rename con mucha más calma de la que sugiere el comando. Cambiar el nombre de un dataset es fácil. No romper referencias de Proxmox es la parte importante.
Uso zfs unmount cuando un dataset de ZFS no debería seguir montado o cuando necesito limpiar un punto de montaje raro. La clave está en mirar dependencias antes, no en forzar por orgullo.
Uso zfs mount para comprobar datasets ZFS que no se montan, rutas vacías y servicios que arrancan antes de que sus datos aparezcan. Es menos vistoso que culpar a Docker, pero funciona mejor.
Uso zpool trim con calma en pools ZFS sobre SSD o NVMe. No es magia, pero me ayuda a mantener el storage limpio después de mucho movimiento de VMs, backups y snapshots.
Uso zfs destroy con una rutina corta: listar, revisar dependencias, simular cuando se puede y borrar solo lo que entiendo. En ZFS, limpiar bien es tan importante como crear snapshots.
zfs clone convierte un snapshot en un dataset escribible. En Proxmox me sirve para pruebas rápidas, validaciones y migraciones pequeñas, pero siempre reviso de qué snapshot cuelga antes de borrar nada.
zfs send y receive convierten snapshots en streams que puedes guardar o enviar a otro servidor. En homelab me sirven para replicar datasets concretos, pero siempre hago primero una prueba seca y reviso nombres, tamaño y destino.
zfs snapshot no sustituye a un backup, pero me da un punto de vuelta local muy cómodo antes de tocar datasets ZFS. La clave está en nombrarlos bien, revisarlos y borrarlos cuando ya no hacen falta.
zfs rollback es útil cuando tienes claro el punto de vuelta y aceptas perder los cambios posteriores. No es un botón mágico de deshacer. En Proxmox conviene mirarlo dos veces antes de pulsar enter.
zfs diff no es magia y no sirve igual para todo, pero cuando tienes datasets de verdad te da una pista rápida de qué ha cambiado entre snapshots. Para mí es una herramienta de contexto antes de tocar nada serio.