ZFS vs btrfs: instantáneas, RAID, recuperación—¿Cuál duele menos?

enero 11, 2026 • febrero 3, 2026 • Lectura: 30 min • Views: 6

¿Te fue útil?

Hay cierto tipo de llamada a medianoche que te enseña más sobre sistemas de archivos que cualquier benchmark: “latencias de almacenamiento en picos”, “VMs congeladas”, “ventana de backup perdida” y el silencioso temor de que tus instantáneas se hayan convertido en un vertedero. ZFS y btrfs prometen características modernas de sistema de archivos: copy-on-write, instantáneas, sumas de verificación, autocuración. En la práctica, se sienten como dos filosofías distintas para gestionar el dolor.

Esta es una comparación para operadores: qué se rompe, cómo se rompe, qué puedes automatizar con confianza y qué deberías ensayar antes de que la producción te obligue a ensayarlo a las 3 a.m. Hablaremos de instantáneas, RAID, recuperación, rendimiento y los hábitos operativos aburridos que te mantienen empleado.

La tesis: ¿cuál duele menos?

Si tu prioridad máxima es la integridad predecible, herramientas maduras y una historia de recuperación menos sorprendente—especialmente para pools grandes, mucha virtualización o retención larga—ZFS duele menos. Es opinado, estricto y normalmente tiene razón. Pagas en apetito de RAM, complejidad de ajuste y a veces en política de licencias, pero obtienes un sistema de archivos que se comporta como si esperara recibir culpas—y vino preparado con recibos.

Si tu prioridad es la integración nativa en el kernel, diseño flexible de subvolúmenes y flujos de trabajo de “instantáneas por todas partes” en Linux—especialmente en sistemas de nodo único y distribuciones que lo envuelven bien—btrfs puede doler menos. Es notablemente capaz hoy, pero su historia de RAID (especialmente RAID de paridad) tiene advertencias que no son teóricas. No es “malo”, pero exige que sepas qué características son aburridamente estables y cuáles aún son un poco… aventureras.

Mi sesgo en producción, ganado a la mala: ZFS para redundancia seria multi-disco y datasets de larga vida. btrfs para sistemas root, instantáneas de OS en estaciones/servidores y configuraciones espejo más sencillas donde la integración en el kernel y la conveniencia de las herramientas importan más que la máxima sofisticación RAID.

Broma #1: Un sistema de archivos es como un paracaídas—si estás intentando descubrir si funciona, ya tomaste decisiones de vida interesantes.

Datos interesantes y contexto histórico (las partes que la gente olvida)

ZFS nació en Sun Microsystems como una pila de almacenamiento de extremo a extremo: sistema de archivos + gestor de volúmenes + RAID + sumas de verificación, diseñado para eliminar la “corrupción silenciosa” y la adivinanza operacional.
btrfs empezó en Oracle como un CoW nativo de Linux con instantáneas y checksumming, con la intención de competir con características tipo ZFS viviendo dentro del kernel.
RAIDZ de ZFS no es el RAID-5/6 clásico; está diseñado para evitar el “write hole” con copy-on-write y grupos de transacciones, reduciendo una clase entera de problemas de corrupción de franjas parciales.
La reputación temprana de btrfs fue moldeada por problemas en RAID5/6. Muchas empresas aprendieron (a la fuerza) a tratar el RAID de paridad de btrfs como “no lo uses, a menos que sepas exactamente a qué te apuntas”.
Ambos sistemas suman checksums a los datos, pero ZFS trata la integridad como la promesa central, mientras que btrfs aporta integridad dentro de un sistema de archivos Linux que también tiene que convivir con el ecosistema más amplio del kernel.
Los scrubs no son copias de seguridad. Tanto ZFS scrub como btrfs scrub son procesos de verificación de integridad; solo pueden reparar si existe datos redundantes buenos disponibles.
ZFS send/receive se convirtió en el modelo para replicación barata y rápida a nivel de bloque/registro. btrfs send/receive también existe y es genial—cuando tu disciplina de subvolúmenes/instantáneas está limpia.
La compresión se volvió mainstream gracias a los sistemas CoW. ZFS popularizó “actívalo, a menudo es más rápido”; btrfs hizo la compresión accesible y nativa en el kernel, con control por subvolumen.
“Instantáneas” son trucos de metadatos, no discos extra mágicos. Ambos sistemas pueden crear instantáneas al instante, pero la retención larga sin poda se convierte en deuda operativa con interés.

Modelos mentales: en qué cree cada sistema de archivos

ZFS: el sistema de almacenamiento que quiere asumir todo el problema

ZFS no quiere ser “un sistema de archivos sobre el RAID de otro”. Quiere ser el sistema de archivos y el RAID y el gestor de volúmenes y la capa de integridad. Por eso un pool ZFS (“zpool”) contiene vdevs, y esos vdevs definen la redundancia. El sistema de archivos (“dataset”) se asienta encima y hereda propiedades. Una vez que interiorizas eso, ZFS deja de parecer extraño y empieza a sentirse como un adulto muy estricto.

