ZFS zpool checkpoint: El botón de deshacer de emergencia (con aristas afiladas)

Hay dos tipos de ingenieros de almacenamiento: los que han necesitado una marcha atrás de emergencia y los que aún no la han necesitado todavía. ZFS zpool checkpoint es esa marcha atrás: un punto de “deshacer” a nivel de pool que puede revertir el estado en disco de un pool a un momento en el tiempo. No es una copia de seguridad. No es un snapshot. Ni siquiera es particularmente indulgente. Pero en la ventana correcta, puede convertir un error que limite tu carrera en un ticket de cambio algo vergonzoso.

Si tratas los checkpoints como una “seguridad gratuita”, eventualmente descubrirás su truco favorito: hacer que el espacio desaparezca justo cuando más lo necesitas. Esta es una herramienta operativa, no una manta de consuelo. Hablemos de cómo funciona, para qué sirve, por qué es peligrosa y cómo usarla en producción sin convertirte en anécdota.

Qué es un zpool checkpoint (y qué no es)

Un checkpoint de un pool ZFS es un marcador especial almacenado en los metadatos del pool que te permite revertir todo el pool al estado exacto en disco en el momento en que se tomó el checkpoint. No «restaurar algunos archivos». No «revertir un solo dataset». Todo el pool: datasets, snapshots, punteros de bloques, asignaciones—todo.

Los checkpoints se entienden mejor como un «botón de rebobinado a nivel de pool» que se sostiene en la naturaleza copy-on-write (CoW) de ZFS. Después de crear un checkpoint, ZFS debe preservar el estado antiguo para poder reconstruirlo. Eso significa que los bloques que antes estaban libres ya no pueden reutilizarse si deben mantenerse para que el checkpoint sea consistente. La consecuencia práctica es brutal: un checkpoint puede inmovilizar espacio. En un pool ocupado, ese espacio inmovilizado puede crecer rápidamente, y lo hace de la peor manera posible: silenciosamente, hasta que deja de ser silencioso.

Qué es

• Un punto de reversión a nivel de pool para los metadatos y datos de todo el pool.
• Un checkpoint a la vez (por pool), no una pila ilimitada.
• Una herramienta táctica para operaciones riesgosas: actualizaciones de pool, coreografía de reemplazo de dispositivos, cambios de características en disco, refactorizaciones mayores.

Qué no es

• No es una copia de seguridad. Si el pool se pierde, el checkpoint se pierde con él.
• No es un snapshot de dataset. Los snapshots son por dataset y pueden enviarse/recibirse; los checkpoints no pueden.
• No es selectivo. No puedes revertir un dataset y mantener otros “como ahora”.

Primera broma (como prometí, corta): Un checkpoint es como “deshacer” en un editor de texto—excepto que también deshace los cambios de tu compañero, los cambios del pipeline CI y tus últimas dos horas de cordura.

Por qué existen los checkpoints: breve historia y algunos datos

Los checkpoints parecen una comodidad moderna, pero están arraigados en verdades antiguas de ZFS: los metadatos son sagrados y CoW es tanto una superpotencia como una responsabilidad. Aquí hay algunos datos y puntos de contexto que ayudan a explicar por qué existen los checkpoints y por qué tienen esa forma.

1. La promesa original de ZFS (era mediados de los 2000) fue “integridad de datos de extremo a extremo”, y CoW es un mecanismo central: las escrituras nuevas no sobrescriben bloques antiguos; asignan bloques nuevos y luego cambian punteros de forma atómica.
2. Las flags de características del pool evolucionaron a medida que ZFS abandonó su ecosistema de proveedor original y se difundió entre implementaciones. Algunas características están “activas” solo una vez usadas; otras cambian cómo se comportan las estructuras en disco. Revertir después de habilitar o usar características puede ser complicado.
3. zpool upgrade solía dar más miedo cuando la activación de características era menos transparente para los operadores. Los checkpoints llegaron como una red de seguridad para momentos de “actualicé y ahora me arrepiento”.
4. Los snapshots son baratos hasta que dejan de serlo: a medida que proliferaron los snapshots, los operadores aprendieron que “barato” se refiere a metadatos, no a bloques inmovilizados para siempre en un dataset con alta rotación. Los checkpoints tienen la misma física—solo que a escala de pool.
5. La contabilidad de espacio en ZFS es sutil. “df dice mucho libre” no es lo mismo que “ZFS puede asignar”. Los checkpoints añaden otra razón por la que esos números pueden divergir.
6. La alta fragmentación es sobrevivible, pero la alta fragmentación estando casi lleno es donde los pools se vuelven inestables en términos operativos (lentos, propensos a fallos). Los checkpoints pueden empujarte más cerca de ese precipicio.
7. El límite de un checkpoint es intencional: el pool ya tiene que preservar el estado anterior; apilar múltiples estados históricos a escala de pool amplificaría el espacio inmovilizado y la complejidad.
8. La herramienta operativa creció alrededor de la realidad de que los cambios en producción son desordenados: reemplazos de dispositivos, desajustes de ashift, flags de características, comandos destructivos accidentales. Los checkpoints existen porque los humanos existen.

