Actualización de zpool de ZFS: cuándo actualizar y cuándo esperar

diciembre 15, 2025 • febrero 3, 2026 • Lectura: 28 min • Views: 12

¿Te fue útil?

Actualizar un pool ZFS es una de esas operaciones que parece mantenimiento rutinario—hasta que recuerdas lo que realmente es: una puerta de un solo sentido. zpool upgrade no “parcha” tu pool. Cambia el conjunto de características en disco que define quién podrá leer ese pool en el futuro. Si ejecutas ZFS en producción, eso no es un detalle. Es todo el trabajo.

Este artículo trata de tomar esa decisión como un profesional con turno de guardia. Cubriremos qué cambia realmente, qué te compra el “esperar”, cómo interactúan las actualizaciones con los pools de arranque y la replicación, y cómo ejecutar los comandos con suficiente contexto para entender su salida. Obtendrás listas de verificación reales, pasos de diagnóstico rápido y los errores que la gente repite porque “funcionó en el laboratorio”.

Qué hace realmente `zpool upgrade`

OpenZFS moderno ya no gira alrededor del viejo “número de versión del pool” como antes. Gira alrededor de las banderas de características. Un pool puede anunciar que soporta ciertas características en disco (por ejemplo, spacemap_histogram o extensible_dataset). Cuando una característica está habilitada en un pool y realmente se utiliza, implementaciones antiguas que no la entienden pueden negarse a importar el pool—o importarlo en modo sólo lectura, o comportarse de forma impredecible dependiendo de la época y la plataforma.

zpool upgrade es la herramienta que habilita nuevas características en un pool existente (y en algunos entornos también actualiza la versión heredada). Normalmente es rápido, y esa es la trampa: las consecuencias en disco pueden ser lentas y permanentes, porque las características pueden activarse sólo cuando se escribe nueva metadata.

La forma práctica de pensarlo es:

Actualizar el software ZFS (paquetes, módulo del kernel) es reversible: puedes arrancar un kernel antiguo o reinstalar una versión anterior del paquete.
Actualizar el conjunto de características del pool es efectivamente irreversible: una vez que las banderas de características están activas y en uso, no puedes “degradar” el pool para que un ZFS antiguo lo entienda otra vez.

Un chiste, porque lo vamos a necesitar: Actualizar un pool es como hacerse un tatuaje en la cara—técnicamente puedes revertirlo, pero “reversible” requiere mucho trabajo en esa frase.

¿Qué cambia en disco?

Las banderas de características se refieren a formatos y semánticas en disco: cómo se almacenan los mapas de espacio, qué estructuras de metadata existen, cómo se rastrean las checksums, qué propiedades existen y si requieren nuevas estructuras, etc. Algunas características están “habilitadas” pero no te afectan hasta que usas algo que depende de ellas. Otras se usan efectivamente de inmediato una vez habilitadas porque ZFS comienza a escribir metadata de una manera más nueva.

Nueva matización importante: zpool upgrade puede habilitar características, pero las características también pueden activarse al establecer propiedades o crear datasets que las utilicen. A veces puedes actualizar un pool y aún así importarlo en sistemas más antiguos si las características están habilitadas pero no activas—sin embargo, esta es una estrategia frágil y depende del comportamiento de la característica. Trata “habilitado” como “estás avisado”.

Hechos interesantes y contexto histórico

Las discusiones sobre almacenamiento se vuelven menos emocionales cuando recuerdas la línea de tiempo. Aquí hay algunos hechos concretos que explican por qué zpool upgrade sigue siendo un tema en 2025:

ZFS comenzó como una característica de Solaris donde la pila de almacenamiento (ZFS + herramientas) estaba integrada verticalmente; la historia de “actualizar el pool” asumía menos permutaciones de sistema operativo.
El ZFS temprano usaba números de versión del pool (por ejemplo, versión 28) en lugar de muchas banderas de características independientes; actualizabas a una versión y aceptabas todo lo incluido.
Las banderas de características llegaron para arreglar el problema del “version lockstep”: proveedores e implementaciones open-source podían añadir características sin pelear por una única versión monótonamente creciente.
OpenZFS se convirtió en el centro de gravedad para muchas plataformas, pero no todas las plataformas entregan el mismo nivel de OpenZFS al mismo tiempo—especialmente appliances y distribuciones empresariales conservadoras.
Los pools de arranque son especiales: tu pool de datos puede importar bien con un nuevo conjunto de características, pero tu cargador de arranque podría no ser capaz de leer el pool raíz si habilitas ciertas características allí.
Las banderas de características son granulares, no inofensivas: algunas afectan solo capacidades opcionales; otras afectan rutas de asignación/metadata principales y se vuelven efectivamente obligatorias una vez usadas.
La replicación es tu máquina del tiempo—hasta que no lo es: zfs send/receive puede salvar muchas diferencias, pero no toda característica en disco es representable en un stream como esperas, y no todos los receptores pueden aceptarla.
“Funciona en mi estación” es especialmente peligroso con ZFS porque los laboratorios suelen tener una sola implementación de ZFS y un único objetivo de importación, mientras que producción tiene sitios DR, repuestos fríos, ISOs de recuperación y appliances de proveedores.

Cuándo actualizar vs cuándo esperar

La mayoría de la gente plantea esto como “nuevas características vs riesgo”. Eso no está mal, pero es incompleto. El verdadero intercambio es entre flexibilidad operativa y deuda técnica.

Buenas razones para actualizar

Actualiza el conjunto de características de tu pool cuando al menos una de estas sea cierta:

Necesitas una característica que resuelva un problema real (no una curiosidad). Ejemplo: habilitar características que mejoren la escalabilidad de los space maps si estás al límite del overhead de metadata, o características requeridas por un flujo de trabajo de replicación/gestión más nuevo.
Has estandarizado un nivel de ZFS en todos los objetivos de importación: cada sistema que pueda importar el pool (producción, DR, host de restauración de prueba, entorno de recuperación “break glass”) ejecuta una versión de ZFS que soporte las mismas características.
Tienes una historia de migración que no dependa de importar el pool antiguo en sistemas más viejos. En otras palabras, has aceptado la puerta de un solo sentido y construido una rampa del otro lado (replicación, backups, o ambos).
Tu entorno de arranque está validado si el pool es un pool raíz. Si no lo es, la vida es más fácil, pero no siempre sencilla.

Buenas razones para esperar

Esperar no es cobardía; es una estrategia. Debes esperar cuando:

Operas una flota mixta y cualquier host podría verse obligado a importar el pool durante un incidente. El día que actualices es el día que eliminas una vía de escape que no sabías que necesitabas.
Tu plan de DR depende de entornos antiguos (por ejemplo, una imagen de recuperación provista por el proveedor, un OS de appliance con ZFS fijado, o un host de recuperación offline que rara vez se actualiza).
No necesitas las características. “Último” no es un requisito de negocio, y para almacenamiento rara vez es un requisito de rendimiento por sí mismo.
No tienes tiempo para ensayar. Las actualizaciones de pool son rápidas; el análisis del radio de impacto no lo es.

El compromiso “esperar, pero seguir avanzando”

La mejor postura operativa que he visto es: actualizar el software ZFS regularmente, pero actualizar las características del pool de forma deliberada y poco frecuente.

Eso te da correcciones de errores, mejoras de rendimiento en el código y parches de seguridad—sin quemar tus puentes de compatibilidad. Puedes ejecutar un OpenZFS nuevo sobre un conjunto de características antiguo; no puedes ejecutar un OpenZFS antiguo sobre un conjunto de características nuevo.

Compatibilidad: OSes, cargadores de arranque y “flotas mixtas”

Si ejecutas ZFS en un solo servidor, la compatibilidad es una nota. Si ejecutas ZFS en toda una empresa, la compatibilidad es una política.

Objetivos de importación mixtos (el requisito oculto)

Haz la lista de cada sistema que podría importar el pool:

Hosts de producción primarios
Pares de conmutación por error HA
Hosts de recuperación DR
Máquinas de forense o recuperación offline
VMs temporales de “restauración” usadas durante incidentes
Entornos de soporte del proveedor (sí, esto sucede)

Si alguno de esos no puede importar después de la actualización, has estrechado tu ventana de respuesta a incidentes. En tiempos tranquilos, eso parece “arquitectura limpia”. En una crisis, es “¿por qué no se importa el pool?”

Los pools raíz son donde la optimismo muere

Actualizar un pool de datos suele ser directo. Actualizar un pool raíz es una negociación con tu cargador de arranque, herramientas de initramfs y cómo tu distribución integra ZFS.

