zfs destroy es el comando que intento escribir con las dos manos en el volante. No porque sea complicado. Justo al revés. Es fácil, rápido y definitivo en el sentido más incómodo de la palabra. Sirve para borrar snapshots, datasets, clones y volúmenes. También sirve para arruinarte la noche si lo lanzas contra el nombre equivocado.
En Proxmox aparece tarde o temprano. Creas snapshots antes de tocar cosas. Clonas datasets para probar upgrades. Haces envíos con zfs send. Acumulas pruebas. Un día miras el pool y hay más restos que en el cajón de cables. Toca limpiar.
La limpieza en ZFS no es opcional. Los snapshots ocupan espacio cuando los datos cambian. Los clones pueden retener snapshots. Los datasets temporales se quedan ahí si nadie los borra. Y como el homelab tiene esa tendencia natural a convertirse en arqueología tecnológica, conviene tener una rutina para borrar sin ponerse creativo.
El comando básico parece inocente.
| |
Borra un snapshot. Si apuntas a un dataset, borra el dataset.
| |
La diferencia entre esas dos líneas es enorme. Una borra una foto. La otra borra un dataset entero. Por eso mi norma es no ejecutar destroy hasta haber listado exactamente lo que voy a tocar.
la captura de este post#
La captura usa salida saneada. No enseña nombres internos, rutas privadas ni identificadores reales. Es el flujo que sigo cuando quiero borrar snapshots antiguos sin llevarme por delante algo que todavía depende de ellos.
Esta es la salida saneada que usé para generar la captura:
| |
Ese error es bueno. ZFS me está diciendo que el snapshot no está solo. Hay un clon que depende de él. En ese momento no fuerzo. Reviso el clon, decido si se borra y después vuelvo al snapshot.
lo primero: saber si estoy borrando snapshot o dataset#
En ZFS, el carácter @ importa mucho. Si el nombre tiene @, estoy hablando de un snapshot.
| |
Si no tiene @, normalmente estoy hablando de un dataset, volumen o jerarquía.
| |
Esto parece básico, pero es la clase de básico que salva datos. Cuando estoy cansado, leo el comando en voz baja antes de darle a Enter. Si suena ridículo, perfecto. Prefiero parecer un señor hablando con una terminal que restaurar un backup porque he escrito una línea como un chimpancé con prisa.
Antes de borrar snapshots, listo snapshots.
| |
Antes de borrar datasets, listo datasets.
| |
No mezclo. No adivino. No borro por memoria.
uso -nvp siempre que puedo#
ZFS tiene una opción de prueba seca para destroy en algunos casos. La combinación que suelo usar es esta.
| |
-n no destruye nada. -v muestra más detalle. -p imprime valores de forma más directa. Lo que quiero ver es qué destruiría y cuánto espacio recuperaría.
Si la salida dice que va a borrar justo lo que espero, sigo. Si la salida enseña más de lo esperado, paro. Ese minuto de lectura evita muchas estupideces.
Con snapshots individuales suele ser muy cómodo. Con operaciones recursivas, más todavía. Cada vez que aparece -r o -R, mi nivel de atención sube.
-r y -R: los cuchillos grandes#
zfs destroy -r borra de forma recursiva. Si lo usas sobre un dataset, puede llevarse hijos. Si lo usas sobre snapshots con el mismo nombre en una jerarquía, puede borrar varios snapshots.
| |
Puede ser útil. También puede ser demasiado amplio. Por eso hago prueba seca.
| |
-R va más allá porque también considera clones dependientes. Es el botón que ZFS te sugiere cuando un snapshot tiene clones. No lo ejecuto como reflejo.
| |
Esa línea puede borrar el snapshot y los datasets clonados que dependen de él. Si esos clones eran pruebas viejas, bien. Si uno de esos clones se convirtió en algo útil y nadie lo documentó, acabas de aprender una lección cara.
Mi regla: si ZFS menciona -R, primero investigo.
| |
Luego decido. A veces borro el clon primero. A veces promociono o migro datos. A veces dejo el snapshot quieto hasta entender por qué existe esa dependencia.
cómo localizo snapshots que merecen limpieza#
No borro snapshots por antigüedad solamente. Borro snapshots por contexto. Uno de hace seis meses puede ser inútil. Otro de hace seis meses puede ser el punto base de una replicación incremental. La fecha ayuda, pero no decide sola.
Para revisar uso:
| |
Si quiero limitar a un dataset:
| |
La columna used me interesa, pero no la leo como una verdad simple. En snapshots, el espacio usado representa bloques retenidos por ese snapshot que no se podrían liberar si desaparece otro elemento. Puede cambiar cuando borras snapshots anteriores o posteriores. ZFS no es una suma de carpetas como en un explorador de archivos.
Aun así, si veo snapshots temporales con nombres tipo prueba, antes-test, upgrade-old o limpieza, los reviso. Los nombres malos envejecen fatal. Cuando un snapshot se llama test, nadie sabe si es basura o una reliquia sagrada. Culpa nuestra, no de ZFS.
mi rutina para borrar snapshots temporales#
La rutina que sigo es bastante aburrida. Me gusta que sea aburrida.
Primero listo snapshots del dataset.
| |
Después busco clones dependientes.
| |
Luego hago prueba seca.
| |
Si todo cuadra, borro.
| |
Después vuelvo a listar. Esto último parece manía, pero me confirma que el estado final es el que quería.
| |
No necesito automatizar cada limpieza. Para snapshots temporales creados a mano, prefiero una revisión manual. Para políticas repetitivas ya usaría una herramienta de snapshots con retención clara, pero eso es otro tema.
borrar datasets de pruebas#
Los datasets de pruebas deberían vivir en una rama fácil de reconocer. Por ejemplo:
| |
Así puedo revisar todo el árbol.
| |
Si un dataset de pruebas ya no sirve:
| |
Si tiene hijos, ZFS puede que pida recursividad. Antes de usar -r, miro qué hijos hay.
| |
Y luego, si de verdad quiero borrar todo ese árbol:
| |
El orden mental es siempre el mismo. Ver. Simular. Borrar. Ver otra vez.
cuidado con Proxmox y sus volúmenes#
En Proxmox hay que distinguir entre datasets que gestionas tú y volúmenes que Proxmox espera controlar. Si has creado un dataset auxiliar para datos de aplicaciones, perfecto. Si estás mirando discos de VM, contenedores o volúmenes gestionados desde el storage de Proxmox, no me lanzaría con zfs destroy manual salvo que sepas exactamente qué estás tocando.
Proxmox guarda configuración, referencias y expectativas sobre esos volúmenes. Borrar por debajo puede dejar recursos rotos en la interfaz, backups incoherentes o una VM que ya no tiene disco. A veces hay que limpiar a mano, claro. Pero no como primera opción.
Para VMs y contenedores, prefiero usar las herramientas de Proxmox cuando el recurso sigue existiendo. Si hay restos huérfanos, entonces sí reviso ZFS, pvesm y configuración. Pero eso ya es diagnóstico, no limpieza alegre.
cuándo no borro aunque parezca obvio#
No borro si no entiendo el nombre. antes-upgrade puede parecer viejo, pero necesito saber de qué upgrade hablamos. Si no lo sé y el espacio no aprieta, lo dejo hasta tener contexto.
No borro si hay replicación incremental apoyada en ese snapshot. Si usas zfs send -i, origen y destino necesitan un snapshot común. Borrar el snapshot base puede obligarte a hacer un envío completo otra vez.
No borro si hay clones dependientes y no sé qué son. La salida de ZFS te da la pista. Hay que seguirla.
No borro si estoy en el nodo equivocado. En clusters Proxmox con varios nodos, esto no es paranoia. Un prompt SSH parecido y un nombre de pool repetido bastan para hacer una estupidez perfectamente ejecutada.
espacio recuperado: no siempre es lo que esperas#
Una de las cosas que más confunde al principio es borrar un snapshot y recuperar menos espacio del esperado. O borrar varios y ver que el espacio cambia de forma rara. Es normal. Los snapshots comparten bloques. Un bloque puede estar retenido por más de un snapshot. Hasta que desaparecen todas las referencias necesarias, el pool no lo libera.
Por eso would reclaim ayuda, pero tampoco conviene convertirlo en una promesa emocional. ZFS calcula según el estado actual. Si hay snapshots solapados, clones y datasets vivos, el resultado puede sorprender.
Para revisar el pool después:
| |
Si lo que quieres es entender consumo fino por snapshots, toca mirar con calma. La limpieza de ZFS no se parece a vaciar la papelera del escritorio.
automatizar borrados: sí, pero con respeto#
Se puede automatizar retención de snapshots. De hecho, para sistemas serios prefiero políticas automáticas antes que snapshots eternos hechos a mano. Pero un script con zfs destroy merece revisión. Logs, prueba seca, filtros claros y nombres consistentes.
Nunca haría un script que borre cualquier snapshot que contenga test sin más. Hoy parece razonable. Mañana alguien crea pretest-produccion y ya tenemos comedia negra.
Si automatizo, filtro por prefijo controlado. Por ejemplo, snapshots creados por una tarea concreta:
| |
Y aun así probaría primero con -n. Los scripts no se cansan, pero tampoco se arrepienten.
mi forma de usar zfs destroy#
Con zfs destroy intento ser deliberado. No lento por postureo. Deliberado. Quiero saber qué borro, por qué lo borro y qué depende de eso.
La secuencia mínima que más uso es esta:
| |
Para datasets de pruebas:
| |
No hay glamour aquí. Es limpieza con casco.
con qué me quedo#
zfs destroy no es un comando malo. Es necesario. Si usas snapshots, clones y datasets temporales, también tienes que saber borrar. El problema no es destruir. El problema es destruir sin mirar.
En Proxmox lo uso con una rutina corta y repetible: listar, revisar dependencias, simular, borrar y comprobar. Si aparece un clon, paro. Si aparece recursividad, leo dos veces. Si estoy tocando volúmenes gestionados por Proxmox, intento usar primero las herramientas de Proxmox.
ZFS te da mucha libertad. La parte menos divertida es que también te deja hacer cosas absurdas con una precisión impecable. zfs destroy merece respeto por eso. No miedo. Respeto. El miedo te bloquea. El respeto te hace escribir el comando correcto.