Cómo funcionan los checkpoints internamente

Puedes operar con checkpoints de forma segura sin leer el código fuente de ZFS, pero necesitas un modelo mental. Aquí está el modelo que se corresponde con síntomas del mundo real.

El checkpoint es una “raíz de pool guardada”

ZFS tiene el concepto de un estado del pool enraizado en estructuras de metadatos (piensa en un “uberblock” como uno de los puntos de entrada a “qué es el pool ahora”). Un checkpoint preserva efectivamente una raíz anterior para que ZFS pueda recorrer el árbol antiguo de punteros de bloques y reconstruir la vista antigua.

Por qué el espacio desaparece: los bloques dejan de ser reutilizables

Debido a que ZFS es CoW, el checkpoint no necesita copiar todo el pool. Solo necesita que los bloques antiguos sigan siendo accesibles. Pero si modificas datos después del checkpoint, ZFS escribe bloques nuevos. Los bloques antiguos siguen referenciados por el checkpoint y, por lo tanto, no se pueden liberar. Si borras datos después del checkpoint, te sentirás estafado: “Borré 20 TB, ¿por qué no recuperé espacio?” Porque desde el punto de vista del checkpoint, esos datos aún existen y deben poder restaurarse.

El rollback no es magia—es una detonación controlada

Revertir a un checkpoint descarta todo lo que ocurrió después: todas las escrituras, todos los borrados, todos los cambios de dataset y cualquier progreso operacional que haya tocado el estado en disco. También puede interactuar con características y operaciones de dispositivos de formas que requieren planificación. El pool vuelve a su estado topológico anterior tal como se registró en el momento del checkpoint, no como te gustaría que fuese.

Las aristas afiladas

• Pools casi llenos: un checkpoint puede llevarte a condiciones de “sin espacio” más rápido de lo que puedes reaccionar.
• Pools ocupados: la rotación inmoviliza bloques rápidamente; el “coste” de un checkpoint puede inflarse en horas.
• Coordinación humana: debes tratar el periodo con checkpoint como una ventana de congelación de cambios para ciertas acciones, o crearás minas que detonarán al intentar revertir.

Segunda broma (también corta): Usar un checkpoint sin monitorización es como pedir prestado un paracaídas sin revisar las correas—técnicamente estás más seguro, hasta que la física tenga otra opinión.

Cuándo usar un checkpoint (y cuándo no)

Buenos casos de uso

1) Antes de un cambio arriesgado a nivel de pool que no puedes deshacer fácilmente. Ejemplos: habilitar una característica que cambia el uso del formato en disco, realizar una actualización de pool en un entorno donde podrían exigir revertir, o ejecutar una secuencia inusual de operaciones de dispositivos.

2) Antes de una operación quirúrgica donde “deshacer los últimos 30 minutos” importa. Piensa en una ventana de mantenimiento donde ejecutarás comandos que pueden dejar la configuración del pool inservible si tecleas mal.

3) Antes de un experimento en un pool no replicado. A veces tienes un pool de laboratorio que se comporta como producción y necesitas un único “rebobinado” seguro.

Malos casos de uso

1) Como sustituto de backups o replicación. Si el pool se pierde, el checkpoint se pierde.

2) Como una red de seguridad de larga duración. Un checkpoint que “dejas por una semana por si acaso” es una forma clásica de descubrir que tu pool puede quedarse sin espacio mientras los paneles aún lucen bien.

3) En pools que ya están justos de espacio libre. Si tienes presión sobre el espacio libre, un checkpoint convierte “ajustado” en “frágil.” Aún podrías hacerlo, pero tu plan debe incluir monitorización activa, una fecha límite firme y una vía rápida de aborto (descartar el checkpoint).