Incluso cuando el sistema en ejecución puede importar el pool raíz actualizado, todavía necesitas demostrar que tu ruta de arranque puede:

Leer la metadata del pool
Leer el dataset que contiene el kernel/initramfs (o encadenarlo)
Manejar las banderas de características que has habilitado

Segundo chiste (y último): el soporte de arranque ZFS es como el “desayuno continental” de un hotel—técnicamente existe, pero no planifiques todo tu día en torno a ello.

Replicación y banderas de características

zfs send/receive puede replicar datasets entre sistemas incluso cuando los conjuntos de características del pool difieren, pero hay matices:

Si el lado receptor no soporta una característica de dataset incrustada en el stream, el receive falla.
Algunas propiedades y comportamientos especiales de vdev no son “portátiles” como la gente asume; puedes replicar datos pero no la forma operacional del pool.
Incluso si la replicación de datasets funciona, las operaciones a nivel de pool (como importar el conjunto de discos del pool en un host distinto) siguen requiriendo compatibilidad de características del pool.

Tareas prácticas: comandos + interpretación

Estos son los comandos que realmente ejecuto antes y después de decidir actualizar un pool. No teoría—solo lo que te dice qué estás a punto de romper.

Tarea 1: Ver el estado actual de características del pool

cr0x@server:~$ sudo zpool get -H -o name,property,value all tank | egrep 'feature@|version'
tank  version  5000
tank  feature@async_destroy  enabled
tank  feature@empty_bpobj  active
tank  feature@lz4_compress  active
tank  feature@spacemap_histogram  enabled
tank  feature@project_quota  disabled

Interpretación: Enfócate en las características que están active (ya usadas en disco) y enabled (pueden volverse activas). disabled es inerte. Si aún ves un campo version heredado, tu plataforma puede conservarlo para reportes de compatibilidad; las banderas de características son las que importan.

Tarea 2: Preguntar a ZFS qué actualizaciones están disponibles

cr0x@server:~$ sudo zpool upgrade
This system supports ZFS pool feature flags.

All pools are formatted using feature flags.

Some supported features are not enabled on the following pools.
Note that once a feature is enabled the pool may become incompatible with
software that does not support the feature. See zpool-features(7) for details.

POOL  FEATURE
tank  spacemap_histogram
tank  device_removal

Interpretación: Esta es la vista de “qué podría cambiar”. Si ves una lista larga, eso no es necesariamente malo—pero es una pista de que estás atrasado y deberías planear un evento de actualización deliberado en vez de morir por mil características.

Tarea 3: Simular la lista de compatibilidad comprobando versiones de ZFS en la flota

cr0x@server:~$ for h in zfs-a zfs-b dr-restore; do
>   echo "== $h ==";
>   ssh $h "zfs version 2>/dev/null || modinfo zfs 2>/dev/null | head -n 5"
> done
== zfs-a ==
zfs-2.2.4-1
zfs-kmod-2.2.4-1
== zfs-b ==
zfs-2.2.2-1
zfs-kmod-2.2.2-1
== dr-restore ==
zfs-2.1.12-1
zfs-kmod-2.1.12-1

Interpretación: Si cualquier host que pueda necesitar importar el pool está atrasado, tu decisión de actualización ya está tomada: o actualizas el host primero o no actualices el pool. “Arreglaremos DR después” es cómo DR se convierte en fan fiction.

Tarea 4: Confirmar la salud del pool antes de tocar nada

cr0x@server:~$ sudo zpool status -x
all pools are healthy

Interpretación: No actualices un pool que ya está degradado a menos que conscientemente estés intercambiando opcionalidad por estabilidad (raro). Arregla primero los problemas de disco; de lo contrario estarás depurando dos categorías de problemas a la vez.

Tarea 5: Comprobar scrubs/resilvers en curso y saturación de I/O

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 01:12:40 2025
        4.12T scanned at 1.05G/s, 2.31T issued at 604M/s, 8.20T total
        0B repaired, 28.17% done, 0 days 02:41:18 to go
config:
        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

Interpretación: Si hay un scrub/resilver en ejecución, termínalo primero a menos que tengas una razón para no hacerlo. Además: los números te dicen si el pool ya está bajo estrés. Actualizar características suele ser ligero, pero tu ventana de cambio no debería solaparse con la operación de mantenimiento más ocupada del pool.

