Snapshots de ZFS: cómo funcionan y cómo usarlos
Los snapshots ZFS son una de las herramientas más prácticas del sistema de ficheros para recuperarse de errores humanos. Aquí tienes los comandos que necesitas y lo que debes saber antes de usarlos.
Tienes ZFS montado y aún no usas snapshots
Si llevas un tiempo con ZFS en tu homelab o en Proxmox, probablemente ya sabes que tienes algo potente entre manos. Pero si todavía no has creado ni un solo snapshot, estás dejando en la mesa la característica que más veces te va a salvar el pellejo: poder volver atrás en el tiempo sobre un dataset concreto sin tocar el resto del sistema.
Es normal que lo hayas ido postergando. Los snapshots suenan a concepto avanzado, y la documentación oficial de OpenZFS tampoco es que invite a entrar con ganas. ¿Cómo se llaman? ¿Dónde van? ¿Cuánto espacio ocupan? ¿Puedo hacer rollback sin cargármelo todo? Preguntas razonables que este post responde con comandos reales, no con teoría.
Al final de esta guía habrás creado tu primer snapshot, entenderás qué pasa por debajo cuando lo haces y sabrás cómo volver a un estado anterior si algo se tuerce. Cinco comandos. Sin magia, sin atajos raros.
Por qué importa
Copy-on-write instantáneo
Al crearlo no copia datos: solo registra bloques que cambien después. El coste de espacio crece con el tiempo.
Rollback en segundos
zfs rollback pool/dataset@nombre restaura el estado al instante. Por defecto solo funciona con el snapshot más reciente.
Envío a otra máquina
zfs send | zfs receive transfiere el snapshot a otro pool o servidor remoto para backups offsite.
No sustituye al RAID
Un snapshot en el mismo pool desaparece si el disco falla. Para protección ante hardware, necesitas mirrors o RAID-Z.
Qué es un snapshot ZFS (y por qué no es lo mismo que un backup)
Un snapshot ZFS es una foto del estado de un dataset en un momento exacto. No copia datos en ese instante: solo marca qué bloques existían. Lo que ocupa espacio es lo que cambia después, cuando el dataset original empieza a divergir del estado capturado.
Esto es copy-on-write en la práctica. Mientras el dataset no cambie, el snapshot es casi gratuito en espacio. Conforme vas escribiendo datos nuevos o modificando ficheros, ZFS guarda los bloques originales para mantener la coherencia de esa foto.
Ojo con una confusión frecuente: un snapshot que vive en el mismo pool que los datos originales se pierde si el pool falla. No es un backup. Es una red de seguridad para errores humanos —borraste sin querer, actualizaste y algo se rompió— pero no para fallos de disco. Para eso necesitas RAID-Z, mirrors o una copia en otro sitio.
Tu primer snapshot, paso a paso
Tienes un dataset datos/documentos y quieres guardar su estado antes de hacer cambios. El comando es directo:
zfs snapshot datos/documentos@antes-de-reorganizar
El nombre después de @ es libre. Ponlo descriptivo; luego lo vas a agradecer. Ahora lista los snapshots disponibles:
zfs list -t snapshot
Verás algo así:
NAME USED AVAIL REFER MOUNTPOINT
datos/documentos@antes-de-reorganizar 0B - 2,4G -
El 0B en USED es completamente normal: todavía no has cambiado nada en el dataset. Ese número irá creciendo según vayas modificando ficheros.
Cuánto espacio ocupa un snapshot con el tiempo
No hay número fijo. El espacio que consume un snapshot depende de cuántos bloques cambian en el dataset original desde su creación. Si modificas un fichero de 1 GB, el bloque original queda referenciado por el snapshot y aparece en su columna USED.
Un ejemplo concreto: un dataset de imágenes de Proxmox de unos 40 GB con VMs en uso normal. Después de una semana, el snapshot inicial pesa entre 6 y 8 GB. Después de un mes, fácilmente 15-20 GB. Depende por completo del workload de cada máquina.
Lo que sí puedes controlar:
- Cuántos snapshots mantienes activos (destruir los viejos libera el espacio que referencian)
- Con qué frecuencia creas snapshots (más granularidad implica más datos históricos y más espacio)
- Si tienes compresión habilitada en el dataset (ayuda mucho con logs, texto y bases de datos)
Para destruir un snapshot que ya no necesitas:
zfs destroy datos/documentos@antes-de-reorganizar
Rollback: recuperar el estado anterior
Volver al snapshot más reciente es sencillo:
zfs rollback datos/documentos@antes-de-reorganizar
Aquí viene una restricción que mucha gente descubre a las malas: por defecto, zfs rollback solo puede ir al snapshot más reciente del dataset. Si tienes varios y quieres volver a uno más antiguo, necesitas el flag -r:
zfs rollback -r datos/documentos@snapshot-del-lunes
El flag -r destruye todos los snapshots más recientes que el objetivo para poder hacer el rollback. Antes de usarlo, lista los snapshots y confirma exactamente cuáles vas a perder. No hay marcha atrás en eso.
Cuándo tiene sentido hacer rollback
Casos donde lo uso habitualmente:
- Antes de actualizar el kernel o paquetes críticos en una VM
- Antes de ejecutar un script que modifica muchos ficheros a la vez
- Antes de reorganizar estructuras de directorios grandes
No lo uso como sustituto de una copia off-site. Si el pool tiene un problema físico, el rollback no te salva.
Replicar snapshots con zfs send y zfs receive
Una de las funcionalidades más prácticas es enviar un snapshot a otro pool o a otra máquina. La sintaxis básica:
# Local: de un pool a otro (disco externo, segundo servidor...)
zfs send datos/documentos@antes-de-reorganizar | zfs receive backup/documentos
# Remoto: a otra máquina por SSH
zfs send datos/documentos@antes-de-reorganizar | ssh usuario@192.168.1.34 zfs receive backup/documentos
Para envíos incrementales —solo lo que cambió entre dos snapshots— la opción -i:
zfs send -i datos/documentos@snapshot-viejo datos/documentos@snapshot-nuevo | zfs receive backup/documentos
Esto es la base de la replicación ZFS: mantener un pool secundario sincronizado sin transferir datos duplicados cada vez. En una red doméstica de gigabit funciona muy bien para tener copias entre máquinas del homelab.
Snapshots ZFS en Proxmox: lo que cambia
Si usas Proxmox con almacenamiento ZFS, los snapshots funcionan igual pero con algún matiz. Al hacer un snapshot de una VM desde la interfaz web, tienes la opción de incluir el estado de la RAM o no.
Los snapshots ZFS del disco de la VM son snapshots ZFS normales. El estado de la RAM, si lo activas, lo gestiona QEMU por separado en un fichero distinto. Sin estado de RAM, la VM arrancará desde el snapshot de disco como si hubiera sufrido un corte de luz —generalmente está bien para Linux, pero puede ser un problema si la VM tenía trabajo en curso.
Para ver los snapshots ZFS de las VMs directamente desde la terminal:
zfs list -t snapshot | grep vm-
Verás entradas del tipo:
rpool/data/vm-100-disk-0@antes-actualizar-kernel 1,2G - 32G -
Una cosa que aprendí por las malas: dejar acumular snapshots de VMs activas hasta que el pool supera el 80% de uso. ZFS puede degradarse en rendimiento a partir de ese punto. Llevar un control de qué snapshots tienes y destruir los que ya no sirven es mantenimiento normal, no opcional.
Preguntas frecuentes
Q: ¿Cuánto espacio ocupa un snapshot ZFS recién creado?
A: Al crearse, prácticamente cero: los snapshots son copy-on-write y solo registran los bloques que cambian en el dataset original después de ese momento. El espacio crece con el tiempo según cuántos datos modifiques; un dataset muy activo puede acumular gigabytes en días.
Q: ¿Qué pasa si quiero volver a un snapshot antiguo, no al último?
A: Por defecto, 'zfs rollback' solo permite volver al snapshot más reciente. Para retroceder a uno anterior necesitas el flag '-r', que destruye todos los snapshots intermedios, así que ten claro qué pierdes antes de ejecutarlo.
Q: ¿Vale un snapshot ZFS como backup si el disco falla?
A: No. Un snapshot vive dentro del mismo pool, así que si el pool falla —disco roto, corrupción grave— el snapshot desaparece con él. Para backup real usa 'zfs send | zfs receive' hacia otro pool, otra máquina o almacenamiento externo.
Q: ¿Cuándo debo destruir un snapshot que ya no necesito?
A: Cuando el dataset origen ya está estable y no necesitas ese punto de restauración. Acumularlo sin criterio infla el uso de espacio progresivamente. El comando es 'zfs destroy pool/dataset@nombre'; puedes listar lo que tienes con 'zfs list -t snapshot' antes de decidir.
Q: ¿Cómo funciona un snapshot de VM en Proxmox con ZFS?
A: Proxmox usa ZFS para snapshotear el disco de la VM, pero no captura el estado de la RAM, a diferencia de los snapshots QEMU. Si la VM estaba encendida, al hacer rollback arrancará como si hubiera habido un corte de luz en ese instante.











Deja una respuesta