Come configurare Btrfs Send e Receive per backup incrementali fuori sede

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How to Configure Btrfs Send and Receive for Incremental Off-Site Backups - Zima Store Online

Btrfs send e receive possono trasformare gli snapshot di sottovolumi in sola lettura in un'efficiente catena di replica remota. Il primo trasferimento invia uno snapshot completo. I trasferimenti successivi usano uno snapshot precedentemente replicato come parent, quindi attraverso la rete passano solo le modifiche necessarie per ricostruire il nuovo snapshot.

Su ZimaOS, verifica innanzitutto che sia la sorgente sia la destinazione remota siano effettivamente filesystem Btrfs e che l'accesso SSH sia disponibile. La guida ai formati dei dischi di ZimaSpace elenca il supporto BTRFS in lettura/scrittura, mentre la guida SSH di ZimaOS mostra come abilitare l'accesso al terminale dalla Modalità sviluppatore.

Comprendi la catena di backup prima di iniziare

Btrfs send/receive è la replica di sottovolumi, non un comando generico per copiare directory. La sorgente deve essere un sottovolume Btrfs e ogni snapshot utilizzato da btrfs send deve essere di sola lettura. Un mount in sola lettura non sostituisce uno snapshot di sottovolume in sola lettura.

La documentazione ufficiale di btrfs send descrive due modalità. Un invio completo contiene lo snapshot intero. Un invio incrementale usa -p o -c con snapshot disponibili nello stesso stato sia sul mittente sia sul ricevitore.

Per una semplice catena remota, usa un parent esplicito con -p:

snapshot-A  --invio completo-->  snapshot-A remoto
snapshot-B  --send -p A-->  snapshot-B remoto
snapshot-C  --send -p B-->  snapshot-C remoto

Non eliminare né modificare il parent corrente finché il trasferimento incrementale successivo non è stato completato e verificato.

Verifica che la sorgente sia un sottovolume Btrfs

Sostituisci i percorsi di esempio con i punti di mount effettivi del tuo sistema. La directory degli snapshot deve trovarsi al di fuori del sottovolume sorgente attivo, in modo che gli snapshot di backup non diventino annidati nei dati protetti.

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

Il primo comando dovrebbe restituire btrfs. Il secondo deve identificare correttamente /mnt/pool/data come sottovolume. Se è solo una directory normale, fermati qui: btrfs send non può inviare una directory arbitraria.

Esegui lo stesso controllo del filesystem sul sistema remoto per la posizione di ricezione. btrfs receive deve creare il proprio sottovolume replicato su un filesystem Btrfs.

Preparare SSH prima di trasmettere i dati di backup

Un flusso di invio fuori sede contiene dati binari del file system. SSH è un trasporto pratico perché fornisce autenticazione e crittografia durante il transito. Se si usa ZimaOS su uno dei due endpoint, abilitare prima SSH e testare un normale accesso prima di tentare un flusso Btrfs.

ssh backup@backup.example.net

Per i processi non presidiati, usare l'autenticazione SSH basata su chiavi. L'account remoto deve inoltre poter eseguire btrfs receive in modo non interattivo. Non consentire a un sudo richiesta di password letta dallo stesso input standard che trasporta il flusso Btrfs. Una regola di privilegio con ambito limitato per l'operazione di ricezione richiesta è più sicura di un accesso root senza password eccessivamente ampio.

Creare la directory di destinazione durante una sessione amministrativa interattiva:

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

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Creare il primo snapshot di sola lettura

Creare uno snapshot di sola lettura fisso del sottovolume sorgente attivo. Il -r questo flag è importante perché l'invio incrementale di Btrfs dipende da snapshot che non possono cambiare durante l'operazione di invio.

sudo mkdir -p /mnt/pool/.snapshots

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

Confermare la proprietà prima dell'invio:

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

Il risultato previsto è ro=true.

Inviare lo snapshot completo iniziale fuori sede

Il primo trasferimento non ha un genitore, quindi è un invio completo. In una shell compatibile con Bash, abilitare pipefail rende visibile alla shell chiamante un errore su uno dei due lati della pipeline.

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'

Se sudo -n se fallisce sull'host remoto, correggere la configurazione dei privilegi remoti prima di riprovare. Non sostituirlo con una richiesta di password all'interno della pipeline di streaming.

La documentazione ufficiale di btrfs receive indica che un sottovolume ricevuto diventa di sola lettura. Avverte inoltre che gli utenti non devono modificare il percorso di ricezione mentre è in corso l'applicazione di un flusso.