Regla práctica

Si no estarías cómodo operando con efectivamente menos espacio libre del que tienes ahora, no crees un checkpoint sin antes crear ese margen. El checkpoint en sí no necesariamente consume espacio de inmediato; consume tu capacidad de recuperar espacio liberando bloques.

Tareas prácticas: comandos, salidas, interpretación

A continuación hay tareas operativas reales que puedes ejecutar en un sistema típico Linux + OpenZFS. Algunas salidas varían según la versión, las características del pool y la plataforma, pero la intención y la interpretación se mantienen. Los comandos asumen que el pool se llama tank.

Tarea 1: Confirmar la salud del pool antes de hacer cualquier cosa

cr0x@server:~$ sudo zpool status -xv tank
pool 'tank' is healthy

Interpretación: Si el pool no está sano, no añadas “complejidad de checkpoint” a una situación ya inestable. Repara fallos, completa resilvers y aborda errores primero.

Tarea 2: Registrar un estado “antes” para tu ticket de cambio

cr0x@server:~$ date -Is
2025-12-25T10:18:44+00:00
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:14:19 with 0 errors on Thu Dec 19 03:10:14 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0

errors: No known data errors

Interpretación: Guarda esta salida con el registro de cambio. En respuesta a incidentes, la diferencia entre “creíamos que estaba bien” y “aquí está el estado a las 10:18 UTC” puede ser horas.

Tarea 3: Comprobar espacio libre y señales de riesgo por fragmentación

cr0x@server:~$ sudo zpool list -o name,size,alloc,free,capacity,fragmentation,health tank
NAME  SIZE  ALLOC   FREE  CAP  FRAG  HEALTH
tank  72T   58.2T  13.8T  80%   41%  ONLINE

Interpretación: 80% lleno con 41% de fragmentación es manejable, pero no es “más que suficiente.” Un checkpoint puede hacer que los borrados dejen de ayudar. Si ya estás por encima de ~85–90% de capacidad, trata un checkpoint como peligroso.

Tarea 4: Verificar si ya existe un checkpoint

cr0x@server:~$ sudo zpool get checkpoint tank
NAME  PROPERTY    VALUE       SOURCE
tank  checkpoint  -           -

Interpretación: Un valor de - significa que no hay checkpoint presente. Si ves una marca temporal o un valor no vacío, ya tienes uno y debes decidir si mantenerlo, descartarlo o revertir a él.

Tarea 5: Crear un checkpoint (y registrar exactamente cuándo lo hiciste)

cr0x@server:~$ sudo zpool checkpoint tank
cr0x@server:~$ sudo zpool get checkpoint tank
NAME  PROPERTY    VALUE                        SOURCE
tank  checkpoint  2025-12-25T10:22:11+00:00    -

Interpretación: Esa marca temporal es tu “punto de no retorno” para todo lo que ocurra después. Anótala donde los humanos la vean, no solo en el historial del shell.

Tarea 6: Observar el comportamiento del espacio inmovilizado mediante liberación de datos (la prueba “¿por qué no aumentó el espacio libre?”)

cr0x@server:~$ sudo zfs destroy -r tank/tmp/testdata
cr0x@server:~$ sudo zpool list -o name,alloc,free,capacity tank
NAME  ALLOC   FREE  CAP
tank  58.2T  13.8T  80%

Interpretación: Si alloc/free apenas se mueven después de un gran borrado y tienes un checkpoint, has aprendido la verdad operativa clave: los borrados no necesariamente compran margen hasta que el checkpoint desaparece.

Tarea 7: Comprobar la vista de espacio a nivel de dataset para evitar el “pánico de df”

cr0x@server:~$ df -h /tank
Filesystem      Size  Used Avail Use% Mounted on
tank            72T   58T   14T  81% /tank

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  58.2T  12.9T   256K  /tank

Interpretación: df y zfs list a menudo coinciden a nivel superior, pero durante periodos con checkpoint puedes encontrar situaciones donde el comportamiento de las aplicaciones sugiere “sin espacio” antes de lo esperado porque las realidades de asignación de ZFS se vuelven más estrictas que lo que el espacio de usuario espera.

Tarea 8: Confirmar que no activaste accidentalmente algo que no puedes revertir

