Cómo usar subvolúmenes de Btrfs: guía completa y práctica

Si vienes de ext4 o XFS y estás mirando Btrfs con cara rara, es totalmente normal: no es “otro sistema de archivos más”, sino una especie de combo entre sistema de ficheros, RAID y gestor de volúmenes. En cuanto empiezas a ver cosas como subvolúmenes, snapshots, balanceos o scrubs, parece que se complique todo, pero realmente son piezas que encajan entre sí.

En este artículo vamos a ver cómo usar subvolúmenes Btrfs y qué sentido tienen en instalaciones típicas (por ejemplo Arch, Debian, openSUSE o NAS con Synology/QNAP), cómo se relacionan con snapshots, RAID, compresión y lo que implica esto para el espacio en disco. Además, verás ejemplos de comandos reales para crear sistemas de archivos, subvolúmenes, instantáneas y manejar discos múltiples, así como algunos problemas típicos (el famoso ENOSPC con espacio “libre”).

Qué es Btrfs y por qué es distinto

Btrfs es un sistema de archivos de nueva generación para GNU/Linux diseñado para escalar desde un simple SSD hasta pools de varios discos con redundancia, snapshots y compresión. Lleva integrado en el kernel desde la versión 2.6.29 y, aunque su desarrollo sigue activo, el formato en disco está estabilizado, así que un sistema Btrfs creado hoy seguirá siendo legible en kernels futuros.

A diferencia de sistemas más clásicos como ext4 o XFS, Btrfs integra funciones que antes se repartían entre el sistema de ficheros, el RAID por software (mdadm) y el gestor de volúmenes lógicos (LVM). Con un solo stack tienes gestión de múltiples dispositivos, perfiles RAID, snapshots, subvolúmenes, verificaciones de integridad y más.

Principios clave de Btrfs: COW, snapshots, RAID y checksums

La pieza central de Btrfs es el modelo Copy-on-Write (COW). Cuando modificas datos, el sistema no los sobreescribe en el mismo sitio, sino que escribe los bloques nuevos en otra parte y actualiza las referencias. Esto permite clones casi instantáneos de ficheros y subvolúmenes, así como snapshots muy baratos en tiempo y espacio.

Este diseño se apoya en que cada bloque de datos y metadatos lleva su suma de verificación (checksum, habitualmente CRC32C). Al leer un bloque, Btrfs comprueba el checksum; si no coincide y existe otra copia (por ejemplo, en RAID1 o RAID10), lee la réplica sana y repara el error al vuelo. Esto protege de la corrupción silenciosa, algo que ext4 por sí solo no detecta.

Además, Btrfs incorpora de serie soporte para varios dispositivos con perfiles tipo RAID0, RAID1, RAID10, RAID5 y RAID6, configurable por separado para datos (-d) y metadatos (-m). Internamente no es un RAID clásico de bloques como mdadm, sino replicación y striping a nivel de “chunks” gestionados por el propio sistema de ficheros.

Por último, Btrfs puede aplicar compresión transparente al vuelo (zlib, lzo, zstd): los datos se comprimen antes de escribirse y se descomprimen al leerlos, de forma completamente transparente para las aplicaciones. Esto reduce el espacio consumido y, en muchos casos, incluso acelera las lecturas en discos lentos o mecánicos.

Creación de un sistema de archivos Btrfs

Para empezar a jugar con subvolúmenes necesitas primero un sistema de ficheros Btrfs en un dispositivo. La creación básica es muy similar a cualquier mkfs:

mkfs.btrfs /dev/sdb

Este comando inicializa /dev/sdb con Btrfs, sin RAID ni historias adicionales. Puedes usar un disco completo o una partición. Después, lo montas en un punto de montaje, por ejemplo:

mount /dev/sdb /mnt/btrfs

Si quieres desde el principio un sistema multidispositivo, simplemente añades varios dispositivos al comando de creación:

mkfs.btrfs /dev/sdc /dev/sdd

En este caso, Btrfs crea un pool lógico con la capacidad agregada de los dispositivos (por defecto, datos en “single” y metadatos duplicados tipo RAID1, salvo que especifiques lo contrario). Cuando lo montes, bastará con indicar uno de los dispositivos, por ejemplo /dev/sdc.

Perfiles RAID nativos y gestión dinámica del pool

Al crear el sistema de archivos puedes indicar ya el perfil de redundancia para datos y metadatos con las opciones -d y -m: valores como raid0, raid1, raid10, raid5, raid6 o single. Un ejemplo típico de RAID1 en Btrfs sería:

mkfs.btrfs -d raid1 -m raid1 /dev/sdc /dev/sdd