Tarea 6: Snapshot y validar replicación (tu sustituto de rollback)

cr0x@server:~$ sudo zfs snapshot -r tank@pre_pool_upgrade
cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -s creation | tail -n 5
tank@pre_pool_upgrade                     Mon Dec 23 03:22 2025
tank/home@pre_pool_upgrade                Mon Dec 23 03:22 2025
tank/vm@pre_pool_upgrade                  Mon Dec 23 03:22 2025

Interpretación: Las snapshots no revierten las banderas de características del pool. Protegen el estado de los datos, no el estado del formato. Aun así son obligatorias, porque las actualizaciones y las ventanas de cambio son cuando los humanos hacen cosas humanas.

Tarea 7: Probar un send/receive a un destino conocido y bueno

cr0x@server:~$ sudo zfs send -R tank@pre_pool_upgrade | ssh backup1 sudo zfs receive -uF backup/tank_test
cr0x@server:~$ ssh backup1 sudo zfs list -o name,used,available -r backup/tank_test | head
NAME                  USED  AVAIL
backup/tank_test      128K  40.2T
backup/tank_test/home  96K  40.2T

Interpretación: Esto es una comprobación de confianza: todavía puedes mover tus datos a otro sitio con tu cadena de herramientas actual. Si esto falla antes de la actualización, no va a fallar mágicamente después.

Tarea 8: Identificar si tratas con un pool raíz

cr0x@server:~$ findmnt -no SOURCE /
tank/ROOT/default

Interpretación: Si / vive en ZFS, estás en territorio de “cadena de arranque”. Eso no prohíbe una actualización; exige un ensayo y un plan de rollback que incluya arrancar un entorno alternativo.

Tarea 9: Ver qué está realmente montado y dónde (capturar sorpresas)

cr0x@server:~$ sudo zfs mount | head -n 10
tank                             /tank
tank/home                        /home
tank/home/cr0x                   /home/cr0x
tank/vm                          /vm

Interpretación: Los pools acumulan “adherencias”. Esta salida te recuerda qué servicios dependen del pool y qué podría romperse si reinicias después de una actualización (especialmente para pools raíz).

Tarea 10: Ejecutar la actualización real (a nivel de pool) deliberadamente

cr0x@server:~$ sudo zpool upgrade tank
This pool is currently formatted using feature flags.
All supported features are enabled.

Interpretación: No obtendrás fuegos artificiales. Obtendrás una línea de texto y un nuevo límite de compatibilidad. Sigue inmediatamente con comandos de verificación, porque “dijo OK” no es un sistema de monitorización.

Tarea 11: Verificar qué características están ahora habilitadas/activas

cr0x@server:~$ sudo zpool get -H -o property,value all tank | egrep '^feature@' | head -n 12
feature@async_destroy  enabled
feature@bookmarks  enabled
feature@embedded_data  active
feature@empty_bpobj  active
feature@enabled_txg  active
feature@extensible_dataset  active
feature@filesystem_limits  enabled
feature@hole_birth  active
feature@large_blocks  enabled
feature@lz4_compress  active
feature@spacemap_histogram  active
feature@userobj_accounting  enabled

Interpretación: Cualquier característica ahora active es una afirmación fuerte de compatibilidad: importar este pool en un ZFS más antiguo probablemente fallará. Las características meramente enabled siguen siendo una preocupación de compatibilidad, porque pueden volverse activas más tarde cuando menos lo esperes.

Tarea 12: Confirmar que nada obvio ha empeorado (latencia + errores)

cr0x@server:~$ sudo zpool iostat -v tank 2 3
                                 capacity     operations     bandwidth
pool                           alloc   free   read  write   read  write
-----------------------------  -----  -----  -----  -----  -----  -----
tank                           3.21T  4.99T     72    190  9.10M  41.2M
  raidz2-0                      3.21T  4.99T     72    190  9.10M  41.2M
    sda                             -      -     18     49  2.30M  10.4M
    sdb                             -      -     17     47  2.20M  10.2M
    sdc                             -      -     18     48  2.30M  10.3M
    sdd                             -      -     19     46  2.30M  10.3M
-----------------------------  -----  -----  -----  -----  -----  -----