En el mundo ZFS, la unidad primaria de riesgo es el vdev. Pierdes un vdev y pierdes el pool. No “añades discos a RAIDZ más tarde” sin planearlo. Diseñas anchos de vdev y redundancia desde el principio (o aceptas las opciones de expansión que existen en tu versión y las limitaciones operativas). ZFS recompensa la paciencia y castiga la improvisación.

btrfs: el sistema de archivos nativo de Linux que quiere ser flexible

btrfs está más cerca de la identidad “sistema de archivos primero”, con soporte multi-dispositivo integrado que puede parecer RAID. Usa subvolúmenes y instantáneas como primitivas organizativas de primera clase, lo que lo hace maravilloso para patrones de rollback/instantáneas del sistema operativo. También encaja bien con el kernel, lo que importa para distribuciones, cargadores de arranque y la realidad de “simplemente actualiza la máquina” en flotas.

La flexibilidad de btrfs es real: puedes añadir dispositivos, convertir perfiles de datos y reorganizar con balance. Pero la flexibilidad corta en dos direcciones. Si ZFS es estricto y te salva de ti mismo, btrfs a veces te permite hacer lo peligroso porque técnicamente está permitido.

Instantáneas y clones: poder y trampas

Cómo se comportan realmente las instantáneas

Tanto las instantáneas de ZFS como las de btrfs son baratas de crear y caras de mantener para siempre. El coste no es la instantánea en sí; son los bloques antiguos retenidos. Si instantaneas un dataset y luego reescribes una gran imagen de VM cada día, básicamente te inscribiste en “historial infinito” a menos que hagas poda. Tu espacio libre no desaparecerá linealmente; desaparecerá en trozos incómodos, en momentos emocionalmente inconvenientes.

Instantáneas ZFS: operativamente previsibles

Las instantáneas de ZFS son estables, ampliamente usadas e integradas con flujos de trabajo de replicación. Los clones son instantáneas a las que puedes escribir. ZFS también te da primitivas limpias como holds (para prevenir eliminación), propiedades de dataset para recursión y flujos send/receive bien entendidos.

La trampa de las instantáneas en ZFS por lo general no es de corrección—es de capacidad y fragmentación. Un dataset con muchas instantáneas y muchos escrituras aleatorias pequeñas puede volverse desordenado. Aun así, el “desorden” suele parecer “rendimiento degradado y espacio justo”, no “los metadatos del sistema de archivos están en llamas”.

Instantáneas btrfs: fantásticas para OS y disciplina de subvolúmenes

Las instantáneas de btrfs brillan cuando tratas los subvolúmenes como límites: @ para root, @home, quizá @var o @docker, e instantaneas los que realmente quieres revertir. Aquí btrfs se siente casi como hacer trampa: instantánea instantánea, rollback rápido, experimentación fácil.

La trampa de las instantáneas en btrfs aparece cuando la gente instantanea todo sin pensar en directorios con mucho churn (imágenes de VM, bases de datos, contenedores). Las instantáneas retienen extensiones, y cargas de trabajo con mucho churn pueden convertir tu “agradable red de seguridad para rollback” en una fuga de espacio a cámara lenta que solo se revela durante un incidente.

RAID: qué está integrado, qué se presupone, qué es arriesgado

RAID en ZFS: mirrors y RAIDZ a la manera ZFS

La redundancia en ZFS se define a nivel de vdev: mirrors, RAIDZ1/2/3. Añade vdevs para ampliar. Reemplaza discos para sanar. Scrub para verificar. Resilver para reconstruir. No es “configurar y olvidar”, pero es coherente.

Verdad operativa clave: IOPS depende en gran medida del número de vdevs, especialmente con mirrors. Un único vdev RAIDZ ancho puede ofrecer un rendimiento secuencial impresionante y aun así sentirse lento para IO aleatorio comparado con múltiples vdevs mirror. El sistema de archivos no está lento; tu geometría lo está.

RAID en btrfs: perfiles, no arreglos clásicos

btrfs habla de perfiles: perfil de datos (single, DUP, RAID1, RAID10, RAID5/6) y perfil de metadata (a menudo RAID1 incluso si los datos son single). Eso es potente: puedes priorizar la seguridad de metadata incluso en configuraciones de disco único usando DUP (en un solo dispositivo guarda dos copias—útil contra ciertos patrones de sectores malos, no es sustituto de redundancia).

La gran advertencia sigue siendo el RAID de paridad. Los perfiles de espejado (RAID1/RAID10) son ampliamente usados y generalmente confiables. Los perfiles de paridad (RAID5/6) han tenido una larga historia de casos límite y todavía se tratan con cautela en muchos entornos de producción. Si construyes “esto debe sobrevivir fallos raros”, RAID1/10 de btrfs es el carril más seguro.

Broma #2: “RAID no es una copia de seguridad” es el equivalente en almacenamiento de “no toques la estufa”—todos asienten, y luego alguien toca la estufa de todas formas.

Recuperación: lo que puedes arreglar y lo que no

Recuperación en ZFS: scrubs, resilvers y el arte de no entrar en pánico

La historia de recuperación de ZFS es cohesiva: detectar corrupción vía checksums, reparar desde la redundancia, rastrear errores por dispositivo y proporcionar estados de salud claros. Cuando falla, a menudo falla de una manera diagnosticable: un disco lanza errores, un cable es intermitente, un controlador miente. ZFS te lo dirá, en voz alta.

