Cómo configurar Btrfs Send y Receive para copias de seguridad incrementales externas

Btrfs send y receive pueden convertir las instantáneas de subvolúmenes de solo lectura en una cadena eficiente de replicación externa. La primera transferencia envía una instantánea completa. Las transferencias posteriores utilizan una instantánea replicada anteriormente como elemento principal, por lo que solo atraviesan la red los cambios necesarios para reconstruir la nueva instantánea.

En ZimaOS, confirma primero que tanto el destino de origen como el externo sean realmente sistemas de archivos Btrfs y que haya acceso SSH disponible. La guía de formatos de disco de ZimaSpace indica compatibilidad de lectura y escritura con BTRFS, y la guía de SSH de ZimaOS explica cómo habilitar el acceso al terminal desde el Modo de desarrollador.

Comprende la cadena de respaldo antes de comenzar

Btrfs send/receive es replicación de subvolúmenes, no un comando genérico para copiar directorios. El origen debe ser un subvolumen Btrfs, y cada instantánea utilizada por btrfs send debe ser de solo lectura. Un montaje de solo lectura no sustituye a una instantánea de subvolumen de solo lectura.

La documentación oficial de btrfs send describe dos modos. Un envío completo contiene la instantánea completa. Un envío incremental utiliza -p o -c con instantáneas disponibles en el mismo estado tanto en el emisor como en el receptor.

Para una cadena externa sencilla, utiliza un elemento principal explícito con -p:

snapshot-A  --full send-->  instantánea externa snapshot-A
snapshot-B  --send -p A-->  instantánea externa snapshot-B
snapshot-C  --send -p B-->  instantánea externa snapshot-C

No elimines ni modifiques el elemento principal actual hasta que la siguiente transferencia incremental haya finalizado y se haya verificado.

Verifica que el origen sea un subvolumen Btrfs

Reemplaza las rutas de ejemplo por los puntos de montaje reales de tu sistema. El directorio de instantáneas debe estar fuera del subvolumen de origen activo para que las instantáneas de respaldo no queden anidadas dentro de los datos que se protegen.

findmnt -no FSTYPE --target /mnt/pool/data
sudo btrfs subvolume show /mnt/pool/data
sudo btrfs version

El primer comando debería mostrar btrfs. El segundo debe identificar correctamente /mnt/pool/data como subvolumen. Si solo es un directorio normal, detente aquí: btrfs send no puede enviar un directorio arbitrario.

Ejecuta la misma comprobación del sistema de archivos en el sistema externo para la ubicación de recepción. btrfs receive debe crear su subvolumen replicado en un sistema de archivos Btrfs.

Prepara SSH antes de transmitir los datos de la copia de seguridad

Un flujo de envío externo es un flujo binario de datos del sistema de archivos. SSH es un transporte práctico porque proporciona autenticación y cifrado durante el tránsito. Si usas ZimaOS en cualquiera de los extremos, habilita primero SSH y prueba un inicio de sesión normal antes de intentar un flujo de Btrfs.

ssh backup@backup.example.net

Para trabajos desatendidos, usa autenticación SSH basada en claves. La cuenta remota también debe poder ejecutar btrfs receive de forma no interactiva. No permitas que un sudo solicitud de contraseña leída de la misma entrada estándar que transporta el flujo de Btrfs. Una regla de privilegios con alcance limitado para la operación de recepción necesaria es más segura que un acceso root amplio sin contraseña.

Crea el directorio de destino durante una sesión administrativa interactiva:

ssh -t backup@backup.example.net \
  'sudo mkdir -p /mnt/backup/btrfs-recv'

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Crea la primera instantánea de solo lectura

Crea una instantánea fija de solo lectura del subvolumen de origen activo. La -r esta marca es importante porque el envío incremental de Btrfs depende de instantáneas que no pueden cambiar durante la operación de envío.

sudo mkdir -p /mnt/pool/.snapshots

sudo btrfs subvolume snapshot -r \
  /mnt/pool/data \
  /mnt/pool/.snapshots/data-20260831-1000

Confirma la propiedad antes de enviar:

sudo btrfs property get \
  /mnt/pool/.snapshots/data-20260831-1000 ro

El resultado esperado es ro=true.

Envía la primera instantánea completa fuera del sitio

La primera transferencia no tiene padre, por lo que es un envío completo. En un shell compatible con Bash, habilitar pipefail hace visible ante el shell invocador cualquier fallo en uno de los lados de la canalización.

set -o pipefail

sudo btrfs send \
  /mnt/pool/.snapshots/data-20260831-1000 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

Si sudo -n falla en el host remoto, corrige la configuración de privilegios remotos antes de volver a intentarlo. No lo sustituyas por una solicitud de contraseña dentro de la canalización de transmisión.