A diferencia de un RAID1 clásico, en Btrfs no tienes espejos idénticos bloque a bloque. Lo que se garantiza es que cada bloque de datos o metadatos tenga al menos dos copias en dispositivos diferentes, pero no hay discos “gemelos” como tal, y además se permiten tamaños de discos distintos.

Una vez montado el sistema, puedes añadir y eliminar discos en caliente del pool usando comandos como:

btrfs device add /dev/sdb /mnt/btrfs
btrfs device delete /dev/sdc /mnt/btrfs

Tras añadir dispositivos suele interesar lanzar un balanceo de datos para redistribuir los chunks existentes entre todos los discos:

btrfs filesystem balance /mnt/btrfs

Este balanceo reubica bloques según el perfil RAID elegido, de forma que todos los discos colaboren y se use el espacio de forma más uniforme. Es una operación online: el sistema de archivos sigue siendo accesible mientras se ejecuta.

Cómo cambiar de single a RAID1 sin reinstalar

Una de las gracias de Btrfs es que puedes convertir un sistema ya en uso a otro perfil RAID sin desmontar ni reinstalar. Imagina que tienes tu raíz en Btrfs sobre un único disco /dev/sda1 y quieres pasar a RAID1 añadiendo /dev/sdb1.

Los pasos serían añadir el nuevo dispositivo y lanzar un balanceo con conversión de perfil:

btrfs device add /dev/sdb1 /
btrfs balance start -dconvert=raid1 -mconvert=raid1 /

Durante este proceso, Btrfs irá reubicando los chunks para que todos los datos y metadatos queden duplicados en ambos discos. Al finalizar, un “btrfs filesystem show /” mostrará dos dispositivos con uso similar y “btrfs filesystem df /” reflejará los perfiles RAID1 para Data, Metadata y System.

RAID degradado y reparación con Btrfs

Si en una configuración con RAID1 nativo falla uno de los discos, el sistema entra en modo degradado. En Btrfs, para poder montar ese sistema necesitas la opción:

mount -o degraded /dev/sdb /mnt/btrfs

Mientras el sistema esté en este estado, Btrfs seguirá sirviendo los datos desde las copias sanas, pero no contará con redundancia completa. El procedimiento correcto es añadir un disco nuevo, eliminar el dispositivo “missing” del pool y lanzar un balanceo para re-replicar los bloques.

En situaciones de corrupción puntual o discos problemáticos, también tienes la opción de lanzar un scrub, que recorre todos los bloques, verifica checksums y repara desde la copia buena si es posible:

btrfs scrub start /mnt/btrfs
btrfs scrub status /mnt/btrfs

Este scrub se ejecuta en segundo plano mientras el sistema está montado, por lo que conviene programarlo en horas de poca carga, especialmente en servidores o NAS.

Compresión transparente: zlib, lzo, zstd

Montando el sistema con la opción compress o compress=<algo> activas la compresión automática de los datos que se escriban a partir de ese momento. Por ejemplo:

mount -o compress=zstd /dev/sdb /mnt/btrfs

El sistema almacenará en disco los bloques comprimidos, pero al hacer un ls o un stat seguirás viendo el tamaño lógico sin comprimir. La ganancia se aprecia en herramientas como df (menos espacio usado) o en “btrfs filesystem df”, o bien usando utilidades como compsize.

Los algoritmos disponibles ofrecen un equilibrio distinto entre ratio de compresión y consumo de CPU:

• zlib: comprime mucho, pero es más lento; útil para datos muy estáticos.
• lzo: muy rápido, pero comprime menos; buena opción para sistemas con mucha escritura.
• zstd: equilibrio muy interesante, con varios niveles configurables.

También puedes ajustar el nivel de compresión en el montaje, por ejemplo zstd:1 para priorizar velocidad o zstd:15 para apretar al máximo a costa de CPU. Estos parámetros se reflejan en /proc/mounts y en mensajes de dmesg cuando se monta el sistema.

Copy-on-Write en ficheros: clones instantáneos con reflinks

El mecanismo COW a nivel de fichero se expone, por ejemplo, mediante la opción –reflink=always de cp. Al copiar un fichero grande dentro de Btrfs con reflink, no se duplican los datos en disco, solo se crean referencias adicionales a los mismos bloques:

cp --reflink=always imagen.iso copia1.iso

La copia aparece inmediatamente y ocupa cero espacio adicional al principio. Solo cuando alguno de los ficheros se modifica, los bloques afectados se copian físicamente (Copy-on-Write real). Esto es tremendamente útil para plantillas de máquinas virtuales, imágenes base, etc.

