zfs rollback es el comando que más se parece a un botón de deshacer, y precisamente por eso lo trato con bastante respeto. Devuelve un dataset al estado de un snapshot anterior. Suena precioso hasta que recuerdas la parte incómoda: todo lo que haya cambiado después puede desaparecer.
No es un backup. No es una copia externa. No te salva si pierdes el pool. No te salva si el disco muere y no tienes otra réplica. Es una herramienta local para volver un dataset a un punto anterior, rápida y útil cuando sabes lo que estás haciendo.
En Proxmox puede tener mucho sentido para datasets de plantillas, datos auxiliares, contenedores o entornos de prueba. Para discos de VM también existe la idea de volver a snapshots, pero ahí suelo preferir las herramientas de Proxmox cuando el snapshot se creó desde Proxmox. Mezclar capas sin pensar es una forma elegante de fabricar una tarde estúpida.
El comando básico es este.
| |
Antes de ejecutarlo, miro tres cosas.
| |
Si no entiendo esas tres salidas, no hago rollback. Así de simple.
la captura de este post#
La captura usa una salida saneada de un dataset de ejemplo en Proxmox. Enseña el flujo mínimo: listar snapshots, mirar cambios y volver al snapshot elegido.
Esta es la salida saneada que usé para generar la captura:
| |
La última salida queda vacía porque el dataset vuelve a estar como estaba en antes-prueba. Eso es lo que quiero ver en un rollback sencillo. Si sigue mostrando cambios, entonces no he entendido bien qué estaba comparando o el dataset ha cambiado otra vez después del rollback.
cuándo uso rollback de verdad#
Lo uso cuando he hecho un cambio local claro y quiero volver exactamente al punto anterior. Por ejemplo, antes de limpiar una carpeta de plantillas, antes de tocar un dataset de pruebas o antes de cambiar una estructura de archivos que me puede salir rana.
El flujo sano empieza antes del problema.
| |
Hago la prueba.
Si sale mal, miro el diff.
| |
Y si lo que veo encaja con lo que quiero deshacer, hago rollback.
| |
Esto funciona muy bien cuando el cambio fue pequeño y reciente. También funciona cuando estoy haciendo pruebas controladas. Donde no me gusta es cuando el snapshot tiene semanas y no sé qué ha pasado después. Ahí rollback deja de ser un salvavidas y empieza a parecerse a una ruleta.
la parte peligrosa: snapshots posteriores#
ZFS no siempre te deja volver a un snapshot antiguo si hay snapshots posteriores. Tiene sentido. Si quieres volver a un punto anterior, los snapshots más nuevos pueden depender de estados que ya no encajan con esa línea temporal.
A veces verás un error parecido a este.
| |
Ese mensaje no está decorando la terminal. Te está diciendo que si usas -r, vas a borrar snapshots más recientes.
El comando sería este.
| |
Yo no ejecuto eso por inercia. Primero listo snapshots.
| |
Luego comparo.
| |
Si el snapshot posterior no importa, perfecto. Si no estoy seguro, paro. El espacio en disco se recupera. Los datos borrados con alegría no siempre.
rollback no es restore granular#
Este punto merece repetirse porque es donde mucha gente se pega el golpe. zfs rollback devuelve el dataset entero al snapshot. No restaura un archivo concreto y deja el resto como está.
Si quiero recuperar un archivo puntual, normalmente prefiero montarme el snapshot o acceder al .zfs/snapshot si está disponible, copiar el archivo y salir de ahí sin tocar el estado completo del dataset.
Algo así, según cómo tengas visible snapshots.
| |
Ese enfoque es menos dramático. Recupero lo que necesito y no revierto todo el dataset. Para un archivo perdido, suele ser mejor que hacer rollback de todo.
Rollback lo reservo para cuando quiero volver el conjunto entero al punto anterior.
Proxmox y las capas de snapshots#
En Proxmox hay que separar conceptos. Una cosa es un snapshot ZFS del dataset o zvol. Otra cosa es un snapshot de VM gestionado por Proxmox. Otra cosa es un backup en Proxmox Backup Server. Y otra cosa es una réplica ZFS.
Parecen parientes, pero no son lo mismo.
Si he creado un snapshot de una VM desde la interfaz de Proxmox, intento revertirlo desde Proxmox. Así mantengo la metadata de la VM, discos, memoria si aplica y estado esperado por la plataforma. Si me pongo a hacer rollback manual del zvol por debajo, puede funcionar en algunos casos, pero también puedo dejar la capa de Proxmox pensando una cosa y el storage haciendo otra.
Para datasets propios, como templates, isos, exports o datos de laboratorio, sí me siento cómodo usando zfs rollback directamente. La clave es saber qué capa está mandando.
Esto conecta con algo que ya comenté en qm rollback en Proxmox. Si la VM vive dentro del modelo de snapshots de Proxmox, uso ese modelo. Si estoy trabajando con ZFS como sistema de archivos, uso ZFS.
mi checklist antes de pulsar enter#
Mi checklist es corta porque si necesita doce pasos, probablemente no debería hacerlo con sueño.
Primero confirmo el dataset exacto.
| |
Segundo, miro snapshots disponibles.
| |
Tercero, miro qué perdería.
| |
Cuarto, confirmo si hay snapshots posteriores.
| |
Y solo entonces hago rollback.
| |
Si necesito -r, me obligo a leer otra vez la lista de snapshots. Sí, es pesado. También es bastante menos pesado que explicarle a mi yo de dentro de diez minutos por qué acabo de borrar el único snapshot útil.
qué hago después del rollback#
Después no cierro la terminal y me voy como si nada. Compruebo.
| |
Si el diff queda vacío, el dataset coincide con el snapshot. Si los snapshots están como esperaba, bien. Si used o referenced cambia de forma rara, investigo antes de tocar más.
También suelo crear un snapshot nuevo si el estado restaurado pasa a ser mi nuevo punto bueno.
| |
Me gusta dejar una marca clara. No por estética, sino porque dentro de una semana los nombres buenos ahorran tiempo. Los nombres malos son deuda técnica con sombrero de fiesta.
rollback frente a backups#
Un snapshot local es rápido porque no copia todos los datos. Depende del pool. Si el pool se rompe, el snapshot se va con él. Esto no es un defecto, es cómo funciona.
Un backup tiene que vivir fuera. Otro disco, otro servidor, Proxmox Backup Server, una réplica fuera del nodo o lo que tenga sentido. Si lo único que tienes es un snapshot en el mismo pool, tienes comodidad, no resiliencia.
Por eso no uso rollback como estrategia de backup. Lo uso como herramienta de corrección rápida. Para dormir tranquilo necesito copias fuera del fallo principal. Ya sea PBS, backups 3-2-1 o una combinación menos bonita pero realista.
En homelab hay una tentación muy fuerte de llamar backup a cualquier cosa que tenga una arroba en el nombre. Mala idea. Un snapshot es una foto local. Un backup es algo que sigue existiendo cuando el original decide morirse.
mi conclusión#
zfs rollback es útil, rápido y peligroso si vas en automático. A mí me gusta porque cuando tengo el snapshot correcto puedo volver atrás en segundos. Pero no lo ejecuto sin mirar diff, snapshots posteriores y capa de Proxmox implicada.
Si el cambio fue pequeño y reciente, rollback es una maravilla. Si no sabes qué ha pasado desde el snapshot, es mejor frenar. Un comando rápido no convierte una decisión incierta en una buena decisión.
Mi regla práctica es simple: si no puedo explicar qué voy a perder, no hago rollback. ZFS te da herramientas potentísimas. La parte difícil sigue siendo no usarlas como un animal con acceso root.