La documentación oficial de btrfs receive indica que un subvolumen recibido pasa a ser de solo lectura correctamente. También advierte que no se debe modificar la ruta de recepción mientras se aplica un flujo.

Verifica la instantánea recibida antes de usarla como padre

No des por hecho que el cierre de una sesión SSH significa que la cadena de copias de seguridad está en buen estado. Inspecciona ambas instantáneas:

sudo btrfs subvolume show \
  /mnt/pool/.snapshots/data-20260831-1000

ssh backup@backup.example.net \
  'sudo -n btrfs subvolume show \
  /mnt/backup/btrfs-recv/data-20260831-1000'

En el emisor, observa la instantánea UUID. En el receptor, el subvolumen replicado debe mostrar ese identificador de origen como su UUID recibido. Confirma también que el subvolumen recibido sea de solo lectura.

Solo después de esta comprobación debe data-20260831-1000 convertirse en el padre de la siguiente copia de seguridad incremental.

Crea y envía la siguiente instantánea incremental

Después de que cambien los datos activos, crea una nueva instantánea de solo lectura:

sudo btrfs subvolume snapshot -r \
  /mnt/pool/data \
  /mnt/pool/.snapshots/data-20260901-0200

Después envía solo la diferencia respecto a la instantánea anterior:

set -o pipefail

sudo btrfs send \
  -p /mnt/pool/.snapshots/data-20260831-1000 \
  /mnt/pool/.snapshots/data-20260901-0200 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

Esto funciona porque la instantánea principal del primer envío sigue existiendo de forma coincidente en ambos sistemas. Después de que la nueva instantánea se reciba y verifique correctamente, data-20260901-0200 puede convertirse en la principal de la siguiente ejecución.

Mantén idénticas las instantáneas principales

La forma más habitual de romper una cadena incremental es cambiar el estado de solo lectura o el contenido de una instantánea que se utiliza como principal. Btrfs registra las instantáneas recibidas con un UUID recibido específicamente para que el emisor y el receptor puedan identificar el historial correspondiente.

La documentación oficial de Btrfs sobre los indicadores de subvolúmenes y los UUID recibidos advierte que cambiar una instantánea recibida de solo lectura a lectura y escritura rompe las suposiciones utilizadas por el envío incremental.

Por ese motivo, no hagas que la instantánea recibida externamente sea modificable solo para explorar, restaurar o editar archivos. Si necesitas una copia de recuperación modificable, crea una instantánea independiente a partir de la instantánea recibida protegida:

sudo btrfs subvolume snapshot \
  /mnt/backup/btrfs-recv/data-20260901-0200 \
  /mnt/restore/data-20260901-0200

La nueva instantánea de restauración es modificable de forma predeterminada, mientras que la instantánea recibida original permanece intacta para futuros envíos incrementales.

Usa una regla segura de retención de instantáneas

No necesitas conservar todas las instantáneas antiguas para siempre, pero debes conservar en ambos sistemas la principal que requiere el siguiente envío. Una regla de rotación sencilla es:

1. Crea la nueva instantánea de origen de solo lectura.
2. Envíala usando la instantánea correcta anterior como -p.
3. Verifica la nueva instantánea recibida externamente.
4. Promueve la nueva instantánea para que sea la siguiente principal.
5. Solo entonces elimina los puntos de recuperación antiguos según tu política de retención.

Conservar varias instantáneas históricas puede proporcionar puntos de reversión útiles, pero recuerda que una instantánea en el mismo sistema de archivos no es una copia de seguridad independiente. La réplica externa es valiosa porque coloca otra copia en un sistema y una ubicación separados. La guía de copias de seguridad 3-2-1 de ZimaSpace explica por qué una copia externa protege frente a fallos que la redundancia local no puede cubrir.

Gestionar por separado los subvolúmenes anidados de Btrfs

Las instantáneas de Btrfs no son recursivas en los subvolúmenes anidados. Si /mnt/pool/data contiene otro subvolumen, la instantánea principal contiene un indicador de subvolumen en lugar de una instantánea completa de los datos anidados.

Enumera los subvolúmenes antes de finalizar el plan de copias de seguridad:

sudo btrfs subvolume list /mnt/pool

Si hay datos de aplicaciones importantes en subvolúmenes anidados, crea y replica una cadena independiente de instantáneas de solo lectura para cada uno.

Saber cuándo usar -p y cuándo usar -c

Para un historial de copias de seguridad lineal, -p es la opción más sencilla y fácil de auditar. La -c La opción puede añadir una o más fuentes de clonación que permiten a Btrfs reutilizar extensiones coincidentes de instantáneas adicionales, pero esas fuentes de clonación también deben existir exactamente en el mismo estado en ambos extremos.