De la misma lógica tiran las instantáneas (snapshots) de subvolúmenes, que no son más que clones COW de un subvolumen entero. Al crearlas, apenas ocupan algo de metadatos; el consumo real vendrá después, según divergentes los contenidos entre original y snapshot.

Subvolúmenes Btrfs: qué son y para qué sirven

Un subvolumen en Btrfs es, en la práctica, un “mini sistema de archivos” dentro del sistema principal. El Btrfs completo siempre tiene al menos un subvolumen (el top level), y sobre él puedes ir creando otros, que desde fuera se ven como simples directorios.

La gracia es que cada subvolumen se puede montar de forma independiente, tener sus propios snapshots, cuotas (con el sistema de cuotas activado) y políticas de backup. Todo ello compartiendo el mismo pool de almacenamiento y la misma configuración RAID del volumen padre.

Para crear varios subvolúmenes sobre un Btrfs ya montado en /mnt/btrfs, harías algo como:

btrfs subvolume create /mnt/btrfs/subvolumen1
btrfs subvolume create /mnt/btrfs/subvolumen2
btrfs subvolume create /mnt/btrfs/subvolumen3

Estos subvolúmenes aparecerán como directorios en /mnt/btrfs, pero si listas con btrfs verás sus IDs y rutas internas:

btrfs subvolume list /mnt/btrfs

Una vez tengas el ID (por ejemplo, 256 para subvolumen1), puedes montar solo ese subvolumen en otra ruta:

mount -o subvolid=256 /dev/sdb /mnt/subvol1

De esta forma, los datos de ese subvolumen se pueden acceder como /mnt/btrfs/subvolumen1 y /mnt/subvol1 simultáneamente, pero es el mismo contenido. Resulta muy útil para separar /, /home, /var o datasets específicos sin recurrir a particiones clásicas.

Diseño de subvolúmenes: ejemplos prácticos (Arch, Debian, NAS)

Una estructura muy típica en una máquina de escritorio puede ser:

• @ para la raíz (/) sin /home ni /var/lib/docker.
• @home para /home con tus datos personales.
• @var o subvolúmenes específicos como @var-log, @var-cache, etc.
• @snapshots para almacenar snapshots organizados por fecha.

Esto permite que una herramienta como snapper para snapshots del sistema, Timeshift o btrbk pueda crear snapshots solo del sistema (subvolumen @) para revertir actualizaciones, mientras que los documentos del usuario (en @home) se protegen o sincronizan con otra lógica diferente.

En un NAS con Synology o QNAP, lo que se hace realmente es crear carpetas compartidas sobre subvolúmenes Btrfs, de modo que Snapshot Replication pueda tomar instantáneas de esas carpetas, clonarlas o replicarlas a otro NAS. La misma idea, pero empaquetada en interfaz gráfica.

Snapshots de subvolúmenes: rollback y copias en segundos

Las instantáneas en Btrfs son simplemente subvolúmenes creados como snapshot de otro. Para crear un snapshot de /mnt/btrfs/subvolumen1 en otro subvolumen snapshot_sub1:

btrfs subvolume snapshot \
  /mnt/btrfs/subvolumen1 \
  /mnt/btrfs/subvolumen1_snapshot

Si después haces un “btrfs subvolume list”, verás un nuevo ID y ruta para este snapshot. Desde ese momento, ambos son independientes a nivel lógico: cambios en uno no afectan al otro, aunque internamente compartan bloques hasta que se modifiquen.

Esto se utiliza tanto para copias de seguridad rápidas (por ejemplo, antes de una actualización de sistema) como para laboratorios, pruebas, entornos de desarrollo, etc. Restaurar un snapshot suele reducirse a montar el snapshot y usarlo como nuevo subvolumen por defecto, o bien copiar los datos de vuelta.

Uso de Btrfs en discos múltiples con RAID

Con Btrfs, la gestión de múltiples discos se hace desde el propio sistema de archivos. Al crear el volumen puedes definir perfiles distintos para datos y metadatos, por ejemplo datos en RAID5 y metadatos en RAID1 si cuentas con tres o más dispositivos:

mkfs.btrfs -d raid5 -m raid1 /dev/sdb /dev/sdc /dev/sdd

Este tipo de perfil ofrece striping y paridad para datos (mejores lecturas y tolerancia a fallos) y redundancia fuerte para metadatos, a costa de algo de espacio extra. No obstante, RAID5/6 en Btrfs ha tenido históricamente bugs importantes; si el entorno es crítico muchos administradores siguen prefiriendo RAID1/10.