cr0x@server:~$ sudo zpool get all tank | egrep 'feature@|compatibility|readonly'
tank  readonly                off                    default
tank  compatibility           off                    default
tank  feature@async_destroy   enabled                local
tank  feature@spacemap_histogram  active             local
tank  feature@extensible_dataset  enabled            local

Interpretación: “Enabled” significa disponible; “active” significa usado en el estado en disco. Un checkpoint puede ayudarte a revertir algunas categorías de “cambié de opinión”, pero la activación de características puede complicar la interoperabilidad y las rutas de degradado. No adivines—inspecciona.

Tarea 9: Simular tu decisión de rollback enumerando “qué se perdería”

cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -s creation | tail -n 5
tank/home@autosnap_2025-12-25_0900  Thu Dec 25 09:00 2025
tank/home@autosnap_2025-12-25_1000  Thu Dec 25 10:00 2025
tank/db@prechange_2025-12-25_1015     Thu Dec 25 10:15 2025
tank/db@postchange_2025-12-25_1030    Thu Dec 25 10:30 2025
tank/logs@hourly_2025-12-25_1100      Thu Dec 25 11:00 2025

Interpretación: Los snapshots creados después del checkpoint se perderán si reviertes el pool. Toma la decisión de rollback con los ojos abiertos y avisa a las partes interesadas: “perderás todo desde las 10:22”.

Tarea 10: Revertir al checkpoint (el gran martillo)

cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import tank
cr0x@server:~$ sudo zpool checkpoint -r tank

Interpretación: Revertir es disruptivo y debe tratarse como un evento de mantenimiento. Export/import no siempre es estrictamente necesario para el rollback, pero en la práctica es una manera limpia de asegurar que los servicios estén abajo, los mounts en reposo y no estés revirtiendo bajo escrituras activas. Después del rollback, típicamente el checkpoint se borra porque has vuelto a él.

Tarea 11: Descartar el checkpoint (comprometerte con el mundo nuevo y reclamar la reutilización)

cr0x@server:~$ sudo zpool checkpoint -d tank
cr0x@server:~$ sudo zpool get checkpoint tank
NAME  PROPERTY    VALUE  SOURCE
tank  checkpoint  -      -

Interpretación: Este es el paso de “terminamos, mantened los cambios”. Operacionalmente, descartar suele ser la acción de checkpoint más importante—porque restaura la reutilización normal del espacio. Establece una fecha límite para este paso cuando crees el checkpoint.

Tarea 12: Vigilar la presión de espacio mientras exista un checkpoint

cr0x@server:~$ watch -n 5 'zpool list -o name,alloc,free,capacity,fragmentation tank; echo; zpool get checkpoint tank'
Every 5.0s: zpool list -o name,alloc,free,capacity,fragmentation tank; echo; zpool get checkpoint tank

NAME  ALLOC   FREE  CAP  FRAG
tank  60.1T  11.9T  83%  44%

NAME  PROPERTY    VALUE                        SOURCE
tank  checkpoint  2025-12-25T10:22:11+00:00    -

Interpretación: Si alloc sube mientras tu cambio está en ejecución, podrías estar inmovilizando bloques antiguos y creando nuevos. Un aumento de capacidad durante una ventana con checkpoint es normal; un aumento hacia el precipicio es una razón para abortar temprano descartando el checkpoint o pausando la rotación.

Tarea 13: Identificar escritores pesados durante la ventana de checkpoint

cr0x@server:~$ sudo zpool iostat -v tank 5 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        60.1T  11.9T      5    802  1.20M   210M
  raidz1-0                  60.1T  11.9T      5    802  1.20M   210M
    sda                         -      -      1    270   410K  70.2M
    sdb                         -      -      2    265   420K  69.1M
    sdc                         -      -      2    267   370K  70.7M
--------------------------  -----  -----  -----  -----  -----  -----

Interpretación: Alta banda de escritura durante la ventana de checkpoint significa que estás acumulando datos del “mundo nuevo” mientras inmovilizas datos del “mundo antiguo”. Si quieres que el checkpoint siga siendo barato, minimiza la rotación de escrituras.

Tarea 14: Validar puntos de montaje y salud de datasets después de descartar/revertir

cr0x@server:~$ sudo zfs mount -a
cr0x@server:~$ sudo zfs list -o name,mounted,available,used,mountpoint tank | head
NAME       MOUNTED  AVAIL  USED  MOUNTPOINT
tank       yes      12.9T  60.1T /tank
tank/home  yes      12.9T   8.4T /tank/home
tank/db    yes      12.9T  44.0T /tank/db

