zfs snapshot es una de esas herramientas que parece demasiado simple para lo importante que acaba siendo. Congela el estado de un dataset en un momento concreto y te deja volver a mirar qué había allí después. No mueve datos como un backup clásico. No copia el dataset entero a otra parte. Al principio solo guarda una referencia, y a partir de ahí ZFS conserva los bloques antiguos que cambian después del snapshot.
En castellano de homelab: es el botón de “antes de tocar esto, déjame una cuerda atada a la cintura”.
Lo uso bastante en Proxmox, pero con una norma mental muy clara. Un snapshot no es un backup. Si el pool muere, el snapshot muere con él. Si borras el dataset, puedes perderlo todo. Si alguien mete la pata con permisos o con un destroy, el snapshot no es una copia mágica escondida en una caja fuerte. Es una foto local del estado de un dataset.
Dicho eso, para cambios controlados es comodísimo. Antes de limpiar plantillas. Antes de probar un script que toca ficheros. Antes de cambiar propiedades de un dataset. Antes de actualizar una carpeta que usan varios contenedores. En esos casos un snapshot me da margen para equivocarme sin convertir cada cambio pequeño en una operación de restauración pesada.
El comando básico es este.
| |
En mi cabeza no existe “snapshot rápido” sin nombre decente. Si creo esto, me estoy haciendo daño a futuro.
| |
A los tres días no voy a recordar qué prueba era. Prefiero algo así.
| |
No hace falta escribir una novela en el nombre, pero sí lo suficiente para que el yo de mañana no me odie.
la captura de este post#
La captura usa una salida saneada de un dataset de ejemplo en Proxmox. No aparecen IPs reales, nombres internos ni rutas privadas. Es el flujo mínimo que suelo seguir cuando voy a tocar algo pequeño.
Esta es la salida saneada que usé para generar la captura:
| |
Ese último destroy no es parte obligatoria del flujo. Lo enseño porque también forma parte de usar snapshots con cabeza. Crear snapshots es fácil. Dejarlos acumulados durante meses porque nadie se atreve a borrar nada es la forma lenta de llenar un pool y luego fingir sorpresa.
cuándo creo un snapshot a mano#
No creo snapshots manuales para todo. Si hiciera eso, acabaría con una colección absurda de puntos de vuelta que nadie entiende. Los creo cuando hay una acción concreta que puede salir mal y el coste de preparar una vuelta atrás es bajo.
Mis casos típicos son bastante mundanos.
Antes de limpiar un dataset de plantillas. Aquí suele haber ISOs, imágenes cloud-init, ficheros temporales y restos de pruebas. Si voy a borrar cosas a mano, snapshot primero. No porque sea una operación heroica, sino porque una limpieza manual a las once de la noche tiene una probabilidad razonable de ser más creativa de lo previsto.
Antes de tocar configuración compartida por varios contenedores. Si un dataset lo montan dos o tres servicios, prefiero tener un punto de vuelta. A veces el cambio es pequeño, pero el efecto colateral aparece en el servicio que no estabas mirando.
Antes de ejecutar scripts propios. Esto incluye scripts de limpieza, scripts de migración y cualquier cosa que camine por carpetas borrando o renombrando ficheros. Si el script está recién escrito, snapshot. Si el script lleva meses funcionando, probablemente también, porque la confianza es maravillosa hasta que se encuentra con un caso raro.
Antes de cambiar propiedades de ZFS que afectan al comportamiento del dataset. Compresión, atime, recordsize, mountpoint o cuotas. Algunas propiedades no reescriben datos ya existentes, otras tienen matices. Tener un punto de referencia me ayuda a leer qué pasó después.
No suelo crear snapshots manuales antes de cada cambio dentro de una VM. Para eso prefiero snapshots desde Proxmox cuando estoy trabajando a nivel VM, o backups si el riesgo es mayor. Mezclar zfs snapshot a nivel de zvol con expectativas de “voy a ver archivos dentro del invitado” es pedirle a ZFS que haga magia que no prometió.
cómo nombro los snapshots#
Aquí soy bastante pesado. El nombre tiene que explicar el motivo, no solo la fecha.
Mal.
| |
Mejor.
| |
La fecha ya aparece en creation, así que no siempre la meto en el nombre. Si el snapshot forma parte de una rutina programada, sí me gusta usar fecha y hora.
| |
Para snapshots manuales prefiero el motivo. Cuando estoy revisando una lista, antes-cambiar-permisos me dice más que 2026-06-15-0800.
cómo reviso lo que tengo#
Para listar snapshots de un dataset uso esto.
| |
name me da el snapshot. used me dice cuánto espacio mantiene vivo ese snapshot. refer me orienta sobre el tamaño referenciado del dataset en ese punto. creation me da la fecha.
La columna que más respeto impone es used. Al principio un snapshot puede ocupar muy poco. Después empiezas a modificar o borrar ficheros grandes y ese snapshot impide liberar bloques antiguos. El pool no se llena por magia. Se llena porque le pediste a ZFS que conservara historia y luego te olvidaste de pagar la factura.
Para ver solo snapshots recientes puedo ordenar por creación.
| |
Y si quiero ver el daño real antes de decidir si borro o mantengo, miro los cambios.
| |
zfs diff ya lo uso como lupa. No me dice todo en todos los casos, sobre todo si estoy ante zvols de VMs, pero en datasets de archivos es muy útil. Si veo dos ficheros cambiados y uno añadido, sé si el snapshot sigue teniendo sentido. Si veo medio árbol movido, ya sé que no era una prueba tan pequeña.
el error de creer que snapshot significa backup#
Este es el punto que más conviene repetir. Un snapshot local no es una copia de seguridad. Es una versión del dataset dentro del mismo pool. Si ese pool se corrompe, si pierdes suficientes discos, si borras el pool entero o si el servidor desaparece, el snapshot no va a levantarse de una silla con una gabardina para salvarte.
Sirve para errores lógicos locales. Borré algo. Cambié algo. Actualicé algo. Quiero comparar. Quiero volver. Para desastre físico o pérdida completa necesitas backup fuera del pool, y mejor todavía fuera de la máquina.
Por eso no me gusta llamar @backup a un snapshot. Es una mentira pequeña que luego genera decisiones grandes. Si se llama @antes-upgrade, entiendo qué es. Si se llama @backup, alguien puede asumir que está cubierto cuando no lo está.
snapshots en datasets frente a snapshots en VMs#
En Proxmox hay dos mundos que se parecen, pero no son lo mismo.
Si tengo un dataset ZFS montado como sistema de archivos, zfs snapshot es directo. Puedo ver ficheros, puedo usar zfs diff, puedo montar clones si lo necesito y puedo razonar bastante bien sobre qué cambió.
Si tengo una VM con disco sobre ZFS, normalmente Proxmox trabaja con zvols. Ahí puedo tener snapshots, claro, pero la lectura cambia. ZFS no sabe qué fichero cambió dentro de la VM. Solo ve bloques del volumen. Para operaciones sobre VMs suelo preferir usar la capa de Proxmox, porque así el estado queda reflejado donde luego voy a mirar la máquina.
Esto no significa que los snapshots de ZFS no valgan para VMs. Significa que no conviene mezclar herramientas sin saber qué capa estás tocando. Si el snapshot lo creó Proxmox, lo gestiono desde Proxmox salvo que tenga un motivo claro para bajar de capa.
cuánto tiempo dejo vivos los snapshots#
Depende del tipo, pero para snapshots manuales soy agresivo. Si ya terminé el cambio y lo validé, lo borro. No necesito conservar cada mini prueba como si fuera patrimonio cultural.
| |
Antes de borrar, reviso la lista.
| |
Si un snapshot manual ocupa 72K y tiene unas horas, no pasa nada. Si uno de hace dos meses ocupa 80G y nadie sabe por qué existe, eso ya no es prudencia. Es síndrome de Diógenes con checksums.
Para snapshots automáticos uso retención. Por ejemplo, conservar horarios durante un día, diarios durante una semana y semanales durante un mes. No hay una regla universal. La regla buena es la que entiendes y puedes pagar en espacio.
una rutina mínima antes de tocar un dataset#
Mi rutina corta es esta.
| |
Hago el cambio. Luego miro qué cambió.
| |
Si todo está bien, espero lo justo para validar el servicio afectado y borro el snapshot.
| |
Si algo salió mal, no corro al rollback como un animal. Primero leo el diff. Luego decido si zfs rollback es lo correcto o si basta con copiar un fichero desde .zfs/snapshot, restaurar a mano o deshacer el cambio en la aplicación.
Ese matiz importa. Rollback revierte el dataset entero al snapshot. A veces solo necesitas recuperar un archivo. Usar una excavadora para colgar un cuadro tiene su gracia hasta que ves la pared.
acceso a ficheros desde .zfs/snapshot#
En datasets con archivos, muchas veces no necesito rollback. Puedo mirar dentro del snapshot y copiar lo que me falta.
Según la configuración, los snapshots pueden aparecer bajo .zfs/snapshot en el punto de montaje del dataset.
| |
Si lo que perdí fue un fichero concreto, puedo recuperarlo desde ahí.
| |
Esto me gusta más que hacer rollback cuando el daño es pequeño. Mantengo los cambios buenos posteriores y recupero solo lo que necesito. No siempre aplica, pero cuando aplica es mucho menos bruto.
problemas habituales#
El primero es crear snapshots y olvidarse. Ya lo dije, pero merece otra vuelta. Un snapshot antiguo puede retener mucho espacio porque conserva bloques que el dataset actual ya no usa. Si borraste una ISO enorme después de crear el snapshot, el espacio no se libera del todo mientras ese snapshot siga vivo.
El segundo es usar nombres inútiles. @test, @old, @backup-final, @backup-final-ok y demás basura mental. En un homelab pequeño parece tolerable. En cuanto tienes varios datasets, varios nodos y varias pruebas por semana, se vuelve barro.
El tercero es hacer rollback sin mirar. Un rollback puede destruir cambios posteriores. Si después del snapshot añadiste ficheros buenos, también pueden irse. Por eso miro zfs diff antes. No porque sea ritual, sino porque me evita perder trabajo válido.
El cuarto es pensar que todos los snapshots son iguales. Dataset de archivos, zvol de VM, snapshot creado por Proxmox, snapshot creado a mano, snapshot automático por una herramienta. Parecen familia, pero no todos se gestionan igual.
mi regla práctica#
Si voy a tocar un dataset ZFS y puedo explicar el riesgo en una frase, creo un snapshot con ese motivo en el nombre. Si no puedo explicar el riesgo, paro y miro mejor. Y si el dato importa de verdad, snapshot más backup, no snapshot en solitario.
zfs snapshot me gusta porque es rápido, transparente y muy honesto. No promete más de lo que hace. Congela un momento dentro del pool. Punto. Usado así, es una herramienta fantástica. Usado como sustituto de backup, es una trampa con buena documentación.