La ventaja operativa más importante: puedes confiar en la señal. Si ZFS dice que reparó X bytes y un dispositivo está fallando, puedes actuar con alta confianza. Esa confianza vale mucho cuando manejas stakeholders y el reloj está gritando.

Recuperación en btrfs: buenas herramientas, más matices y “conoce tu modo”

btrfs tiene un conjunto sólido de herramientas de recuperación: scrub, estadísticas de dispositivo, utilidades check/repair y la capacidad de montar en solo lectura y salvar datos. Pero la carga para el operador es mayor porque los resultados pueden depender más de qué características usaste (perfiles, compresión, cuotas, instantáneas) y qué tipo de fallo ocurrió (corrupción en dispositivo único vs multi-dispositivo vs daño en metadata).

btrfs puede ser extremadamente fiable en las configuraciones bien trilladas (dispositivo único, RAID1/10, instantáneas disciplinadas). Se vuelve menos “predeciblemente aburrido” cuanto más te alejas hacia RAID de paridad y conversiones complejas bajo presión.

Rendimiento: latencia, rendimiento y la guerra de caches

Rendimiento en ZFS: ARC, recordsize, sync y el mito del SLOG

A ZFS a menudo se le acusa de ser “glotón de RAM”. Más precisamente: ZFS usará memoria para ARC (adaptive replacement cache) porque la caché mejora todo hasta que deja de hacerlo. En Linux, debes entender la interacción entre ARC y la page cache del kernel, y deberías poner límites sensatos en sistemas con memoria limitada.

Para bases de datos y virtualización, el ajuste de ZFS suele girar alrededor de unas pocas palancas prácticas:

recordsize: grande para secuencial (backups), más pequeño para aleatorio (VMs, DBs).
compression: a menudo mejora el rendimiento efectivo y la latencia.
sync: no “optimices” esto a menos que te guste explicar pérdida de datos.
SLOG: ayuda las escrituras sync solo para ciertas cargas; no es una poción mágica.

Rendimiento en btrfs: CoW, compresión y realidades de fragmentación

btrfs puede ser rápido, especialmente con compresión y NVMe. Pero CoW tiene consecuencias para cargas que reescriben grandes archivos en sitio (imágenes de disco de VM, algunas bases de datos). btrfs ofrece formas de mitigarlo (como desactivar CoW en archivos/directorios específicos vía chattr +C), pero eso es un intercambio: estás renunciando a algunos beneficios de CoW.

El “balance” de btrfs es tanto una capacidad como una trampa: puede reorganizar datos hacia un nuevo perfil o mejorar la distribución, pero consume mucho IO y puede amplificar el dolor si lo ejecutas de forma casual en sistemas ocupados.

Tareas prácticas con comandos (y qué significa la salida)

La forma más rápida de aprender estos sistemas es hacer cosas reales: crear pools, instantanear, scrubs, simular fallos y practicar caminos de recuperación. Abajo hay tareas que puedes ejecutar en sistemas de prueba. Los comandos asumen Linux con herramientas ZFS instaladas (OpenZFS) y btrfs-progs para btrfs.

Task 1 (ZFS): Create a mirrored pool and verify layout

cr0x@server:~$ sudo zpool create -o ashift=12 tank mirror /dev/disk/by-id/ata-diskA /dev/disk/by-id/ata-diskB
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         ONLINE       0     0     0
          mirror-0                   ONLINE       0     0     0
            ata-diskA                ONLINE       0     0     0
            ata-diskB                ONLINE       0     0     0

errors: No known data errors

Interpretación: mirror-0 es tu unidad de redundancia. Si pierdes un disco, el pool permanece online. Si pierdes el vdev mirror (ambos discos), el pool se pierde.

Task 2 (ZFS): Create datasets with sane properties for VMs and backups

cr0x@server:~$ sudo zfs create -o compression=zstd -o atime=off tank/vm
cr0x@server:~$ sudo zfs set recordsize=16K tank/vm
cr0x@server:~$ sudo zfs create -o compression=zstd -o recordsize=1M tank/backup
cr0x@server:~$ sudo zfs get -o name,property,value compression,recordsize,atime tank/vm tank/backup
NAME         PROPERTY    VALUE
tank/vm      compression zstd
tank/vm      recordsize  16K
tank/vm      atime       off
tank/backup  compression zstd
tank/backup  recordsize  1M
tank/backup  atime       on

Interpretación: Estás ajustando recordsize al patrón de IO. VMs: registros más pequeños reducen la amplificación read-modify-write. Backups: registros grandes mejoran la eficiencia secuencial.

Task 3 (ZFS): Take a recursive snapshot and list it

cr0x@server:~$ sudo zfs snapshot -r tank@pre-upgrade
cr0x@server:~$ sudo zfs list -t snapshot -o name,used,refer,creation | head
NAME                    USED  REFER  CREATION
tank@pre-upgrade          0B   128K  Tue Dec 24 00:10 2025
tank/backup@pre-upgrade   0B    96K  Tue Dec 24 00:10 2025
tank/vm@pre-upgrade       0B   256K  Tue Dec 24 00:10 2025