Si inicialmente creaste un pool con RAID1 y más tarde quieres aprovechar mejor el espacio, siempre puedes convertir perfiles sobre la marcha con balance:

btrfs balance start -dconvert=raid5 -mconvert=raid1 /srv

De igual forma, añadir o eliminar dispositivos se hace con btrfs device add/remove y un balanceo posterior para reubicar chunks. El comando “btrfs filesystem show” te da una panorámica del estado, tamaño y uso de cada disco en el pool.

Gestión del espacio: por qué du y df “mienten” en Btrfs

Uno de los puntos más confusos de Btrfs es que las herramientas clásicas df y du no reflejan bien la realidad. La mezcla de RAID a nivel de chunks, COW, snapshots y compresión hace que las suposiciones de “1 MiB escrito = 1 MiB ocupado” no se cumplan.

En Btrfs, el espacio se reserva en grandes “rodajas” (chunks), típicamente de 1 GiB para datos y 256 MiB para metadatos. Cada chunk se asigna con el perfil correspondiente: single, RAID1, RAID10, etc. Dentro de un chunk, sí, 1 MiB escrito es 1 MiB usado, pero la forma en que se combinan varios chunks y copias de bloques hace que el cálculo sencillo se rompa.

Además, con COW y snapshots, borrar un fichero no garantiza que sus bloques se liberen: si esos bloques son compartidos con otra instantánea o clon reflink, seguirán ocupando espacio hasta que no quede ninguna referencia a ellos. De ahí la sensación de “borro cosas y el espacio no vuelve”.

Por este motivo, Btrfs aporta comandos específicos como “btrfs filesystem df <path>”, que muestran desglose de uso de Data, Metadata y System por perfil, y “btrfs filesystem show <device>”, que enseña qué parte de cada disco está reservada y usada en crudo.

Buenas prácticas con subvolúmenes y snapshots en el día a día

Si estás montando, por ejemplo, Arch Linux con Btrfs en un solo SSD, una estrategia muy recomendable es:

• Crear un Btrfs único sobre la partición raíz.
• Definir subvolúmenes separados para / (sistema), /home, /var/log, quizá /var/lib/libvirt o /var/lib/docker.
• Montar cada subvolumen con opciones de compresión adecuadas (zstd o lzo) y, si quieres, autodefrag para cargas con muchos pequeños ficheros.
• Usar Snapper, Timeshift o btrbk para automatizar snapshots del subvolumen de sistema antes y después de las actualizaciones.

En una máquina física con varios SSD, puedes optar por un único Btrfs multidispositivo con RAID1/10 y subvolúmenes lógicos, o por varios Btrfs separados. A efectos de subvolúmenes, no cambia gran cosa: siguen siendo entidades lógicas dentro del volumen Btrfs en el que están; lo importante es definir desde el principio qué datos quieres poder snapshoter y revertir de forma independiente.

En cuanto a copias de seguridad completas, ten en cuenta que snapshots no son backups externos. Snapper o Timeshift suelen usarse para snapshots locales (principalmente del sistema), y para copias de seguridad reales de todo (incluyendo /home) conviene apoyarse en herramientas como borg, restic, rsync, btrbk remoto o las propias soluciones de snapshot/replicación de los NAS.

Administración básica y comandos útiles de Btrfs

La CLI de Btrfs puede parecer un poco verbosa, pero permite abreviar los subcomandos usando prefijos únicos. Por ejemplo, en lugar de “btrfs filesystem defragment /” puedes usar “btrfs fi de /” si no hay ambigüedad.

Algunos comandos esenciales que usarás con frecuencia son:

• mkfs.btrfs: crear sistemas de archivos, con opciones de RAID y etiquetas.
• btrfs filesystem show/df: ver dispositivos, uso y perfiles.
• btrfs device add/delete: añadir o quitar discos del pool.
• btrfs balance start: reequilibrar datos y convertir perfiles RAID.
• btrfs scrub start/status: verificar y reparar bloques con checksums.
• btrfs subvolume create/list/delete/snapshot: gestionar subvolúmenes y snapshots.
• btrfs check: comprobar el sistema de archivos offline (con precaución).

También es importante recordar que no se debe pasar fsck tradicional a un Btrfs en cada arranque; en fstab, el último campo de las entradas Btrfs debe ser 0 para evitar chequeos automáticos inadecuados.

Con este conjunto de conceptos y comandos, Btrfs deja de ser esa “caja negra rara” y pasa a ser una herramienta muy flexible con la que puedes organizar tu sistema de forma lógica con subvolúmenes, aprovechar snapshots de verdad útiles y combinar todo ello con redundancia y compresión, tanto en un simple portátil como en un pool de múltiples discos.