Si no puedes demostrar que una fuente de clonación no ha cambiado y está presente en ambos sistemas, no la uses. Una cadena sencilla con un solo elemento principal suele ser más segura para un trabajo de copia de seguridad externa.

Opcional: usar el protocolo 2 para extensiones comprimidas

En versiones suficientemente recientes de Linux y btrfs-progs, el protocolo de envío 2 de Btrfs puede transmitir extensiones comprimidas de forma más eficiente con --compressed-data. La documentación oficial del envío indica que el protocolo 2 requiere btrfs-progs 6.0 o posterior tanto en el emisor como en el receptor, y Linux 6.0 o posterior en el emisor.

sudo btrfs send \
  --proto 2 \
  --compressed-data \
  -p /mnt/pool/.snapshots/data-20260831-1000 \
  /mnt/pool/.snapshots/data-20260901-0200 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

No habilites esta opción solo porque exista. Comprueba primero las versiones en ambos extremos y usa el protocolo predeterminado cuando la compatibilidad sea más importante que la optimización.

Solución de problemas de errores comunes de envío y recepción incrementales

El comando de envío indica que la instantánea no es de solo lectura

Vuelve a crear la instantánea con btrfs subvolume snapshot -r. Montar simplemente una instantánea escribible mediante un montaje de solo lectura no cumple el requisito de envío.

El envío incremental no puede encontrar ni usar su elemento principal

Comprueba que la instantánea principal exacta todavía exista en el emisor y que su instantánea recibida correspondiente siga existiendo en el receptor. Si alguno de los elementos principales se eliminó, modificó o se hizo escribible, restaura un elemento principal coincidente si dispones de uno. De lo contrario, crea una nueva instantánea de solo lectura e inicia una nueva semilla completa.

btrfs receive indica que el subvolumen de destino ya existe

btrfs receive no sobrescribirá un subvolumen existente con el mismo nombre entrante. Inspecciona primero el subvolumen existente. Si se trata de una recepción fallida o incompleta y has confirmado que es seguro eliminarla, borra ese subvolumen incompleto antes de volver a intentar la misma transferencia.

La principal de recepción se modificó después de llegar

No uses esa instantánea modificada como base de un nuevo flujo incremental. Si no existe una principal de recepción coincidente y sin cambios, inicia una nueva cadena de copia de seguridad completa.

Faltan archivos dentro de un directorio anidado en la instantánea

Comprueba si ese directorio es, a su vez, un subvolumen Btrfs. Los subvolúmenes anidados no se incluyen recursivamente en la instantánea principal y necesitan su propia cadena de envío/recepción.

La conexión WAN o SSH se interrumpe durante una transferencia

Considera que la recepción ha fallado a menos que se complete correctamente y el subvolumen resultante se verifique de forma adecuada. La interfaz de comandos documentada de envío/recepción de Btrfs no proporciona una opción para reanudar un flujo. Para enlaces de larga distancia poco fiables, considera escribir el flujo de envío en un archivo de preparación, transferir ese archivo mediante un transporte reanudable y, después, pasar el archivo completo y de confianza a btrfs receive.

Protege el lado de recepción frente a flujos que no sean de confianza

Btrfs receive aplica operaciones del sistema de archivos a partir del flujo entrante. La documentación oficial de recepción desaconseja aceptar flujos de envío de fuentes que no sean de confianza y recomienda proteger la ruta de recepción contra escrituras simultáneas mientras se aplica un flujo.

Usa la verificación del host SSH, autenticación basada en claves, una cuenta de copia de seguridad dedicada y los privilegios más limitados posibles. Mantén el directorio de recepción fuera de las rutas de escritura normales de los usuarios mientras se ejecuta una copia de seguridad.

Usa esta lista de comprobación para cada ejecución incremental

• Confirma que ambos extremos sean Btrfs.
• Crea la nueva instantánea de origen con -r.
• Mantén sin cambios la principal anterior que tuvo éxito en ambos sistemas.
• Envía con btrfs send -p OLD NEW.
• Recibe mediante una conexión SSH autenticada y cifrada.
• Verifica que la operación haya tenido éxito y compara el UUID de origen con el UUID recibido del receptor.
• Mantén la instantánea de copia de seguridad recibida como de solo lectura.
• Crea una instantánea escribible independiente cuando necesites restaurar o probar datos.
• Rota las instantáneas antiguas solo después de verificar la nueva principal.
• Realiza copias de seguridad de los subvolúmenes anidados con cadenas independientes.

Una vez que una semilla completa y una ejecución incremental hayan tenido éxito manualmente, automatiza la misma secuencia con registros y comprobaciones explícitas del estado de salida. Lo importante no es el programador: es conservar una instantánea principal sin cambios y verificada en ambos extremos de cada paso incremental.