Interpretación: El USED de la instantánea crece a medida que el sistema de archivos en vivo diverge. No lo ignores; es tu “espacio que no puedes recuperar hasta eliminar instantáneas”.

Task 4 (ZFS): Send an incremental snapshot to another pool (replication)

cr0x@server:~$ sudo zfs snapshot tank/vm@replica-001
cr0x@server:~$ sudo zfs send -w tank/vm@replica-001 | sudo zfs receive -u backup-pool/vm
cr0x@server:~$ sudo zfs snapshot tank/vm@replica-002
cr0x@server:~$ sudo zfs send -w -i tank/vm@replica-001 tank/vm@replica-002 | sudo zfs receive -u backup-pool/vm

Interpretación: El primer envío es completo; el segundo es incremental. -w envía un stream en bruto preservando propiedades y (cuando se soporta) características de cifrado.

Task 5 (ZFS): Scrub and read the results

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Tue Dec 24 00:14:02 2025
        2.31G scanned at 410M/s, 812M issued at 144M/s, 120G total
        0B repaired, 0.66% done, 0:13:50 to go
config:

        NAME         STATE     READ WRITE CKSUM
        tank         ONLINE       0     0     0
          mirror-0   ONLINE       0     0     0
            diskA    ONLINE       0     0     0
            diskB    ONLINE       0     0     0

errors: No known data errors

Interpretación: Los scrubs verifican datos contra checksums. Si ocurre reparación, ZFS te dirá exactamente cuánto y qué dispositivo es sospechoso.

Task 6 (ZFS): Simulate a disk failure and replace it

cr0x@server:~$ sudo zpool offline tank /dev/disk/by-id/ata-diskB
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         DEGRADED     0     0     0
          mirror-0                   DEGRADED     0     0     0
            ata-diskA                ONLINE       0     0     0
            ata-diskB                OFFLINE      0     0     0

errors: No known data errors
cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/ata-diskB /dev/disk/by-id/ata-diskC
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Tue Dec 24 00:20:11 2025
        8.02G scanned, 1.94G issued, 120G total
        1.93G resilvered, 1.62% done, 0:18:10 to go

Interpretación: “Resilver” es reconstrucción. En mirrors es directo; en RAIDZ es más complejo. Vigila resilvers lentos—a menudo indican contención IO oculta o un segundo disco enfermo.

Task 7 (btrfs): Create a filesystem on a single device and mount it

cr0x@server:~$ sudo mkfs.btrfs -L data /dev/nvme0n1p3
btrfs-progs v6.6
Label:              data
UUID:               4b1a0c7e-1d2a-4a6f-9e3c-2e3a3a4e6b2f
Node size:          16384
Sector size:        4096
Filesystem size:    400.00GiB
Block group profiles:
  Data:             single
  Metadata:         DUP
  System:           DUP
cr0x@server:~$ sudo mount -o compress=zstd,space_cache=v2 /dev/nvme0n1p3 /mnt/data
cr0x@server:~$ sudo btrfs filesystem df /mnt/data
Data, single: total=1.00GiB, used=256.00MiB
Metadata, DUP: total=1.00GiB, used=112.00MiB
System, DUP: total=8.00MiB, used=16.00KiB

Interpretación: Metadata DUP en un disco único es un refuerzo pragmático de integridad. No es redundancia contra la muerte del disco, pero puede ayudar contra cierta corrupción localizada.

Task 8 (btrfs): Create subvolumes and snapshot them (OS-style layout)

cr0x@server:~$ sudo btrfs subvolume create /mnt/data/@
Create subvolume '/mnt/data/@'
cr0x@server:~$ sudo btrfs subvolume create /mnt/data/@home
Create subvolume '/mnt/data/@home'
cr0x@server:~$ sudo btrfs subvolume snapshot -r /mnt/data/@ /mnt/data/@-snap-pre-upgrade
Create a readonly snapshot of '/mnt/data/@' in '/mnt/data/@-snap-pre-upgrade'
cr0x@server:~$ sudo btrfs subvolume list /mnt/data | head
ID 256 gen 12 top level 5 path @
ID 257 gen 13 top level 5 path @home
ID 258 gen 14 top level 5 path @-snap-pre-upgrade

Interpretación: Las instantáneas de solo lectura son más seguras para rollback y send/receive. Trata los límites de subvolumen como límites de radio de daño.

Task 9 (btrfs): Use send/receive for incremental replication

cr0x@server:~$ sudo btrfs subvolume snapshot -r /mnt/data/@ /mnt/data/@-snap-001
cr0x@server:~$ sudo btrfs send /mnt/data/@-snap-001 | sudo btrfs receive /mnt/backup
At subvol /mnt/backup/@-snap-001
cr0x@server:~$ sudo btrfs subvolume snapshot -r /mnt/data/@ /mnt/data/@-snap-002
cr0x@server:~$ sudo btrfs send -p /mnt/data/@-snap-001 /mnt/data/@-snap-002 | sudo btrfs receive /mnt/backup
At subvol /mnt/backup/@-snap-002

Interpretación: El -p parent snapshot permite envíos incrementales. Si borras el snapshot padre prematuramente, tu cadena se rompe y necesitarás un nuevo envío completo.

Task 10 (btrfs): Scrub and read device stats

