zfs rename es el tipo de comando que parece inocente hasta que recuerdas que Proxmox guarda referencias a storages, discos, subvolúmenes y rutas con menos poesía de la que uno imagina.
Renombrar un dataset en ZFS es fácil. Demasiado fácil, quizá. Escribir el comando lleva segundos.
| |
El problema no es que ZFS no sepa hacerlo. ZFS lo hace muy bien. El problema es si ese dataset lo estaba usando algo que esperaba encontrarlo con el nombre antiguo. Una VM, un LXC, una entrada de storage en Proxmox, un script de backup, una tarea cron, una documentación vieja o una automatización que escribiste una noche y que ahora te mira desde las sombras.
Por eso no uso zfs rename como una operación estética. No renombro datasets para que queden bonitos en una captura. Lo uso cuando hay una razón real: limpiar una prueba, mover un dataset dentro de una jerarquía más clara, preparar una migración, ordenar plantillas o corregir un nombre malo antes de que se convierta en costumbre.
Y antes de tocar nada miro más de lo que el comando pide. Porque el comando solo pide origen y destino. La realidad pide algo más de humildad.
la captura de este post#
La captura usa una salida saneada de un entorno Proxmox con ZFS. Los nombres son genéricos y no enseñan estructura interna. Me interesa enseñar la secuencia: listar, comprobar propiedades, renombrar y validar que el dataset aparece con el nombre nuevo.
Esta es la salida de ejemplo.
| |
En este caso todo es sencillo porque el dataset era de prueba. No había VM, LXC ni storage de Proxmox apuntando ahí. Cuando sí los hay, la historia cambia bastante.
qué hace realmente zfs rename#
zfs rename cambia el nombre de un dataset, snapshot o volumen ZFS. También puede moverlo dentro de la jerarquía si el destino está en el mismo pool.
Ejemplo simple:
| |
Ejemplo moviéndolo dentro de otro padre:
| |
No copia datos como haría un rsync. No crea un duplicado completo. Cambia la referencia dentro de ZFS. Por eso es rápido incluso con datasets grandes. Esa velocidad es cómoda, pero también puede engañar. Que sea rápido no significa que sea trivial para las capas que dependen del nombre.
Si el dataset tiene snapshots, se quedan con él. Si tiene hijos, puedes renombrar jerarquías con cuidado. Si el dataset está montado, ZFS puede actualizar el punto de montaje cuando el mountpoint viene heredado o por defecto. Si el mountpoint está fijado manualmente, puede seguir apuntando donde estaba.
Ese detalle del mountpoint importa mucho.
miro mountpoint antes de tocar#
Antes de renombrar, siempre miro el punto de montaje.
| |
Si el mountpoint viene de default, normalmente cambiará con el nombre del dataset. Si antes era /pve-zfs/test, después puede quedar como /pve-zfs/lab-test.
Si el mountpoint está puesto de forma local, puede no cambiar como esperas.
| |
En ese caso renombrar el dataset no implica necesariamente cambiar la ruta. Puede que eso sea justo lo que quieres. O puede que sea una trampa, porque el nombre dice una cosa y el montaje otra.
En Proxmox intento evitar nombres que mientan. Si un dataset se llama archive pero monta en /srv/templates, dentro de tres meses alguien va a perder tiempo. Seguramente yo.
Por eso después de renombrar vuelvo a mirar.
| |
Y si hace falta ajusto mountpoint de forma explícita.
| |
No lo hago por estética. Lo hago para que el sistema cuente la misma historia desde ZFS, desde Proxmox y desde mi cabeza.
cuidado si Proxmox conoce ese storage#
Aquí está la parte que más me importa. Si el dataset es solo una zona de pruebas, renombrarlo suele ser fácil. Si Proxmox lo tiene configurado como storage, hay que revisar antes.
| |
Si hay una entrada de tipo zfspool, Proxmox puede estar usando el nombre del pool o del dataset. Si hay una entrada de tipo dir, puede estar usando una ruta montada sobre ese dataset.
Los dos casos son distintos.
Con dir, Proxmox mira una ruta. Si renombro el dataset y cambia el punto de montaje, la ruta antigua puede quedar vacía o desaparecer. Proxmox no sabe que mi intención era moverlo todo a un nombre más bonito. Solo sabe que donde antes había cosas ahora no están.
Con zfspool, Proxmox trabaja con ZFS de forma más directa. Renombrar datasets debajo puede afectar a referencias de discos o subvolúmenes. No me gusta tocar eso sin revisar qm config y pct config.
Antes de renombrar algo que pueda tocar VMs:
| |
Antes de renombrar algo que pueda tocar contenedores:
| |
Si veo rutas o volúmenes que apuntan al dataset, paro. Primero decido cómo migrarlo bien. A veces lo correcto no es zfs rename, sino mover el disco desde Proxmox, hacer backup y restore, o crear un dataset nuevo y copiar datos con calma.
no renombro discos de VM a mano por capricho#
Esto merece su propia advertencia. Los discos de VM en ZFS suelen aparecer como zvols con nombres tipo:
| |
Los contenedores pueden aparecer como subvolúmenes:
| |
Ver esos nombres despierta una tentación peligrosa: renombrarlos para que sean más humanos. Mala idea como reflejo.
Proxmox espera esos nombres. Sus configuraciones apuntan a ellos. Si los cambias por fuera, puedes dejar una VM sin disco desde el punto de vista de Proxmox aunque los datos sigan existiendo. Luego toca reparar referencias, editar config y fingir que era una prueba controlada. No cuela.
Si quiero mover o renombrar discos de VM, prefiero usar herramientas de Proxmox cuando existan.
| |
O reviso la config con muchísimo cuidado antes de hacer una intervención manual. Hay casos donde tocar ZFS directamente tiene sentido, pero no son el camino normal para ordenar nombres.
Mi regla: datasets de trabajo, sí. Discos de VM gestionados por Proxmox, cuidado extremo. Zvols con nombres automáticos, no los maquillo para sentirme mejor.
snapshots y renombres#
Los snapshots viajan con el dataset. Si renombro:
| |
Un snapshot que antes veías como:
| |
pasará a estar bajo:
| |
Eso está bien. Pero si tienes scripts que buscan snapshots por nombre de dataset, pueden dejar de encontrarlos. Un script de limpieza, una replicación casera con zfs send, una comprobación de snapshots antiguos o un inventario nocturno pueden depender del nombre anterior.
Antes de renombrar datasets que participan en replicación, miro los scripts. No todos los sistemas fallan gritando. Algunos fallan dejando de hacer copias. Esos son los peores, porque te enteras tarde.
También me fijo si el dataset tiene muchos snapshots.
| |
No porque impida renombrar, sino porque me dice si ese dataset tiene historia. Un dataset con veinte snapshots, clones o replicaciones merece más respeto que uno recién creado para probar compresión.
clones y dependencias#
Si hay clones, el renombre puede seguir siendo posible, pero quiero entender la relación.
| |
Los clones tienen origen en snapshots. Si estoy reorganizando datasets de prueba, puede que un clon dependa de un snapshot que pensaba borrar después. Renombrar no arregla ni rompe por sí solo esa relación, pero puede hacer más difícil leerla si cambio nombres sin orden.
Aquí mi consejo es poco glamuroso: dibuja la jerarquía, aunque sea mentalmente.
| |
Si no puedo explicar qué datasets son padres, cuáles son hijos y cuáles son clones, no renombro. Primero entiendo. Luego toco.
mi secuencia segura#
Cuando el dataset es normal y no forma parte directa de discos de VM o LXC, hago algo así.
| |
Si el dataset está montado y el punto de montaje cambia, miro que la ruta antigua no se haya quedado con basura o con un directorio vacío que pueda confundir a Proxmox.
| |
Si había servicios usando la ruta, los reinicio o actualizo configuración. Si había scripts, actualizo scripts. Si había documentación, la cambio. Esa última parte parece menor hasta que dentro de seis meses sigues una nota antigua y acabas mirando un dataset que ya no existe.
cuándo prefiero crear nuevo y copiar#
No siempre renombro. A veces prefiero crear un dataset nuevo y copiar datos.
| |
Uso esa ruta cuando quiero cambiar organización y al mismo tiempo limpiar permisos, revisar contenido o evitar tocar algo en caliente. Es más lento, pero también más explícito. En storage, explícito suele ser mejor que brillante.
Si hay una aplicación escribiendo, paro aplicación o hago una ventana de mantenimiento. Si hay muchas referencias, copiar y migrar paso a paso me deja validar. Renombrar es elegante, pero no siempre es la opción más segura.
errores típicos#
El primer error es renombrar sin mirar Proxmox. ZFS acepta el cambio, Proxmox se queda mirando el nombre viejo y tú descubres que la capa bonita de la web no comparte tu entusiasmo.
El segundo es confundir dataset con punto de montaje. Cambias el nombre del dataset y crees que cambió la ruta, pero el mountpoint estaba fijado manualmente. O al revés: crees que la ruta seguirá igual y cambia porque venía de default.
El tercero es tocar zvols de VM como si fueran carpetas. No lo son. Si Proxmox creó ese disco, Proxmox tiene algo que decir.
El cuarto es olvidar scripts. El homelab moderno está lleno de automatismos pequeños. Backups, informes, scrubs, snapshots, copias, avisos. Un nombre cambiado puede romper una tarea que no mirarás hasta que haga falta.
El quinto es renombrar para ordenar algo que en realidad deberías borrar. Si el dataset es una prueba muerta, quizá no necesita un nombre mejor. Quizá necesita un backup si hay algo útil y luego zfs destroy. Ordenar basura sigue siendo basura, solo que con etiquetas.
cierre#
zfs rename es rápido, cómodo y muy útil. También es uno de esos comandos que te deja meterte en líos limpios, de los que no parecen líos hasta que otra capa del sistema pregunta por el nombre anterior.
En Proxmox lo uso con una regla sencilla: si el dataset vive solo, renombrar suele ser tranquilo. Si Proxmox, una VM, un LXC, un snapshot script o una tarea de backup lo conocen, primero reviso referencias.
Cambiar el nombre es la parte fácil. Mantener coherente todo lo que depende de ese nombre es el trabajo real.
Y si tengo dudas, creo un dataset nuevo, copio con calma y valido. No queda tan elegante en la terminal, pero dormir tranquilo también tiene su encanto.