Verificare lo snapshot ricevuto prima di usarlo come genitore

Non dare per scontato che la fine di una sessione SSH significhi che la catena di backup sia integra. Ispezionare entrambi gli snapshot:

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'

Sul mittente, annotare lo snapshot UUID. Sul ricevitore, il sottovolume replicato dovrebbe mostrare quell'identificatore di origine come proprio UUID ricevuto. Confermare inoltre che il sottovolume ricevuto sia di sola lettura.

Solo dopo questo controllo si dovrebbe data-20260831-1000 diventare il genitore per il prossimo backup incrementale.

Crea e invia il successivo snapshot incrementale

Dopo le modifiche ai dati attivi, crea un nuovo snapshot di sola lettura:

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

Quindi invia solo il delta dallo snapshot precedente:

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'

Questo funziona perché lo snapshot padre del primo invio esiste ancora in forma corrispondente su entrambi i sistemi. Dopo che il nuovo snapshot è stato ricevuto e verificato correttamente, data-20260901-0200 può diventare il padre dell'esecuzione successiva.

Mantieni identici gli snapshot padre

Il modo più comune per interrompere una catena incrementale consiste nel modificare lo stato di sola lettura o i contenuti di uno snapshot utilizzato come padre. Btrfs tiene traccia degli snapshot ricevuti con un UUID ricevuto proprio affinché mittente e destinatario possano identificare la cronologia corrispondente.

La guida ufficiale di Btrfs su flag dei sottovolumi e UUID ricevuti avverte che modificare uno snapshot ricevuto da sola lettura a lettura-scrittura rompe le condizioni previste dall'invio incrementale.

Per questo motivo, non rendere scrivibile lo snapshot ricevuto fuori sede solo per sfogliarlo, ripristinare dati o modificare file. Se ti serve una copia di ripristino scrivibile, crea uno snapshot separato dallo snapshot ricevuto protetto:

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

Il nuovo snapshot di ripristino è scrivibile per impostazione predefinita, mentre lo snapshot ricevuto originale rimane intatto per i futuri invii incrementali.

Usa una regola sicura per la conservazione degli snapshot

Non è necessario conservare per sempre ogni vecchio snapshot, ma devi mantenere su entrambi i sistemi il padre richiesto dal prossimo invio. Una semplice regola di rotazione è:

Crea il nuovo snapshot sorgente di sola lettura.
Invialo usando lo snapshot precedente riuscito come -p.
Verifica il nuovo snapshot ricevuto fuori sede.
Promuovi il nuovo snapshot a snapshot padre successivo.
Solo a quel punto rimuovi i punti di ripristino più vecchi in base ai criteri di conservazione.

Conservare diversi snapshot storici può fornire utili punti di ripristino, ma ricorda che uno snapshot sullo stesso filesystem non è un backup indipendente. La replica fuori sede è preziosa perché colloca un'altra copia su un sistema e in una posizione separati. La guida al backup 3-2-1 di ZimaSpace spiega perché una copia fuori sede protegge dai guasti che la ridondanza locale non può gestire.

Gestisci separatamente i sottovolumi Btrfs annidati

Gli snapshot Btrfs non sono ricorsivi tra sottovolumi annidati. Se /mnt/pool/data contiene un altro sottovolume, lo snapshot padre contiene uno stub del sottovolume anziché uno snapshot completo dei dati annidati.

Elenca i sottovolumi prima di definire il piano di backup:

sudo btrfs subvolume list /mnt/pool

Se dati applicativi importanti risiedono in sottovolumi annidati, crea e replica una catena separata di snapshot di sola lettura per ciascuno di essi.

Quando usare -p e quando usare -c

Per una cronologia di backup lineare, -p è l'opzione più semplice e facile da verificare. L'opzione -c l'opzione può aggiungere una o più sorgenti clone che consentono a Btrfs di riutilizzare gli extent corrispondenti di snapshot aggiuntivi, ma tali sorgenti clone devono esistere esattamente nello stesso stato su entrambe le estremità.

Se non puoi dimostrare che una sorgente clone sia invariata e presente su entrambi i sistemi, non utilizzarla. Per un processo di backup fuori sede, una semplice catena con un solo padre è generalmente più sicura.

Facoltativo: usa il protocollo 2 per gli extent compressi