cr0x@server:~$ sudo btrfs scrub start -Bd /mnt/data
Starting scrub on devid 1
Scrub device /dev/nvme0n1p3 (id 1) done
Scrub started:    Tue Dec 24 00:35:12 2025
Status:           finished
Duration:         0:01:07
Total to scrub:   18.00GiB
Rate:             274.62MiB/s
Error summary:    read=0 write=0 csum=0 verify=0 no_csum=0 csum_discards=0 super=0 malloc=0 uncorrectable=0 corrected=0
cr0x@server:~$ sudo btrfs device stats /mnt/data
[/dev/nvme0n1p3].write_io_errs   0
[/dev/nvme0n1p3].read_io_errs    0
[/dev/nvme0n1p3].flush_io_errs   0
[/dev/nvme0n1p3].corruption_errs 0
[/dev/nvme0n1p3].generation_errs 0

Interpretación: El scrub verifica checksums e intenta reparar cuando existe redundancia. Las estadísticas de dispositivo te ayudan a identificar un dispositivo intermitente antes de que falle por completo.

Task 11 (btrfs): Convert to RAID1 with a second device (mirror-like behavior)

cr0x@server:~$ sudo btrfs device add /dev/nvme1n1p3 /mnt/data
cr0x@server:~$ sudo btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/data
Done, had to relocate 12 out of 12 chunks
cr0x@server:~$ sudo btrfs filesystem df /mnt/data
Data, RAID1: total=16.00GiB, used=12.00GiB
Metadata, RAID1: total=2.00GiB, used=512.00MiB
System, RAID1: total=32.00MiB, used=64.00KiB

Interpretación: btrfs usa perfiles y chunks. Tras la conversión, tus datos y metadata están espejados entre dispositivos. La operación balance es el precio de esa flexibilidad—planifica capacidad y ventanas de mantenimiento.

Task 12 (btrfs): Disable CoW for a VM directory (with trade-offs)

cr0x@server:~$ sudo mkdir -p /mnt/data/vmimages
cr0x@server:~$ sudo chattr +C /mnt/data/vmimages
cr0x@server:~$ lsattr -d /mnt/data/vmimages
---------------C------ /mnt/data/vmimages

Interpretación: Los archivos nuevos creados en ese directorio serán NOCOW, reduciendo a menudo fragmentación y mejorando patrones de escritura de VM. Intercambio: reduces garantías basadas en CoW para esos archivos (y el comportamiento de checksumming puede verse afectado según kernel/características).

Task 13 (ZFS): Check ARC behavior and memory pressure (Linux)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|hit|miss)'
size                            4    17179869184
c_max                           4    25769803776
hit                             4    1402382231
miss                            4    32988312

Interpretación: El tamaño del ARC y hit/miss te da una señal rápida: ¿estás escaso de caché o bien? Si la máquina está intercambiando, hay que atender límites de ARC, pero no reacciones en caliente—identifica los verdaderos consumidores de memoria.

Task 14 (ZFS): Identify what’s eating space (snapshots vs live data)

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,usedbysnapshots,usedbydataset -r tank
NAME        USED  AVAIL  REFER  USEDBYSNAPSHOTS  USEDBYDATASET
tank        420G   1.2T   128K              0B          128K
tank/vm     300G   1.2T   250G            80G          250G
tank/backup 120G   1.2T   110G            10G          110G

Interpretación: Si USEDBYSNAPSHOTS es grande, eliminar instantáneas antiguas es la palanca. Si USEDBYDATASET es grande, tus datos en vivo crecieron y necesitas capacidad o políticas de poda.

Playbook de diagnóstico rápido (encuentra el cuello de botella antes de que te encuentre)

Este es el flujo “¿qué compruebo primero, segundo, tercero?” que uso cuando el almacenamiento “se siente lento” y el dashboard de monitorización acusa a todo el mundo.

1) Establecer: ¿es disco, CPU, presión de memoria o un inquilino ruidoso?

cr0x@server:~$ uptime
 00:41:03 up 12 days,  4:22,  2 users,  load average: 18.12, 17.90, 16.55
cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            128G         92G         3.1G        2.2G         33G         29G
Swap:             0B          0B          0B
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
18  3      0 3211232 120000 28000000    0    0  1200  3400 9000 22000 25 15 30 30  0

Interpretación: Un wa alto sugiere espera IO. Alta carga con baja espera IO sugiere contención de CPU. La presión de memoria aparece como memoria disponible decreciente y posible swap (si está activado).

2) Revisa la salud del sistema de archivos/pool primero; el rendimiento después

Porque pools degradados a menudo parecen “lentitud aleatoria”.

cr0x@server:~$ sudo zpool status
cr0x@server:~$ sudo btrfs device stats /mountpoint
cr0x@server:~$ dmesg | tail -n 50

Interpretación: Cualquier error read/write/cksum, resets o timeouts cambia tu plan: no estás ajustando; estás triageando hardware.

3) Identifica los mayores consumidores de IO (por proceso y por dispositivo)

cr0x@server:~$ iostat -xz 1 5
cr0x@server:~$ pidstat -d 1 5

