Nos complace anunciar la publicación de Synex 13 u12. Esta actualización concentra su trabajo en un frente: la recuperación del sistema. Synex Snapshots llega a la rama estable en su versión 0.5.0, con soporte nativo para ZFS además de Btrfs, integración con el gestor de arranque a través de dos herramientas nuevas y un paquete de integración para ZFSBootMenu. El instalador acompaña estos cambios con ajustes en su esquema de particionado.
Synex Snapshots 0.5.0: Btrfs, ZFS y recuperación desde el arranque
Cuando publicamos Synex Semi-rolling 26.08.17 presentamos por primera vez Synex Snapshots 0.1.0, entonces centrado exclusivamente en Btrfs. En aquel anuncio explicamos también una decisión que forma parte del modelo de desarrollo del proyecto: las herramientas nuevas llegan primero a Semi-rolling, acumulan pruebas y uso real y, una vez alcanzado el nivel de madurez esperado, pasan a Synex estable.
Luego de varios días de trabajo, Synex Snapshots 0.5.0 llega a Synex 13 u12 y el cambio respecto de aquella primera versión es considerable. Lo que comenzó como una aplicación para crear y restaurar snapshots Btrfs evolucionó hacia una capa de recuperación integrada al sistema, con implementaciones independientes para Btrfs y ZFS, automatización, recuperación desde el gestor de arranque y mecanismos específicos para trabajar de forma segura incluso cuando el sistema instalado ya no puede iniciar normalmente.
La aplicación detecta ahora el filesystem utilizado por el sistema raíz en el momento de iniciar y deriva la ejecución hacia el backend correspondiente. Btrfs y ZFS comparten una misma aplicación de cara al usuario, pero mantienen implementaciones separadas por debajo: las operaciones de ZFS utilizan sus mecanismos nativos y no intentan reproducir artificialmente el funcionamiento de Btrfs.
Btrfs: automatización y Snapshot Boot desde GRUB
La versión 0.1.0 ya permitía crear snapshots Single, correspondientes a un subvolumen individual, y Full, que representan el conjunto de subvolúmenes operacionales administrados. También incorporaba el modelo de restauración segura con validación previa, creación automática de un estado Pre-restore, reemplazo transaccional de los subvolúmenes y reinicio obligatorio después de restaurar.
Sobre esa base incorporamos ahora automatización de snapshots, con frecuencia y retención configurables. Los snapshots automáticos son Single del subvolumen raíz: ante una actualización problemática interesa poder recuperar el sistema sin retroceder también los datos actuales del usuario. Los snapshots Full permanecen disponibles como operación manual cuando se busca conservar el estado conjunto del sistema.
Pero uno de los cambios más importantes es la incorporación de grub-btrfs a los repositorios de Synex y su integración con Synex Snapshots.
Los snapshots que contienen el sistema raíz pasan a estar disponibles directamente desde GRUB, lo que permite iniciar un estado anterior incluso cuando la instalación normal dejó de arrancar. No se trata solamente de poder inspeccionarlo: una vez iniciado el snapshot, Synex Snapshots reconoce que está ejecutándose en modo Snapshot Boot, identifica los subvolúmenes canónicos del sistema instalado y permite restaurar directamente sobre ellos.
Esto habilita escenarios de recuperación mucho más severos que un simple cambio de configuración. Durante el desarrollo probamos restauraciones después de eliminar componentes críticos del sistema, incluyendo /etc, y adaptamos el proceso para que la recuperación pueda continuar incluso cuando el sistema dañado ya no dispone de un /etc/fstab utilizable.
El comportamiento del Snapshot Boot también respeta el tipo de snapshot seleccionado. Un Single del root utiliza los /home y /var/log actuales, mientras que un Full puede arrancar los subvolúmenes incluidos en el propio snapshot mediante OverlayFS, agregando una capa temporal de escritura sin modificar los snapshots originales de sólo lectura. Este modelo permite iniciar un estado histórico completo y, desde esa misma sesión, decidir si se lo quiere restaurar.
También se mantiene la protección de /boot cuando se encuentra en una partición ext4 independiente. En esos layouts Synex Snapshots conserva su contenido en un archivo .tar.zst validado y lo incorpora al proceso de recuperación, evitando tener que reparar posteriormente el arranque desde un sistema live y un chroot.
Finalmente, Synex Snapshots evita crear nuevos snapshots mientras el sistema está iniciado desde un Snapshot Boot. Las operaciones de recuperación permanecen disponibles, pero la herramienta distingue deliberadamente entre el sistema canónico y un entorno temporal de recuperación.
ZFS deja de ser solamente una opción de instalación
Synex 13 ya ofrecía ZFS como filesystem desde el instalador. Con u12 damos el siguiente paso: ZFS pasa a integrarse también con el sistema de snapshots y recuperación de Synex.
Synex Snapshots detecta dinámicamente el dataset raíz en ejecución y, a partir de él, descubre el árbol de datasets administrados. No depende de escribir nombres fijos de datasets en la aplicación, lo que permite adaptar la interfaz al layout real del sistema.
Los snapshots creados por Synex son snapshots ZFS nativos y almacenan su metadata mediante user properties de ZFS, incluyendo su estado administrado, propósito, scope, miembro, fecha de creación e identificador. La interfaz los organiza entre snapshots manuales, automáticos y aquellos creados por otras herramientas o directamente por el administrador.
La creación manual trabaja con snapshots Single por dataset. A diferencia de Btrfs, no incorporamos snapshots Full recursivos al flujo local de ZFS: preferimos conservar las propiedades naturales de su arquitectura y reservar las operaciones recursivas para futuros escenarios de replicación y send/receive.
La restauración utiliza directamente zfs rollback. Cuando el snapshot seleccionado es histórico, Synex Snapshots detecta primero si existen snapshots o bookmarks posteriores que ZFS deberá destruir para volver a ese punto. Sólo en ese caso utiliza el rollback recursivo y presenta previamente una advertencia explícita indicando qué historia posterior se perderá.
Cuando la restauración afecta al dataset raíz, el reinicio pasa a ser obligatorio y una segunda restauración queda bloqueada hasta que ese reboot ocurra. En cambio, la restauración de un dataset hijo puede completarse sin imponer un reinicio del sistema.
También incorporamos gestión manual de snapshots ZFS externos. Los snapshots que no fueron creados por Synex permanecen claramente separados en la interfaz y no entran en las políticas de Automation ni de retención, pero pueden ser restaurados o eliminados manualmente. La intención es convivir correctamente con snapshots creados desde la consola, ZFSBootMenu u otras herramientas, sin apropiarnos de ellos ni modificar su metadata.
Eliminación consciente de clones
ZFS agrega además una dificultad que no existe de la misma manera en Btrfs: un snapshot puede tener clones dependientes y eliminarlo puede implicar destruir también datasets derivados.
Synex Snapshots analiza esas dependencias antes de realizar una eliminación. Si existen clones, la interfaz muestra cuáles serán afectados, calcula el espacio que ZFS estima recuperar y exige una confirmación específica antes de realizar una destrucción recursiva.
La dependencia se vuelve a comprobar inmediatamente antes de ejecutar la operación. Si el estado cambió respecto de lo que el usuario confirmó, o si la eliminación pudiera afectar al root actualmente en ejecución, la operación se rechaza. No utilizamos una destrucción forzada para resolver silenciosamente dependencias.
Esta lógica se aplica tanto a snapshots administrados por Synex como a snapshots externos gestionados manualmente. La separación entre ambos se conserva; las garantías de seguridad de la operación, no.
Automation también llega a ZFS
El backend ZFS incorpora su propio sistema de automatización, independiente del existente para Btrfs.
Cada dataset puede disponer de su propia política y los datasets hijos pueden activarse individualmente o heredar la configuración definida para el root. Están disponibles políticas Hourly, Daily, Weekly y Monthly, además de un modo Frequent con intervalos configurables en minutos u horas.
La retención se aplica de forma independiente por dataset y sólo sobre snapshots automáticos; un snapshot manual nunca es eliminado por la política de Automation.
La ejecución se realiza mediante unidades propias de systemd y contempla recuperación después de períodos de inactividad, evita ejecuciones concurrentes y aísla los errores por dataset: una falla sobre un miembro no impide procesar correctamente los restantes.
También desarrollamos un modo dry-run que permite calcular el estado de las políticas, próximos vencimientos y eliminaciones previstas sin modificar ZFS.
Y, al igual que en Btrfs, existe una protección adicional cuando no estamos ejecutando el sistema canónico. Si el root actual es un clone ZFS derivado de un snapshot, Synex Snapshots pausa la creación automática y la retención hasta volver al dataset raíz normal. La aplicación continúa permitiendo las operaciones de recuperación que sean seguras, pero evita generar nueva historia desde un entorno temporal.
grub-zfs: snapshots ZFS directamente desde GRUB
La integración con ZFS no termina dentro de Synex Snapshots.
Durante este desarrollo creamos también grub-zfs, una nueva herramienta de Synex que integra los estados arrancables de ZFS directamente en GRUB.
El desafío era diferente al de Btrfs. OpenZFS ya dispone de zfs-initramfs y, cuando se inicia un snapshot, su comportamiento nativo consiste en crear un clone RW derivado de ese snapshot. Decidimos conservar ese funcionamiento en lugar de reemplazarlo.
grub-zfs organiza en un único submenú tres tipos de entradas claramente diferenciadas:
[Synex]identifica snapshots administrados por Synex Snapshots.[External]identifica snapshots del root creados fuera de Synex que reúnen las condiciones necesarias para arrancar.[RW Clone]identifica los clones escribibles generados a partir de snapshots.
La diferencia del último grupo resulta especialmente útil. Si un usuario inicia un snapshot, ZFS crea su clone RW y permite trabajar sobre él. Al regresar posteriormente al sistema canónico, grub-zfs puede detectar ese clone y ofrecerlo como una entrada independiente. Al arrancar directamente el clone, los cambios realizados allí se conservan.
Esto permite utilizar un snapshot para crear rápidamente un entorno aislado de prueba y después continuar entrando al mismo estado RW mientras el clone exista.
grub-zfs carga para cada objeto su conjunto coherente de kernel, initrd y módulos, en lugar de asumir que todos los estados comparten necesariamente el kernel del sistema actualmente instalado.
Al mismo tiempo, mantuvimos deliberadamente un límite: grub-zfs no pretende convertirse en un gestor completo de Boot Environments. No incorporamos operaciones como Promote, Duplicate ni administración compleja de árboles de clones. El desarrollo dejó precisamente más claro dónde termina la recuperación integrada de Synex y dónde resulta conveniente utilizar una herramienta especializada. El roadmap de u12 definió esa separación expresamente.
ZFSBootMenu integrado a Synex
Y para esa capa especializada incorporamos finalmente synex-zfsbootmenu.
ZFSBootMenu es una solución específica para gestionar y arrancar Boot Environments sobre ZFS. En lugar de intentar reproducir dentro de Synex Snapshots todo lo que este proyecto ya hace correctamente, desarrollamos un paquete de integración para utilizarlo de forma sencilla en Synex.
La instalación es deliberadamente conservadora. synex-zfsbootmenu funciona exclusivamente sobre sistemas ZFS arrancados mediante UEFI, obtiene directamente desde upstream la imagen oficial fijada de ZFSBootMenu 3.1.0, verifica obligatoriamente su SHA-256 antes de utilizarla y conserva una copia local verificada para futuras reinstalaciones.
Una vez validada, instala la imagen en la partición EFI, crea o reutiliza una entrada NVRAM denominada ZFSBootMenu y la coloca primero en el orden de arranque.
Y hay una decisión importante: no reemplaza ni elimina GRUB.
La entrada existente de Synex permanece intacta como fallback. El resultado es:
UEFI├── ZFSBootMenu└── Synex / GRUB
Si el paquete se elimina, retira su entrada NVRAM y el EFI desplegado, dejando nuevamente Synex como opción normal de arranque. Una eliminación convencional conserva la copia local verificada para que una posterior reinstalación no necesite descargar nuevamente la imagen; un purge elimina también ese archivo.
El paquete tampoco modifica bootfs, propiedades org.zfsbootmenu ni transforma los datasets existentes. Esta fue una decisión deliberada: las pruebas mostraron que el layout ZFS generado por Synex ya puede ser interpretado por ZFSBootMenu sin preparaciones especiales.
Tres capas, cada una haciendo su trabajo
Con u12 terminamos definiendo una arquitectura que preferimos a intentar resolverlo todo dentro de una sola aplicación.
- Synex Snapshots administra snapshots, restauración y automatización.
- grub-btrfs y grub-zfs integran la recuperación cotidiana directamente en GRUB.
- ZFSBootMenu queda disponible para quienes quieran una administración más avanzada de Boot Environments.
La idea detrás de las tres capas es la misma: simplificar la recuperación sin ocultar ni reemplazar los mecanismos nativos de cada filesystem.
Synex Snapshots no pretende convertir los snapshots en backups —continúan viviendo en el mismo almacenamiento y una falla física sigue requiriendo una estrategia de backup real—, pero sí busca que volver a un estado anterior deje de ser una operación reservada a quien conoce de memoria comandos de Btrfs, ZFS, initramfs o GRUB.
En la práctica, Synex 13 u12 convierte esa idea en uno de los cambios más grandes que hemos incorporado hasta ahora al sistema.
El instalador acompaña los cambios
calamares-settings-synex avanza a la versión 1.0.30 con ajustes que derivan directamente del trabajo sobre snapshots.
El cambio de mayor alcance está en el esquema de particionado automático: se eliminó la partición /boot separada. Ese layout existía para dar soporte a instalaciones cifradas con LUKS2, dado que GRUB no puede leer directamente un volumen LUKS2, pero imponía una partición adicional a la totalidad de las instalaciones para cubrir un caso minoritario. Con /boot dentro del sistema raíz, los snapshots del root en Btrfs y ZFS abarcan también /boot sin necesidad de tratarlo por separado.
En consecuencia, el cifrado LUKS2 pasa a realizarse desde el particionado manual. Quien necesite una instalación cifrada con LUKS2 puede crear allí su propia partición /boot en ext4, que es el esquema que esa configuración requiere de todas formas. Los layouts con /boot separado siguen contemplados por Synex Snapshots, que conserva su contenido en un archivo comprimido validado durante la recuperación.
El instalador incorpora además procesos que ajustan el sistema resultante al filesystem elegido. Si la instalación no utiliza ZFS, se eliminan los paquetes de ZFS junto con sus dependencias huérfanas; si no utiliza Btrfs, se elimina grub-btrfs; y si no utiliza ninguno de los dos, se elimina también Synex Snapshots. Una instalación sobre ext4 o XFS no arrastra así herramientas que no puede aprovechar. En los pools ZFS creados por el instalador se activa autotrim.
Actualizaciones del sistema
Esta versión incluye todas las actualizaciones acumulativas de paquetes disponibles en los repositorios de Debian Trixie hasta la fecha de construcción, con kernel Linux 6.12.107, systemd 257.13, OpenSSL 3.5.7, ZFS 2.3.9, btrfs-progs 6.14, Mesa 25.0.7, PipeWire 1.4.2 con WirePlumber 0.5.8, Firefox ESR 140.15.0 y Flatpak 1.16.6. La instalación se realiza con Calamares 3.3.14 y calamares-settings-synex 1.0.30, y todas las ediciones incluyen Synex Package Manager 1.2.3, Synex Snapshots 0.5.0, grub-btrfs 4.14+git20260805-1synex1 y grub-zfs 0.1.0.
Por edición: KDE Plasma 6.3.6 con KDE Applications 25.04.3; GNOME 48.7 con GDM3 48.0 y Nautilus 48.3; XFCE 4.20, con xfce4-panel 4.20.4, xfce4-session 4.20.2, xfwm4 4.20.0 y Thunar 4.20.2; MATE, con mate-panel 1.27.1, Marco 1.26.2 y Caja 1.26.4; LXDE 13.0, con lxpanel 0.11.1, lxsession 0.5.6 y PCManFM 1.4.0; IceWM 3.7.4; Openbox 3.6.1 con tint2 17.0.1; y COSMIC Epoch 1.3.0.
Una nota sobre el conjunto de paquetes
Durante la preparación de estas imágenes revisamos en detalle el conjunto de paquetes de cada edición y encontramos que el paquete de fondos de pantalla utilizado en la edición COSMIC declaraba GNOME Shell como dependencia dura, arrastrando por esa vía un conjunto de componentes de GNOME que esa edición no utiliza. Fue reemplazado por un paquete unificado de fondos sin esa dependencia, lo que reduce el tamaño del conjunto instalado en COSMIC.
Ese trabajo dejó expuesta también una dependencia implícita del lanzador de Calamares, que utilizaba xhost para el control de acceso al servidor gráfico y lo recibía indirectamente a través de uno de los paquetes retirados. La corrección ejecuta Calamares como cliente Wayland nativo en COSMIC, eliminando esa necesidad. El cambio ya está desarrollado y probado, y se distribuirá con la próxima actualización del paquete.
Disponibilidad
Synex 13 u12 está disponible para descarga inmediata en las ediciones KDE Plasma, GNOME, XFCE, MATE, LXDE, IceWM, Openbox y COSMIC. Como siempre, recomendamos verificar las sumas de comprobación de las imágenes descargadas antes de crear el medio de instalación.
Descargá Synex 13 u12 desde aquí.