Interpretación: Después de un rollback, no asumas que los servicios volverán limpios. El estado de los mounts y la disponibilidad de los datasets son las primeras comprobaciones de “¿está sano el almacenamiento?” antes de reiniciar bases de datos o hypervisores.

Guion de diagnóstico rápido: cuando el pool se siente “raro”

Esta es la lista de verificación de “son las 02:00 y algo anda mal”. El objetivo es identificar si el checkpoint contribuye al síntoma y si estás frente a un cuello de botella de espacio, I/O o fragmentación.

Primero: establece si existe un checkpoint y cuánto tiempo lleva

cr0x@server:~$ sudo zpool get checkpoint tank
NAME  PROPERTY    VALUE                        SOURCE
tank  checkpoint  2025-12-25T10:22:11+00:00    -

Si tienes un checkpoint: trata las anomalías de espacio como “checkpoint hasta que se demuestre lo contrario”. Si no, procede con la triaje normal de ZFS.

Segundo: comprueba el margen real del pool y señales de alerta

cr0x@server:~$ sudo zpool list -o name,alloc,free,capacity,fragmentation,health tank
NAME  ALLOC   FREE  CAP  FRAG  HEALTH
tank  60.1T  11.9T  83%  44%   ONLINE

Qué buscas: capacidad acercándose al 90% mientras existe un checkpoint; fragmentación en ascenso; estado distinto de ONLINE.

Tercero: identifica si estás limitado por IOPS, por ancho de banda o por otra cosa

cr0x@server:~$ sudo zpool iostat -v tank 2 5
cr0x@server:~$ sudo zpool status -v tank

Interpretación:

• Altas escrituras + poco espacio libre: te diriges hacia territorio de “fallo de asignación”. Decide rápido: descartar checkpoint, pausar escritores o añadir espacio.
• Síntomas de latencia de lectura altos: el checkpoint no suele ser la causa directa, pero se correlaciona con periodos de alta rotación y fragmentación, lo que puede amplificar la latencia.
• Errores o resilver en curso: no revirtieras a la ligera durante actividad de fallo de dispositivo. Estabiliza primero a menos que el rollback sea la única salida.

Cuarto: verifica si los borrados “funcionan”

cr0x@server:~$ sudo zpool list -o alloc,free,capacity tank
ALLOC   FREE  CAP
60.1T  11.9T  83%

Interpretación: Si borras datasets grandes y free no se mueve durante una ventana con checkpoint, no sigas borrando en pánico. No estás ganando pista de aterrizaje; solo estás haciendo que el mundo post-checkpoint sea más extraño.

Tres mini-historias del mundo corporativo

1) El incidente causado por una suposición equivocada

Tenían un almacén de backing para un clúster de virtualización en un gran pool ZFS. El equipo de almacenamiento planeó un cambio de flag de característica y, intentando ser responsables, crearon un checkpoint “por si acaso”. La ventana de mantenimiento fue tranquila. El cambio pareció bien. Todos se fueron a casa.

Dos días después, comenzaron las alertas: VMs fallando escrituras de forma intermitente, luego una cascada de comportamientos de “sistema de archivos en solo lectura” en invitados. El on-call vio “15 TB libres” en los paneles y asumió que no podía ser un problema de espacio. Persiguieron fantasmas: multipath, firmware HBA, un SSD SLOG sospechoso. Todo parecía en su mayoría normal.

Lo que realmente sucedió fue más simple y más cruel. Durante esos dos días, el pool churned: imágenes de VM, logs, rotación de bases de datos dentro de los invitados. El checkpoint inmovilizó una cantidad creciente de bloques antiguos, y los borrados/reclaims no ayudaban. El pool no estaba fuera de espacio según la métrica ingenua de “libre”, pero se estaba volviendo hostil a las asignaciones: la fragmentación subió, las metaslabs con segmentos libres se volvieron menos útiles, y las operaciones que requerían asignaciones más o menos contiguas empezaron a fallar bajo carga.

La suposición equivocada fue pensar que un checkpoint es “gratis hasta que lo reviertes”. No lo es. Es una restricción viva sobre la reutilización de espacio. Descartaron el checkpoint y el comportamiento del espacio volvió a la normalidad en la hora siguiente. La acción del postmortem fue clara: los checkpoints deben tener un propietario y un tiempo de expiración, y la monitorización debe alertar “checkpoint más antiguo de X horas” igual que alerta sobre un vdev degradado.