Nelle versioni sufficientemente recenti di Linux e btrfs-progs, il protocollo 2 di invio di Btrfs può trasmettere gli extent compressi in modo più efficiente con --compressed-data. La documentazione ufficiale relativa all'invio indica che il protocollo 2 richiede btrfs-progs 6.0 o versioni successive sia sul mittente sia sul destinatario, oltre a Linux 6.0 o versioni successive sul mittente.

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'

Non abilitarlo solo perché l'opzione è disponibile. Controlla prima le versioni su entrambi gli endpoint e usa il protocollo predefinito quando la compatibilità è più importante dell'ottimizzazione.

Risoluzione dei problemi comuni relativi agli errori di invio e ricezione incrementali

Il comando send indica che lo snapshot non è di sola lettura

Ricrea lo snapshot con btrfs subvolume snapshot -rMontare semplicemente uno snapshot scrivibile tramite un montaggio di sola lettura non soddisfa il requisito per l'invio.

L'invio incrementale non riesce a trovare o utilizzare il proprio padre

Verifica che lo snapshot padre esatto esista ancora sul mittente e che lo snapshot ricevuto corrispondente esista ancora sul destinatario. Se uno dei due padri è stato eliminato, modificato o reso scrivibile, ripristina un padre corrispondente, se ne hai uno. Altrimenti crea un nuovo snapshot di sola lettura e avvia un nuovo seed completo.

btrfs receive indica che il sottovolume di destinazione esiste già

btrfs receive non sovrascriverà un sottovolume esistente con lo stesso nome in ingresso. Esamina prima il sottovolume esistente. Se si tratta di un receive non riuscito o incompleto e hai confermato che è sicuro rimuoverlo, elimina il sottovolume incompleto prima di ritentare lo stesso trasferimento.

Il padre di receive è stato modificato dopo il suo arrivo

Non usare lo snapshot modificato come base per un nuovo flusso incrementale. Se non esiste un padre di receive corrispondente e invariato, avvia una nuova catena di backup completa.

I file all’interno di una directory annidata mancano nello snapshot

Verifica se quella directory è a sua volta un sottovolume Btrfs. I sottovolumi annidati non vengono inclusi ricorsivamente nello snapshot del padre e richiedono una propria catena send/receive.

La connessione WAN o SSH si interrompe durante un trasferimento

Considera il receive non riuscito a meno che non sia stato completato correttamente e il sottovolume risultante non sia stato verificato. L’interfaccia documentata dei comandi Btrfs send/receive non offre un’opzione per riprendere un flusso. Per collegamenti a lunga distanza inaffidabili, valuta la possibilità di scrivere il flusso send in un file di staging, trasferire tale file con un trasporto ripristinabile e quindi passare il file attendibile completato a btrfs receive.

Proteggi il lato di ricezione dai flussi non attendibili

btrfs receive applica le operazioni sul filesystem contenute nel flusso in ingresso. La documentazione ufficiale di receive sconsiglia di accettare flussi send da fonti non attendibili e raccomanda di proteggere il percorso di ricezione dalle scritture concorrenti mentre viene applicato un flusso.

Usa la verifica dell’host SSH, l’autenticazione basata su chiavi, un account di backup dedicato e i privilegi pratici più limitati possibile. Durante l’esecuzione del backup, mantieni la directory di ricezione fuori dai normali percorsi scrivibili dagli utenti.

Usa questa checklist per ogni esecuzione incrementale

Conferma che entrambe le estremità usino Btrfs.
Crea il nuovo snapshot della sorgente con -r.
Mantieni invariato il precedente padre riuscito su entrambi i sistemi.
Invia con btrfs send -p OLD NEW.
Ricevi tramite una connessione SSH autenticata e crittografata.
Verifica il successo e confronta l’UUID della sorgente con l’UUID Received del ricevitore.
Mantieni lo snapshot di backup ricevuto in sola lettura.
Crea uno snapshot scrivibile separato quando devi ripristinare o testare i dati.
Ruota gli snapshot meno recenti solo dopo aver verificato il nuovo padre.
Esegui il backup dei sottovolumi annidati con catene separate.

Dopo che un seed completo e un’esecuzione incrementale sono riusciti manualmente, automatizza la stessa sequenza con registrazione e controlli espliciti dello stato di uscita. L’aspetto importante non è lo scheduler, ma mantenere uno snapshot padre invariato e verificato su entrambe le estremità di ogni passaggio incrementale.