Interpretación: Busca dispositivos con alta utilización y await en aumento, y procesos que generan escrituras desproporcionadas. Aquí encuentras el “trabajo de backup” que está haciendo IO aleatorio en tu pool de VMs.

4) Para ZFS: comprueba ARC y comportamiento de escrituras sync

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|mru_size|mfus|hits|miss)'
cr0x@server:~$ sudo zfs get -o name,property,value sync,logbias,primarycache,recordsize -r tank/vm

Interpretación: Si ves muchas escrituras sync y no hay un camino de latencia adecuado (o está saturado), el sistema “se sentirá atascado” bajo ciertas cargas aunque el rendimiento de throughput parezca bien.

5) Para btrfs: comprueba si hay balance/scrub en curso y patrones de fragmentación

cr0x@server:~$ sudo btrfs balance status /mountpoint
cr0x@server:~$ sudo btrfs scrub status /mountpoint
cr0x@server:~$ sudo btrfs filesystem usage /mountpoint | head -n 30

Interpretación: Un balance en marcha durante horas punta puede explicar un “impuesto IO repentino”. También vigila el uso de metadata; un estrechamiento en metadata puede producir bloqueos extraños.

Errores comunes (síntomas y soluciones)

Error 1: Tratar instantáneas como copias de seguridad

Síntoma: “Tenemos instantáneas, ¿por qué no podemos restaurar después de perder el pool?” seguido de un largo silencio.

Solución: Las instantáneas protegen contra errores lógicos (rm -rf, malas actualizaciones) en el mismo almacenamiento. Las copias de seguridad requieren medios independientes o un sistema remoto. Usa zfs send/receive o btrfs send/receive a otro host/pool, o un sistema de backup separado. Prueba restauraciones, no solo envíos.

Error 2: Pool ZFS diseñado como un enorme vdev RAIDZ para cargas de VM

Síntoma: Excelentes benchmarks secuenciales, latencia terrible en VMs, quejas de “IOPS maldito”.

Solución: Para IO aleatorio, usa múltiples vdevs mirror o múltiples vdevs RAIDZ para aumentar paralelismo. También ajusta recordsize apropiadamente (p. ej., 16K) para datasets de VM y activa compression.

Error 3: Usar RAID de paridad de btrfs como si fuera tan aburrido como mdadm RAID6

Síntoma: Comportamiento inesperado durante fallo/reconstrucción de dispositivo, estados de error confusos, recuperación como arqueología.

Solución: Prefiere RAID1/10 de btrfs para fiabilidad multi-dispositivo en producción a menos que tengas procedimientos probados para modos de paridad. Si necesitas paridad, considera usar mdadm por debajo con un perfil simple de btrfs encima—o elige ZFS RAIDZ.

Error 4: Ejecutar btrfs balance de forma casual en producción ocupada

Síntoma: Picos de latencia IO, timeouts de aplicaciones, “nada cambió” salvo “alguien ejecutó mantenimiento”.

Solución: Usa balance filtrado (-dusage= / -musage=) y prográmalo. Monitoriza. Trata balance como un trabajo de migración de almacenamiento, no como un script de limpieza.

Error 5: “Optimizar” ajustes sync de ZFS para mejorar benchmarks

Síntoma: La carga es ultrarrápida—hasta un evento de energía o crash, entonces la integridad de datos se convierte en reunión.

Solución: Mantén sync=standard a menos que entiendas completamente las expectativas de durabilidad de la aplicación. Si necesitas sync más rápido, considera dispositivos SLOG adecuados con protección contra pérdida de energía y valida mejoras de latencia con cargas reales.

Error 6: Ignorar scrubs porque “el pool está online”

Síntoma: El primer scrub en un año encuentra errores; ahora estás depurando historia de corrupción en lugar de prevenirla.

Solución: Programa scrubs: mensual es común para pools grandes; más frecuente para discos de consumo o entornos duros. Revisa resultados. Reemplaza hardware intermitente temprano.

Error 7: Explosión de instantáneas sin política de retención

Síntoma: “El espacio desapareció”, las eliminaciones no liberan espacio, backups fallan por poco espacio, el rendimiento se degrada.

Solución: Aplica retención de instantáneas (horarias/diarias/semanales) y poda automática. Rastrea el espacio usado por instantáneas (ZFS: usedbysnapshots; btrfs: uso por subvolumen y qgroups si se usan).

Listas de verificación / plan paso a paso

Checklist A: Elegir entre ZFS y btrfs (decisión de producción)

Define el modelo de fallo: ¿disco único? ¿dos discos? ¿el controlador miente? ¿bit rot? ¿error humano? ¿ransomware y radio de daño?
Define la carga: VMs, bases de datos, object storage, backups, directorios home de desarrolladores, root de OS.
Decide enfoque de redundancia: mirror/RAIDZ de ZFS vs RAID1/10 de btrfs (o mdadm + btrfs).
Decide estrategia de instantáneas: qué datasets/subvolúmenes reciben instantáneas; retención; cadena de replicación; protección contra eliminación.
Planifica observabilidad: cronogramas de scrub, alertas en errores de dispositivo, previsión de capacidad, alarmas de crecimiento de instantáneas.
Ensaya la recuperación: reemplazar un disco; revertir una instantánea; restaurar un dataset replicado en un host limpio.