2) La optimización que salió mal

Un equipo de plataforma decidió reducir el riesgo de mantenimiento estandarizando un flujo de trabajo: “checkpoint antes de cada cambio de almacenamiento”. Sonaba a madurez. El calendario de cambios se hizo más ocupado, así que los checkpoints se volvieron frecuentes. Alguien incluso lo automatizó: cuando un ticket de cambio se aprueba, la automatización crea el checkpoint y publica la marca temporal en el hilo de chat.

Luego llegó el contragolpe. Usaban el mismo pool tanto para bases de datos críticas como para una carga analítica grande que reescribía toneladas de datos a diario. Durante un reemplazo de dispositivo rutinario, se creó un checkpoint y se dejó en su lugar más tiempo del esperado porque el proveedor envió un modelo de disco equivocado y pospusieron el resto del trabajo. Mientras tanto, el analytics seguía golpeando el pool.

El pool no falló. Hizo algo peor: se ralentizó de una manera que no era inmediatamente atribuible. La latencia subió, las ventanas de replicación se retrasaron, y el equipo de bases de datos empezó a limitar sus propias cargas para mantener la latencia de cola aceptable. El equipo de almacenamiento miró el checkpoint y pensó: “No revertimos, así que no debería importar.” Pero importaba porque el checkpoint hacía que el pool cargara dos realidades a la vez. Las escrituras seguían asignando nuevos bloques mientras los antiguos quedaban inmovilizados. Los mapas de espacio se volvieron más complejos, la fragmentación subió y el pool se comportó como si fuera más viejo y más lleno de lo que realmente era.

La solución fue cultural: los checkpoints se convirtieron en una herramienta usada solo para cambios con valor real de reversión, no para cada operación rutinaria. Reemplazaron “checkpoint en todas partes” por “checkpoint cuando la reversión cambia significativamente el riesgo” y lo emparejaron con snapshots de datasets de corta vida para cambios menores. La optimización falló porque optimizó por la métrica equivocada: seguridad percibida, no estabilidad operativa.

3) La práctica aburrida pero correcta que salvó el día

Un sistema ligado a finanzas tenía un proceso de cambio estricto: cada cambio de almacenamiento requería una lista de verificación previa, una ventana de mantenimiento y un “plan de reversión” escrito en lenguaje llano. Era lo suficientemente aburrido como para que los ingenieros se quejaran—en voz baja, porque los sistemas financieros tienden a ganar argumentos por existir.

Durante una actualización planificada del pool, crearon un checkpoint e inmediatamente fijaron un recordatorio interno en el calendario: “Descartar checkpoint al final de la ventana a menos que se necesite revertir.” También pusieron una barrera en la monitorización: si existe un checkpoint por más de cuatro horas, que se haga page al on-call y al propietario del cambio. No era elegante, solo propiedad explícita y un temporizador.

A mitad de la ventana, un ingeniero de almacenamiento notó un servicio comportándose raro. No fallando, solo “descolocado”. Como el plan de reversión ya estaba escrito, no improvisaron. Pausaron servicios dependientes, exportaron el pool, lo reimportaron limpiamente, revirtieron al checkpoint y restauraron el servicio. La revisión posterior encontró una interacción de configuración que habría sido dolorosa de deshacer manualmente.

La salvación no fue solo el checkpoint: fue la disciplina a su alrededor: silenciar escrituras, tener una fecha límite y tratar el rollback como una operación planificada en lugar de una reacción emocional. Lo aburrido está subestimado en almacenamiento.

Errores comunes (con síntomas y soluciones)

Error 1: Crear un checkpoint en un pool casi lleno

Síntomas: la capacidad del pool sube rápidamente; los borrados no recuperan espacio; las aplicaciones empiezan a lanzar ENOSPC o “disco lleno” pese a las expectativas de “espacio libre”; la fragmentación aumenta.

Solución: si el rollback ya no es necesario, descarta el checkpoint. Si el rollback aún puede ser necesario, pausa cargas de alta rotación y añade margen (vdevs adicionales o migración temporal). En una crisis, prioriza reducir la rotación sobre borrar datos—los borrados están inmovilizados de todas formas.

Error 2: Dejar un checkpoint “por si acaso”