Interpretación: Las actualizaciones de pool raramente cambian las estadísticas de I/O inmediatas, pero aquí es donde detectas “actualizamos durante la hora punta y ahora todo está lento” antes de que se convierta en una avalancha de tickets. Observa la latencia de escritura y los errores de checksum.

Tarea 13: Ensayo de export/import (pool no raíz) para validar la importación en el mismo host

cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import -d /dev/disk/by-id tank
cr0x@server:~$ sudo zpool status -x tank
pool 'tank' is healthy

Interpretación: Esto no valida la compatibilidad entre hosts, pero valida que el pool se importa correctamente y que las rutas de dispositivo están sanas. No lo hagas en un pool raíz a menos que disfrutes reconstruir initramfs a las 2 AM.

Tarea 14: Capturar un “bundle forense” después de la actualización (línea base)

cr0x@server:~$ sudo sh -c '{
>   date;
>   uname -a;
>   zfs version;
>   zpool status;
>   zpool get all tank;
>   zfs get -r all tank | head -n 50;
> } > /root/tank-post-upgrade-baseline.txt'

Interpretación: Esto es aburrido. También es el archivo que usarás para demostrar qué cambió cuando alguien aparezca tres semanas después con “el rendimiento es diferente”.

Guía de diagnóstico rápido (caza de cuellos de botella)

Esta es la secuencia de “actualizamos algo y ahora se siente raro”. El objetivo no es encontrar una métrica mágica. El objetivo es clasificar el cuello de botella rápidamente: CPU, disco, metadata, presión de memoria o un cambio de carga de trabajo que coincidió con tu ventana de cambio.

1) Primera comprobación: salud del pool y errores

cr0x@server:~$ sudo zpool status -xv
all pools are healthy

Si ves errores: detén el análisis de rendimiento y trátalo como un incidente de fiabilidad. Los errores de checksum después de una actualización suelen ser coincidencia (cables, HBA, sector malo) pero la coincidencia aún rompe datos.

2) Segunda comprobación: ¿ZFS está bloqueado por I/O o por CPU?

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

Interpretación: Si los discos están saturados (alta ops/ancho de banda en los vdevs) y la latencia sube, estás limitado por I/O. Si los discos parecen tranquilos pero el sistema está lento, probablemente estés limitado por CPU, ARC/memoria o contención de locks.

3) Tercera comprobación: presión del ARC y reclaim de memoria

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|c_min|hits|misses|memory_throttle_count) ' | head
size 4 1234567890
c_max 4 34359738368
c_min 4 4294967296
hits 4 987654321
misses 4 123456789
memory_throttle_count 4 0

Interpretación: Una tasa de misses creciente no es automáticamente mala; depende de la carga. Pero si ves throttling de memoria, churn de reclaim o el ARC reduciéndose inesperadamente, puede que tengas un problema a nivel de host más que del pool.

4) Cuarta comprobación: latencia en la capa de bloques

cr0x@server:~$ iostat -x 1 5

Interpretación: Si await y svctm (o equivalentes modernos) suben, tu ruta de discos/HBA está descontenta. Si la capa de bloques parece bien y ZFS va lento, sospecha metadata o CPU.

5) Quinta comprobación: identificar qué datasets están calientes

cr0x@server:~$ sudo zfs list -o name,used,refer,compressratio,recordsize,logbias -r tank | head -n 20

Interpretación: Los cambios en características de la carga de trabajo suelen aparecer aquí: un dataset de VM con un recordsize grande, una ratio de compresión que cambió tras una actualización de software, o un logbias que no coincide con la realidad.

6) Sexta comprobación: comprobar si hay un scrub/resilver o trim que olvidaste

cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'

Interpretación: La causa más común de “lentitud posterior al cambio” es una tarea en segundo plano que arrancó durante la ventana. Los humanos recuerdan la actualización; ZFS recuerda que aún tiene que scrubear el 60% de tu pool.

Tres micro-historias del mundo corporativo

Micro-historia 1: El incidente causado por una suposición incorrecta

Tenían dos centros de datos, un par HA en cada uno, y un plan de replicación entre sitios. El equipo de almacenamiento hizo lo responsable: mantener ZFS parcheado. Hicieron lo irresponsable: asumir que “parcheado” implicaba “compatible”.

