Wisp: nueva extensión GNOME para gestionar snapshots Btrfs de forma gráfica

septiembre 29, 2026 Alfonso Moreno | Sysadmin Senior 27 Visitas 10 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Wisp llega para llenar un hueco en GNOME

Wisp es una nueva extensión para GNOME Shell que pone la gestión de snapshots de Btrfs en la barra superior del escritorio. Hasta ahora, quien quería manejar snapshots Btrfs sin tocar la terminal tenía dos caminos: la herramienta gráfica btrfs-assistant (sin update desde hace tiempo) o el comando snapper directamente. Wisp aparece en un momento interesante: GNOME 51 acaba de salir en septiembre de 2026 y el escritorio Linux está en plena transición a setups con Btrfs como filesystem por defecto en Fedora Workstation, openSUSE Tumbleweed y CachyOS.

Lo que hace Wisp es integrarse con Snapper, el demonio que crea snapshots automáticos en sistemas Btrfs (típicamente cada hora y antes/después de cada transacción de paquetes). En vez de pedirte que abras una terminal y escribas snapper list, te muestra una lista en el top bar con cada snapshot, su descripción, qué cambió respecto al anterior y opciones para restaurar archivos individuales o hacer rollback completo del sistema.

Qué se puede hacer desde Wisp

La interfaz gráfica de Wisp cubre el flujo completo de Snapper sin sacrificar el detalle técnico. Las funciones principales, según el README del proyecto y los screenshots de Phoronix:

Listar snapshots en la barra superior, ordenados del más reciente al más viejo, con descripción visible.
Tomar un snapshot manual con descripción libre (por ejemplo, “antes de actualizar el kernel”).
Borrar snapshots con un diálogo de confirmación que dice exactamente qué se va a eliminar.
Abrir un snapshot en el gestor de archivos para navegarlo como si fuera una carpeta más.
Comparar dos snapshots para ver qué archivos cambiaron entre uno y otro (diff visual).
Restaurar archivos individuales desde un snapshot al sistema activo, usando snapper undochange.
Rollback completo del sistema al estado de un snapshot específico.
Editar políticas de retención por configuración de Snapper (timeline limits, hourly/daily/weekly/monthly).
Gestionar los temporizadores de Snapper y los jobs de btrfsmaintenance.
Ver uso de espacio por filesystem y qué bloques están asignados a chunks.

Cómo funciona por debajo

Wisp está escrita en GJS (JavaScript con bindings a GNOME) y se comunica con Snapper principalmente por D-Bus. Hay un detalle de diseño importante que el autor documenta en el README: snapperd no soporta polkit. Esto significa que en una instalación fresca, ningún usuario tiene permisos para leer los snapshots porque los campos ALLOW_USERS y ALLOW_GROUPS de cada configuración de Snapper están vacíos.

La solución que implementa Wisp es elegante: en lugar de pedir contraseña polkit cada vez que el usuario quiere ver su lista de snapshots, la extensión ofrece agregar la cuenta actual al campo ALLOW_USERS una sola vez, con SYNC_ACL activado para que los archivos dentro del snapshot también sean legibles. Esa llamada inicial pasa por pkexec (una sola autenticación); todo lo demás corre como usuario normal vía D-Bus plano.

Para las operaciones que sí requieren root (restaurar archivos, hacer rollback), Wisp muestra el comando exacto que va a ejecutar y pide confirmación con pkexec en cada intento. La ventana muestra el comando antes de correrlo, lo cual es un patrón de seguridad sano: transparencia total sobre lo que va a pasar.

Instalación: tres caminos

El repositorio en GitHub (epogonii/wisp) documenta tres formas de instalar la extensión. Elige según tu distribución y nivel de confianza:

# Camino 1: extensions.gnome.org (EGO)
# Visita https://extensions.gnome.org/extension/10755/wisp/
# Click en el switch ON/OFF - el sitio instala la extension via
# la integracion GNOME Shell + navegador.
# Camino 2: ZIP de release desde GitHub
# Descarga la ultima version (1.0.12 a sept-2026):
wget https://github.com/epogonii/wisp/releases/download/v1.0.12/wisp.zip
# Luego desde la app 'Extensions' (gnome-extensions app):
# o con gnome-extensions CLI:
gnome-extensions install --force wisp.zip
# Activala:
gnome-extensions enable [email protected]
# Camino 3: instalar desde fuentes
git clone https://github.com/epogonii/wisp.git
cd wisp
# El repo incluye tools/install-local.sh que pone los archivos
# en ~/.local/share/gnome-shell/extensions/[email protected]/
bash tools/install-local.sh
gnome-extensions enable [email protected]

Para que Wisp sea útil, tu sistema necesita tener Snapper configurado con al menos una config activa. En openSUSE esto viene por defecto (cada partición btrfs tiene su config). En Fedora Workstation con Btrfs hay que crear la config manualmente:

# Fedora con Btrfs como root (Workstation 33+)
# Verifica que tienes snapper:
sudo dnf install snapper
# Crea la config para root:
sudo snapper -c root create-config /
# Ajusta los permisos ALLOW_USERS para tu usuario (lo que Wisp hace
# automaticamente la primera vez que arranca, pero aqui el comando manual):
sudo snapper -c root set-config "ALLOW_USERS=$(whoami)" SYNC_ACL=yes
# Verifica que systemd timers estan corriendo:
sudo systemctl enable --now snapper-timeline.timer
sudo systemctl enable --now snapper-cleanup.timer

El problema del rollback en Fedora y la solución de Wisp 1.0.12

Una de las complicaciones que el autor resolvió recientemente (commit del 28 de septiembre de 2026, mismo día del anuncio de Phoronix) es que snapper no puede hacer rollback en un layout como el de Fedora. La razón es técnica: el subvolume por defecto de Fedora no es uno de los snapshots de snapper, así que el comando snapper undochange se rehúsa a trabajar sobre él.

El workaround que Wisp 1.0.12 implementa (en el commit 532548800fcca1775dadf6a1899eb69991d66050) es generar un comando que hace un swap de subvolumes: pone una copia escribible del snapshot elegido en el lugar del root, y mueve el root viejo a .snapshots con un info.xml válido para que snapper lo pueda gestionar después. Esto convierte el rollback en algo seguro incluso en Fedora, donde antes era imposible.

El diálogo de Wisp muestra ese comando antes de ejecutarlo. Si tienes /etc/fstab con subvolid= hardcodeado, el comando advierte que el rollback va a sobrescribir esa entrada (porque sino el siguiente boot ignora el nuevo default subvolume). Es la única advertencia seria: si tu fstab tiene subvolid=5 o usa defaults, no hay drama.

Rollback paso a paso desde Wisp

El flujo real cuando quieres volver a un estado anterior del sistema, una vez tienes Wisp instalado y un snapshot que te interesa:

# 1. Click en el icono de Wisp en el top bar
# 2. Busca el snapshot al que quieres volver (lista cronologica inversa)
# 3. Click en el snapshot para abrir su ventana de detalle
# 4. Click 'Roll back to this snapshot'
# 5. Wisp muestra el comando exacto que va a ejecutar, por ejemplo:
# btrfs subvolume snapshot /snapshots/N/snapshot /snapshots/N/root
# mv /snapshots/N/root /@old-$(date +%s)
# btrfs subvolume set-default $(btrfs subvolume list / | grep '@old' | awk '{print $2}')
# 6. Confirmas con pkexec (autenticacion root)
# 7. Wisp mueve el root viejo a /.snapshots y deja el nuevo default activo
# 8. Reinicias

El paso crítico es revisar tu /etc/fstab antes del rollback. Si tienes líneas como UUID=xxxx / btrfs subvol=root,subvolid=257,..., después del swap el subvolid hardcodeado va a apuntar al subvolume viejo (que ya no es default). Soluciones: o reescribes el fstab para usar subvol=/@ sin id, o documentas el id nuevo y lo actualizas después del reboot.

Comparación con btrfs-assistant

La alternativa más conocida hasta ahora era btrfs-assistant, una GUI en Qt que cubre funcionalidades similares. ¿Qué cambia con Wisp?