Checklist B: Plan de despliegue ZFS (aburrido, correcto, repetible)

Elige geometría de vdev: mirrors para IOPS/latencia; RAIDZ2 para capacidad + resiliencia; evita un vdev ancho heroico para cargas mixtas.
Establece ashift correctamente (usualmente 12) al crear el pool; no quieras “descubrir” el tamaño de sector después.
Define datasets por carga; ajusta recordsize, compression, atime.
Configura política de instantáneas y replicación; verifica envíos incrementales.
Programa scrubs y alerta sobre cambios en zpool status y errores de checksum.
Documenta el procedimiento de reemplazo de discos y mantén capacidad libre para resilvers.

Checklist C: Plan de despliegue btrfs (primeros carriles seguros)

Decide si será disco único, RAID1 o RAID10. Trata RAID de paridad como un proyecto especial, no por defecto.
Usa subvolúmenes como límites; instantanea los que puedas razonablemente revertir.
Activa compresión (zstd es una opción común) y opciones de montaje consistentes.
Planifica operaciones balance: filtradas, programadas y monitorizadas.
Scrub periódicamente; vigila estadísticas de dispositivo; investiga errores IO temprano.
Prueba restores con send/receive; conserva snapshots padres hasta que los hijos estén replicados de forma segura.

Tres mini-historias del mundo corporativo (plausibles, técnicamente precisas y dolorosas)

Mini-historia 1: El incidente causado por una suposición equivocada

Tenían una configuración bonita: btrfs en un par de SSDs, instantáneas cada hora y un tablero orgulloso que mostraba “conteo de instantáneas: saludable”. Un ingeniero junior preguntó lo obvio—“¿estamos haciendo backup fuera del host?”—y le respondieron con un gesto y “las instantáneas son básicamente backups; podemos revertir todo”. Esa frase es el equivalente en almacenamiento a dejar las llaves dentro del coche porque tienes seguro.

El incidente no fue dramático al principio. Un bug de firmware en un SSD empezó a generar errores de lectura intermitentes y luego escaló a que el disco desapareciera del bus. El sistema siguió funcionando; la redundancia cubrió la falla inmediata. El equipo reemplazó el disco. Luego, una semana después, el segundo SSD mostró comportamiento similar—mismo lote, mismo firmware, distinto momento. De pronto la máquina cayó y el sistema de archivos quedó inaccesible.

La reunión incómoda no fue sobre la falla. Los discos fallan; por eso espejamos. La reunión fue sobre el descubrimiento de que su “plan de backup” vivía en el mismo chasis. Las instantáneas estaban impecables e inútiles. La ruta de restauración era “esperar que el proveedor recupere NAND”, que no es un plan tanto como una plegaria con orden de compra.

Lo que cambiaron después fue deliciosamente aburrido: replicación fuera del host usando send/receive a un sistema separado, más pruebas de restauración mensuales. El equipo dejó de discutir si las instantáneas son backups, porque tenían una invitación de calendario que probaba que la restauración funcionó.

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

Un clúster de virtualización se trasladó a ZFS en Linux porque el equipo quería instantáneas limpias y replicación. Las pruebas iniciales mostraron buen rendimiento. Luego alguien notó que cargas heavy en sync eran “un poco lentas”, y un entusiasta del rendimiento propuso una “solución”: desactivar las semánticas sync en el dataset de VM. Hizo que las gráficas se vieran increíbles.

Durante un tiempo, todos estuvieron felices. La latencia bajó, el throughput subió y el equipo de almacenamiento parecía mago. La única disidencia venía de la persona que seguía preguntando, “¿qué piensa la base de datos que significa fsync?” A nadie le gusta esa persona hasta que tiene razón.

Entonces vino un evento de energía no programado—nada exótico, solo un fallo en la instalación más una UPS que hizo su mejor imitación de caja decorativa. Varias VMs arrancaron, pero un subconjunto tenía estado de aplicación corrupto. Una base de datos se recuperó. Otra no. La causa raíz no fue misteriosa: el dataset estaba configurado de forma que permitía que escrituras reconocidas evaporaran en crash. ZFS hizo exactamente lo que le dijeron. El sistema de archivos no los mordió; la configuración lo hizo.

El postmortem fue clásico: restaurar desde réplicas, luego volver a ajustes sync seguros, luego añadir un camino de sync de baja latencia donde importaba. También aprendieron una lección dolorosa pero útil: benchmarks no son pruebas de durabilidad. Si cambias semánticas, cambias el contrato—no solo la velocidad.

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

Un equipo gestionaba ZFS para un servicio de ficheros que todos olvidaron hasta que se rompió—que es el mayor cumplido que puedes hacer al almacenamiento. Tenían dos hábitos que parecían molesta y anticuadamente correctos: scrubs mensuales y revisiones rutinarias de alertas de salud del pool. No “cuando nos acordemos”, sino realmente programado, con un runbook de on-call.

Durante un scrub, ZFS reportó un pequeño número de errores de checksum en un disco. El rendimiento parecía normal; los usuarios no se quejaban. La tentación fue ignorarlo. Pero los checksums no mienten por diversión, y ZFS no es de melodramas. Revisaron SMART, encontraron un aumento en el contador de sectores realocados y reemplazaron el disco en horario de oficina.