Un viernes, un administrador sénior actualizó los paquetes de ZFS del sitio primario y, viendo una lista de características disponibles, ejecutó zpool upgrade para “mantenerlo ordenado”. El pool volvió bien. Las cargas estaban contentas. Nadie notó—porque ZFS no hace fiesta cuando habilitas nuevos formatos en disco.

Dos semanas después, el sitio primario tuvo un incidente de red que forzó una conmutación controlada. Los hosts de DR seguían en una versión anterior de ZFS debido a una política de fijación del kernel del proveedor. Cuando el equipo de DR intentó importar los discos replicados para un flujo de recuperación específico, la importación falló con un error de característica no soportada.

El error no fue actualizar. El error fue asumir que “replicamos, así que estamos a salvo”. La replicación protegió los datos, pero el runbook de recuperación para esa carga dependía de la portabilidad del conjunto de discos. Acabaron restaurando desde replicación a nivel de dataset en lugar de importar el pool, lo que funcionó—pero costó horas porque las herramientas y la automatización esperaban la ruta de importación.

Tras el incidente, su política cambió: las actualizaciones de características del pool requerían aprobación de compatibilidad de cada objetivo de importación, más un host “break glass” que se actualizaba primero y se mantenía disponible como plataforma de recuperación. Fue aburrido, y detuvo por completo esta clase de fallos.

Micro-historia 2: La optimización que salió mal

Otra compañía tenía un problema de rendimiento: cargas con mucha metadata en un pool que había crecido con los años. Alguien vio nuevas banderas de características en una versión más nueva de OpenZFS y concluyó—razonablemente, pero incorrectamente—que habilitar todo modernizaría el comportamiento de asignación y mejoraría el rendimiento.

Actualizaron el pool durante una ventana de cambios. El rendimiento era similar justo después. Luego, durante el mes siguiente, comenzaron a hacer operaciones normales: crear y destruir datasets, rotar snapshots, rotar backups. Poco a poco, los tiempos de importación aumentaron y un par de operaciones de mantenimiento se alargaron. Nada fue catastrófico. Fue peor que catastrófico: fue ambiguo.

La causa raíz no fue “las banderas de características son malas”. La causa raíz fue que confundieron la actualización del pool con tuning de rendimiento, y además cambiaron patrones de carga de trabajo en el mismo trimestre. En el postmortem, tres cambios independientes se solaparon: un cambio en la política de retención de backups (más snapshots), un aumento de densidad de VMs (más I/O pequeño aleatorio) y una actualización del pool que habilitó características que cambiaron el comportamiento de metadata.

Lo que salió mal fue operativo: no pudieron probar causalidad. Cada equipo tenía una historia plausible. Tomó semanas aislarlo, porque no capturaron una línea base y no escalaron los cambios.

La solución fue casi embarazosa: revertieron la política de retención, movieron algunas VMs y el rendimiento se normalizó. La actualización del pool no fue la villana; la ausencia de experimentos controlados sí lo fue. En su siguiente ventana volvieron a actualizar—esta vez con una línea base, un cambio por variable y una métrica de éxito clara.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una organización de servicios financieros ejecutaba ZFS para directorios home y artefactos internos de construcción. No era glamoroso. Muy ocupado. Su equipo de almacenamiento tenía una regla que molestaba a todos: cada trimestre realizaban un ensayo de importación DR en un host aislado. Mismo diseño de pools, mismos runbooks, mismo simulacro de “simular pánico”. El ensayo incluía verificar que el host DR pudiera importar los pools tal como existen hoy, no como alguien los recordaba.

Cuando llegó el momento de adoptar un OpenZFS más nuevo, actualizaron paquetes en toda la flota primero y luego dejaron las características del pool intactas durante un mes. Durante ese mes, hicieron el ensayo DR dos veces: una con el conjunto de características antiguo y otra después de habilitar selectivamente un pequeño conjunto de características en una copia de staging del pool.

En el ensayo número dos, su entorno de arranque falló al importar el pool raíz en una imagen de recuperación antigua que mantenían para emergencias. Esa imagen de recuperación no debía usarse ya, pero seguía en el “binder break glass”—porque las empresas son museos con nómina.

Porque lo encontraron en ensayo, la solución fue limpia: actualizar la imagen de recuperación, validar de nuevo y luego programar la actualización de características del pool. Cuando un incidente real ocurrió meses después (una falla de host que requirió importar pools en el hardware DR), la recuperación fue fluida. Nadie celebró, que es el mayor elogio para un equipo de almacenamiento.