Síntomas: presión de espacio de combustión lenta que no se correlaciona con el crecimiento visible de datos; degradación de rendimiento a largo plazo en cargas de escritura aleatoria.

Solución: aplica una política de expiración. Operativamente: el checkpoint debe tener un propietario humano, una fecha de eliminación y monitorización que alerte por antigüedad.

Error 3: Asumir que los checkpoints se comportan como snapshots

Síntomas: alguien espera restaurar un solo dataset; alguien intenta “enviar” un checkpoint; confusión sobre lo que se perderá.

Solución: educa con una regla: los snapshots son por dataset; los checkpoints abarcan todo el pool. Usa snapshots para “quiero mi directorio de vuelta”. Usa checkpoints para “quiero mi pool de vuelta”.

Error 4: Revertir sin quiescer las escrituras

Síntomas: los servicios vuelven corruptos a nivel de aplicación; las bases de datos requieren recuperación; las VMs pueden tener discos inconsistentes; se culpa a ZFS de forma confusa.

Solución: trata el rollback como restaurar una imagen de capa de almacenamiento: detén servicios, vacía buffers, desmonta donde sea posible, exporta/importa para asegurar que no haya escritores. Luego revierte. ZFS hará lo que pediste; las aplicaciones harán lo que la física permita.

Error 5: Olvidar que el rollback descarta progreso operacional

Síntomas: un reemplazo de dispositivo “desaparece”, un cambio de topología se revierte o una migración cuidadosamente planificada se deshace.

Solución: documenta exactamente qué acciones ocurrieron después del checkpoint. Si reemplazaste un disco tras el checkpoint, revertir puede volver a la vista topológica anterior, lo que puede confundir operaciones posteriores. Planifica pasos de rollback, no solo el comando.

Error 6: Interpretar “espacio libre” como “espacio asignable” bajo presión

Síntomas: “todavía tenemos terabytes libres” pero fallan asignaciones; el rendimiento cae; operaciones de metadatos se ralentizan; picos de latencia extraños.

Solución: vigila la capacidad del pool y la fragmentación, y mantén más margen del que crees necesitar—especialmente durante una ventana con checkpoint. Considera limitar temporalmente a los escritores y asegúrate de que autotrim (cuando sea apropiado) no esté enmascarando el comportamiento a nivel de dispositivo.

Listas de verificación / plan paso a paso

Lista A: Crear un checkpoint de forma segura (producción)

1. Confirmar salud: pool ONLINE, sin resilver en curso a menos que tengas una razón muy específica.
2. Confirmar margen: comprueba capacidad y fragmentación; si estás por encima de umbrales cómodos, crea margen primero.
3. Definir el alcance del rollback: ¿qué exactamente desharía el rollback? Escríbelo en el registro de cambio.
4. Fijar un tiempo de expiración: “descartar al final de la ventana” es un buen valor por defecto. Ventanas más largas necesitan justificación y monitorización.
5. Crear el checkpoint: registra la marca temporal.
6. Monitorear durante la ventana: observa alloc/free y tasas de escritura. Si la presión de espacio sube, decide pronto.
7. Terminar la ventana con intención: o descartar (comprometer) o revertir (deshacer). No lo dejes ambiguo.

Lista B: Descartar un checkpoint (el paso más olvidado)

1. Verificar que los servicios están sanos y el cambio está aceptado.
2. Confirmar que el checkpoint existe.
3. Descartarlo.
4. Verificar que ha desaparecido.
5. Vigilar el comportamiento del espacio libre del pool durante la siguiente hora: los borrados deberían volver a reclamar espacio y el crecimiento de alloc debería reflejar la realidad.

cr0x@server:~$ sudo zpool get checkpoint tank
NAME  PROPERTY    VALUE                        SOURCE
tank  checkpoint  2025-12-25T10:22:11+00:00    -

cr0x@server:~$ sudo zpool checkpoint -d tank
cr0x@server:~$ sudo zpool get checkpoint tank
NAME  PROPERTY    VALUE  SOURCE
tank  checkpoint  -      -

Lista C: Revertir de forma segura (cuando realmente lo decidas)

1. Declarar impacto: todo lo posterior a la marca temporal del checkpoint se perderá.
2. Quiescer: detén aplicaciones, desmonta o monta en solo lectura si procede.
3. Export/import: asegura un estado de importación limpio y consistente del pool sin escritores activos.
4. Rollback: ejecuta el rollback del checkpoint.
5. Validar: monta datasets, comprueba la salud del pool y luego levanta servicios en orden controlado.