Semanas más tarde, otro disco del mismo chasis sufrió una falla repentina. Si no hubieran reemplazado proactivamente el primer disco, esa segunda falla habría ocurrido durante una ventana degradada. En su lugar, el pool siguió funcionando. El ticket del incidente fue un no-evento: “Disco falló; reemplazado; resilver completado; sin pérdida de datos.”

Esta es la verdad secreta del almacenamiento fiable: la historia de recuperación heroica rara vez es señal de excelencia. La mejor historia de almacenamiento es la que nadie cuenta porque no pasó nada interesante.

Preguntas frecuentes

1) ¿Es ZFS “más seguro” que btrfs?

En muchas configuraciones de producción, ZFS tiene una historia de integridad y recuperación más consistentemente predecible, especialmente con configuraciones multi-disco RAIDZ/mirror. btrfs también puede ser muy seguro—particularmente disco único o RAID1/10 con operaciones disciplinadas—pero su perfil de riesgo depende más de las características que uses.

2) ¿Puedo usar btrfs como ZFS con instantáneas y replicación?

Sí: las instantáneas de subvolumen de btrfs más btrfs send/receive pueden ofrecer un flujo de trabajo de replicación eficiente. La trampa es la disciplina operativa: debes gestionar cadenas de snapshots padres e retención cuidadosamente, y deberías probar restauraciones rutinariamente.

3) ¿Cuál es la diferencia práctica entre RAIDZ de ZFS y perfiles RAID de btrfs?

RAIDZ de ZFS forma parte de un diseño de pool unificado donde la redundancia se define por vdevs y es central para la identidad del pool. btrfs usa perfiles por chunk para datos y metadata que puedes convertir con balance. ZFS es más rígido pero más determinista; btrfs es más flexible pero requiere elecciones operativas más cuidadas.

4) ¿Son obligatorios los scrubs?

Si te importa la integridad, sí. Los scrubs son cómo encuentras errores latentes mientras aún existe redundancia. Sin scrubs, descubres corrupción solo cuando lees los datos afectados—a menudo durante restores o auditorías, que es el peor momento para enterarte.

5) ¿Cuándo debería usar compresión?

A menudo por defecto en ambos sistemas, especialmente con zstd. La compresión frecuentemente mejora el rendimiento porque menos bytes van al disco. Las excepciones son medios ya comprimidos y sistemas limitados en CPU; aun así, prueba en lugar de asumir.

6) ¿Necesito RAM ECC para ZFS?

ECC está fuertemente recomendado para cualquier sistema de almacenamiento serio, independientemente del sistema de archivos. ZFS se beneficia de ECC porque es agresivo con la caché y la integridad. Pero “sin ECC” no significa automáticamente “no uses ZFS”; significa entender tu riesgo y monitorizar más de cerca.

7) ¿Por qué mis eliminaciones no liberan espacio cuando tengo instantáneas?

Porque las instantáneas retienen referencias a bloques antiguos. Borrar archivos los quita de la vista en vivo, pero los bloques siguen referenciados por instantáneas. En ZFS inspecciona usedbysnapshots. En btrfs inspecciona uso de snapshot/subvolumen y considera cuotas (qgroups) si necesitas aplicación.

8) ¿Debería poner ZFS sobre RAID hardware?

Por lo general no. ZFS quiere acceso directo a discos para gestionar correctamente la redundancia y el reporte de errores. Si debes usar un controlador RAID, configúralo en modo HBA/JBOD si es posible. “Doble RAID” a menudo resulta en peor visibilidad de fallos y recuperación más confusa.

9) ¿Cuál es la configuración multi-disco btrfs más simple y segura?

RAID1 para datos y metadata en dos dispositivos es una base común relativamente aburrida. RAID10 también es sólido cuando tienes cuatro o más dispositivos y quieres mejor rendimiento y características de resiliencia.

10) ¿Cuál es la configuración ZFS más simple y segura?

Mirrors. Un pool de vdevs mirror escala previsiblemente para IO aleatorio y mantiene la recuperación sencilla. RAIDZ2 también es común cuando importa la eficiencia de capacidad, pero diseña con cuidado para la carga y el riesgo de reconstrucción.

Conclusión

Si quieres el sistema de archivos que más consistentemente se comporta como un SRE disciplinado—rastreando checksums, señalando el disco culpable, haciendo de la replicación un hábito de primera clase—ZFS es la apuesta más segura, especialmente para pools multi-disco y retención larga. No es sin esfuerzo, pero es coherente, y la coherencia es la mitad de la fiabilidad.

Si quieres integración nativa en el kernel, flujos elegantes de instantáneas por subvolumen y un sistema que es excelente para rollback a nivel OS y razonablemente seguro en almacenamiento espejado, btrfs es una opción sólida—siempre que te mantengas en caminos bien iluminados (single/RAID1/RAID10) y trates las operaciones de mantenimiento como eventos de producción reales.

De todos modos, el sistema de archivos no te salva de no practicar. Ejecuta scrubs. Prueba restauraciones. Mantén las políticas de instantáneas aburridas. Y recuerda: el mejor sistema de almacenamiento es el que convierte desastres en tickets de mantenimiento de rutina.