Errores comunes, síntomas y soluciones

Error 1: Tratar `zpool upgrade` como una actualización normal de paquetes

Síntoma: Después de actualizar, un host antiguo o un entorno de recuperación no puede importar el pool; la importación falla con “unsupported feature(s).”

Solución: Actualiza la implementación de ZFS en todos los posibles objetivos de importación antes de habilitar las características del pool. Si no puedes, no actualices el pool. Si ya lo hiciste, tu solución práctica es migración: replica datasets a un pool compatible o reconstruye el host de recuperación con un ZFS compatible.

Error 2: Actualizar el pool raíz sin demostrar la cadena de arranque

Síntoma: El sistema importa el pool cuando está en ejecución, pero no arranca después de un reinicio; cae a un shell de initramfs o no encuentra el dataset raíz.

Solución: Valida el soporte del cargador de arranque + initramfs para el conjunto de características objetivo. Mantén un entorno de arranque conocido bueno y prueba el reinicio en una ventana de mantenimiento. Si es posible, separa el pool de arranque conservadoramente del pool de datos y actualiza primero el pool de datos.

Error 3: Asumir que las snapshots son un rollback para banderas de características

Síntoma: Alguien dice “podemos hacer rollback a la snapshot si sale mal” en la revisión de cambio.

Solución: Corrige el modelo: las snapshots revierten el estado del dataset, no el formato del pool. El plan de rollback para características del pool es “restaurar a otro pool” (replicación/backup), no “zfs rollback”.

Error 4: Actualizar durante un scrub/resilver o mientras el pool está degradado

Síntoma: La actualización coincide con resilvers más lentos, timeouts o errores adicionales de dispositivos. La correlación crea confusión.

Solución: Estabiliza primero. Termina resilvers/scrubs, arregla cableado/HBA, confirma zpool status -x limpio, luego actualiza.

Error 5: Habilitar características “porque están ahí”

Síntoma: Meses después descubres que un objetivo de importación previamente compatible ya no puede importar el pool porque alguna característica se volvió activa por un cambio de propiedad o uso de un nuevo dataset.

Solución: Habilita solo las características que planeas usar, cuando sea posible. Si el zpool upgrade de tu plataforma habilita todo por defecto, trata eso como una ruptura de compatibilidad deliberada y alinea primero la flota.

Error 6: No capturar una línea base

Síntoma: Reportes vagos: “se siente más lento después de la actualización”, sin métricas previas al cambio.

Solución: Captura una línea base mínima: zpool status, zpool get all, zpool iostat, estadísticas ARC y métricas de latencia de la carga. Guárdalo con el registro del cambio.

Listas de verificación / plan paso a paso

Lista de decisión: ¿debemos actualizar el conjunto de características del pool?

Enumera cada host/entorno que pueda importar este pool (incluyendo DR, VMs de restauración, ISOs de recuperación, appliances del proveedor).
Verifica las versiones de ZFS a través de esa lista; confirma que soportan las características que planeas habilitar.
Confirma que el pool está sano (zpool status -x), sin resilver activo a menos que lo aceptes explícitamente.
Confirma que backups y/o replicación están actualizados y probados (un receive real, no una creencia).
Si es un pool raíz: confirma soporte del cargador de arranque/initramfs y ensaya el reinicio en mantenimiento.
Define métricas de éxito (compatibilidad de importación, éxito de reinicio, límites de latencia, operación sin errores).

Paso a paso: plan de actualización conservador en producción

Actualiza primero el software, no el pool. Despliega actualizaciones de OpenZFS en la flota; reinicia según sea necesario; mantiene los pools en las características existentes.
Realiza un ensayo de compatibilidad. Elige un objetivo de importación no productivo que coincida con tu peor host de recuperación; confirma que puede importar un pool representativo.
Captura la línea base. Almacena: zpool get all, zpool status, zpool iostat, estadísticas ARC y una muestra de latencia de servicio.
Haz snapshots de los datasets. No es para rollback de pool; es para rollback humano y seguridad de datos.
Realiza la actualización. Ejecuta zpool upgrade POOL durante una ventana de pocas escrituras si es posible.
Verifica características y salud. Confirma el estado de características y que el pool permanece sin errores.
Ensaya la importación. Para pools no raíz, exporta/importa en el mismo host; para pools raíz, realiza un reinicio controlado.
Observa. Vigila la latencia de I/O, contadores de errores y la programación de scrubs. No declares victoria hasta haber pasado al menos un ciclo normal de backup y rotación de snapshots.