Característica	btrfs-assistant	Wisp
Lenguaje / toolkit	C++ / Qt5	JavaScript / GJS (GTK4)
Integración con GNOME Shell	App standalone, no top bar	Indicador en top bar + ventanas
Comunicación con Snapper	Línea de comandos	D-Bus principalmente
Soporte de rollback Fedora	Limitado, mismo problema que snapper CLI	Workaround con swap de subvolumes (v1.0.12)
Estilo visual	Qt tradicional	GTK4 + libadwaita, integra con tema del sistema
Permisos	pkexec por acción	D-Bus plano para lectura, pkexec solo para write
Estado del proyecto	Mantenimiento irregular, sin updates frecuentes	Activo, 98 commits, v1.0.12 hace días

Si ya usas GNOME Shell como escritorio principal, Wisp es claramente más coherente con el resto del sistema. Si prefieres KDE Plasma o XFCE, btrfs-assistant sigue siendo la opción más portable. Para servidores sin GUI, ninguna de las dos aplica: ahí el camino es snapper directo o scripts con btrfs send/receive.

Limitaciones y casos donde NO aplica

Wisp no es para todo el mundo. Cosas que debes saber antes de adoptarlo:

Solo GNOME 46 o superior: el manifiesto de extensiones lo declara explícitamente. Si usas GNOME 45 (Ubuntu 22.04 LTS, Debian 11), Wisp no carga.
Necesita snapper configurado: sin una config activa de snapper, la extensión no tiene nada que mostrar. En distros no-SUSE hay que crearla manualmente (ver bloque de instalación arriba).
No reemplaza btrbk o btrfs-snap: si prefieres gestionar snapshots con tus propios scripts o herramientas dedicadas, Wisp es redundante.
Subvolumes no-root: Wisp maneja la config de Snapper que apunta a /. Si tienes configs separadas para /home o /var, cada una necesita su ALLOW_USERS y aparecen como pestañas adicionales en la ventana de preferencias.
GNOME en Wayland y X11: ambos funcionan. El autor no menciona issues con ninguno de los dos.
Traducciones: la extensión está solo en inglés actualmente. po/wisp.pot existe pero ninguna .po ha sido contribuida todavía.

¿Vale la pena para ti?

Si llevas años usando Snapper desde la terminal y tu distro ya tiene Btrfs por defecto (openSUSE Tumbleweed, Fedora Workstation 33+, Endeavour, CachyOS, Garuda), Wisp te va a ahorrar teclear comandos sin sacrificar el control fino. La integración top-bar es cómoda y el diff entre snapshots es exactamente lo que necesitabas cuando rompiste algo y querías ver qué archivos se modificaron.

Si vienes de ZFS y nunca tocaste Snapper, no es la extensión la que te va a convencer: es una capa de conveniencia sobre una herramienta que probablemente ya conoces poco. Empieza por entender snapper list, snapper status y snapper undochange antes de instalar la GUI.

Si eres sysadmin y tus servidores no tienen GUI, Wisp no aplica. El camino profesional sigue siendo snapper + btrfs send/receive + cron. La extensión es para workstations y laptops de usuarios que quieren explorar el pasado de su sistema sin abrir una terminal cada vez.

Resumen

Wisp es una extensión GNOME Shell escrita en GJS que pone la gestión de snapshots Btrfs en la barra superior, usando Snapper como backend y D-Bus como canal de comunicación principal. La versión 1.0.12, publicada el 28 de septiembre de 2026, incluye el workaround de rollback con swap de subvolumes que antes era imposible en Fedora.

Para usarla necesitas GNOME 46+, Snapper con al menos una config activa, y permisos sobre esa config. La instalación más simple es desde extensions.gnome.org, pero si prefieres control total, el repo tiene un script install-local.sh que copia los archivos al directorio correcto.

Preguntas frecuentes

¿Por qué Wisp: nueva extensión GNOME para gestionar snapshots Btrfs de forma gráfica es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Wisp: nueva extensión GNOME para?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Wisp: nueva extensión GNOME para?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Wisp: nueva extensión GNOME para y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Wisp: nueva extensión GNOME para?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.