cr0x@server:~$ sudo systemctl stop libvirtd
cr0x@server:~$ sudo systemctl stop postgresql
cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import tank
cr0x@server:~$ sudo zpool checkpoint -r tank
cr0x@server:~$ sudo zpool status -xv tank
pool 'tank' is healthy

Preguntas frecuentes

1) ¿Un zpool checkpoint es lo mismo que un snapshot de ZFS?

No. Los snapshots son por dataset y te permiten restaurar o clonar el estado de un dataset. Un checkpoint es un punto de reversión a nivel de pool que rebobina todo en el pool, incluidos todos los datasets y sus snapshots.

2) ¿Puedo tener múltiples checkpoints?

Normalmente, no: un checkpoint a la vez por pool. La limitación es en parte para evitar que el espacio inmovilizado y la complejidad se vuelvan inmanejables.

3) ¿Crear un checkpoint consume espacio inmediatamente?

Por lo general no asigna una gran cantidad inmediatamente. El coste aparece a medida que modificas datos después: los bloques antiguos que normalmente quedarían libres se mantienen inmovilizados para que el checkpoint pueda reconstruirse.

4) ¿Por qué no aumentó el espacio libre después de borrar terabytes?

Porque el checkpoint todavía referencia los bloques antiguos. Desde el punto de vista del checkpoint, los datos aún existen. Descartar el checkpoint quita esa restricción y permite la reutilización normal del espacio.

5) ¿Puedo “enviar” un checkpoint a otra máquina como un snapshot?

No. Si necesitas portabilidad, usa snapshots de dataset con zfs send/zfs receive, o replica el pool por otros medios. Un checkpoint no es un mecanismo de replicación.

6) ¿Debería crear un checkpoint antes de zpool upgrade?

A veces. Si estás en un entorno donde podrían exigir rollback y tienes suficiente margen, puede ser una protección razonable. Pero la mejor “seguridad de upgrade” sigue siendo: probar en staging, entender las flags de características y tener copias de seguridad/replicación reales. Un checkpoint es un undo táctico, no una estrategia.

7) ¿Un checkpoint me protegerá de fallos de hardware durante el cambio?

No. Un checkpoint no hace una segunda copia de tus datos. Si pierdes el pool o suficientes dispositivos como para hacerlo inaccesible, el checkpoint cae con él.

8) ¿Es seguro mantener un checkpoint por días?

Puedes, en el sentido de que ZFS lo soporta, pero es arriesgado operativamente en pools activos. Estás apostando a que los bloques inmovilizados y la fragmentación no te llevarán a presión de espacio o problemas de rendimiento. Si debes mantenerlo, monitorea agresivamente y pon una expiración firme.

9) ¿El rollback arregla corrupciones a nivel de aplicación?

Puedes deshacer cambios a nivel de almacenamiento, pero no garantiza consistencia a nivel de aplicación a menos que hayas quiescido la aplicación en el momento del checkpoint y al rollback. Bases de datos, VMs y sistemas distribuidos se preocupan por el orden de escrituras y las semánticas de flush, no solo por bloques en disco.

10) ¿Cuál es la política más simple y segura para checkpoints en producción?

Úsalos solo para cambios donde la reversión a nivel de pool tiene un valor real, siempre asigna un propietario y una fecha límite, y por defecto descártalos al final de la ventana de mantenimiento.

Conclusión

zpool checkpoint es una de esas características que se siente como un regalo hasta que aprendes su precio. Es un deshacer de emergencia a escala de pool, potenciado por CoW, y funciona—con frecuencia de forma espectacular—cuando lo usas en ventanas cortas y controladas. Las aristas afiladas provienen del mismo lugar de donde viene su poder: preservar el pasado significa que el pool no puede reutilizar libremente el presente.

Si recuerdas solo tres cosas, que sean estas: (1) un checkpoint no es una copia de seguridad, (2) puede inmovilizar espacio y arruinar silenciosamente tu margen, y (3) el checkpoint más seguro es el que tiene un propietario escrito, un temporizador y una decisión clara al final de la ventana: descartar o revertir. En almacenamiento, la ambigüedad es cómo lo “temporal” se vuelve “permanente” y lo “permanente” se vuelve “incidente”.