Paso a paso: si debes mantener compatibilidad hacia atrás

No ejecutes zpool upgrade todavía.
Actualiza paquetes de OpenZFS en todas partes; verifica que el pool antiguo aún se importe en todos los hosts.
Crea un calendario para actualizar sistemas rezagados (appliances, kernels fijados, imágenes DR).
Sólo después de que el último objetivo de importación esté actualizado, programa la actualización de características del pool.

Preguntas frecuentes

1) ¿Es obligatorio ejecutar `zpool upgrade` después de instalar un ZFS más nuevo?

No. Actualizar el software no obliga a actualizar las características del pool. Muchas organizaciones ejecutan código OpenZFS nuevo sobre características de pool antiguas durante años para preservar compatibilidad.

2) ¿Puedo degradar un pool después de `zpool upgrade`?

No en el sentido que la gente suele pensar. No hay un “rollback de banderas de características” soportado una vez que las características están activas en disco. Tu vía de degradado es migración: replica/restaura en un pool creado con el conjunto de características antiguo en un sistema que lo soporte.

3) ¿Cuál es la diferencia entre características “enabled” y “active”?

Enabled significa que el pool tiene permiso para usar la característica; puede volverse active cuando ZFS escribe metadata relevante. Active significa que la característica ya se usa en disco. Las características activas son la restricción de compatibilidad más fuerte.

4) ¿Habilitar nuevas características mejorará el rendimiento?

A veces, indirectamente, para cargas específicas. Más a menudo, los cambios de rendimiento vienen de mejoras en el software, tuning o cambios de carga. Trata las actualizaciones de pool primero como una decisión de compatibilidad y como decisión de rendimiento solo si puedes vincular una característica a un beneficio medible para tu carga.

5) ¿Necesito actualizar un pool para usar nuevas propiedades de dataset?

Depende. Algunas propiedades son puramente comportamiento en tiempo de ejecución; otras dependen de características en disco. Si una propiedad requiere una bandera de características, el pool debe soportarla y los sistemas receptores también.

6) ¿Es seguro actualizar un pool de datos pero no el pool de arranque?

Sí, y a menudo es el mejor compromiso. Mantener el pool de arranque/raíz conservador reduce el riesgo de “no arranca”, mientras permites que tu pool de datos adopte nuevas características una vez que hayas alineado los objetivos de importación.

7) ¿Cómo planifico DR cuando las actualizaciones de pool son unidireccionales?

Haz que los objetivos de importación DR sean ciudadanos de primera clase en tu plan de actualización: mantenlos actualizados, ensaya importaciones y valida que tus herramientas de restauración funcionen con el conjunto de características actualizado. Si DR depende de importar discos físicos, la compatibilidad es innegociable.

8) Si replico datasets, ¿las características del pool siguen importando?

Sí. La replicación te ayuda a mover datos, pero no garantiza mágicamente que todo receptor pueda aceptar toda característica. Además, la replicación de datasets no preserva la topología o el comportamiento a nivel de pool. Planifica pruebas de replicación antes de actualizar.

9) ¿Cuál es la manera más segura de experimentar con `zpool upgrade`?

Clona el entorno: crea un pool de prueba con un diseño de vdev similar, restaura un conjunto representativo de datasets vía zfs send y ensaya la actualización y los pasos de recuperación. Lo principal que pruebas es la compatibilidad y el comportamiento operacional, no si el comando termina.

Conclusión

zpool upgrade no es un paso de parcheo rutinario; es una decisión de compatibilidad con consecuencias que sobreviven al host donde la ejecutas. En producción, el patrón ganador es consistente: actualiza el software ZFS regularmente, actualiza las características del pool sólo cuando tengas una razón, una historia de recuperación ensayada y una flota que pueda importar lo que vas a crear.

Si no sacas nada más: trata las actualizaciones de características del pool como migraciones de esquema para tu almacenamiento—probadas, escalonadas y respaldadas por un sustituto real de rollback (replicación/restauración), no por esperanza. Ese enfoque no hará que las actualizaciones sean emocionantes. Las hará olvidables, que es exactamente lo que quieres del almacenamiento.