Btrfs è adatto come file system di backup?

In questo momento ho una struttura di filesystem di backup piuttosto tradizionale su ext4. Ogni volta che viene eseguito un backup, viene creata una nuova cartella backup-DATEin cui i file vengono sincronizzati (con collegamenti fissi creati utilizzando l' --link-destopzione di rsync ).

Da quando ho letto di BitRot, vorrei avere un checksum per tutti i file, in modo trasparente. Apparentemente ext4 non può farlo, ma btrfs offre supporto per i checksum dei dati (e persino una modalità RAID1 integrata). Per cominciare, vorrei usare btrfscome filesystem "stupido" che supporta i checksum dei dati senza usare le sue funzionalità avanzate come RAID, snapshot sottovolume, invio / ricezione, ecc.

Tuttavia, la loro wiki non ispira davvero fiducia nel filesystem ai fini del backup:

"Mentre molte persone lo usano in modo affidabile, ci sono ancora problemi da trovare. Dovresti conservare e testare i backup dei tuoi dati ed essere pronto a usarli." - Per iniziare

"Btrfs è stabile? Risposta lunga: [..] Qualunque cosa tu faccia, ti consigliamo di mantenere backup validi, testati, off-system (e off-site)." - FAQ .

Il mio caso d'uso è di avere un backup offline. Per questo motivo il disco vedrà pochissimo utilizzo (come in ore) e verrà spesso inserito / disconnesso (eSATA o USB 3.0). Avere un filesystem affidabile è un must. Non deve essere peggio di ext4 wrt. interruzioni di corrente, arresti impuri, ecc.

Si consiglia effettivamente di utilizzare btrfs come filesystem a scopo di backup? Ci sono altre proprietà di btrfs che potrebbero renderlo meno (o più) adatto?

Fornirò solo una breve risposta perché penso che questo sia stato ripensato.

Se leggi il wiki del kernel principale sui comandi (b) subtr) , scoprirai che ci sono due comandi per:

1. fare un "backup" :btrfs-send
2. e ripristina :btrfs-restore

Per ogni evenienza, ciò significa che non è (progettato per essere) un backup, ma un file system di istantanea, con l'idea di tornare indietro se necessario, non come backup ma come "flessibile".

Pertanto - no, non usarlo come backup - usalo come un filesystem con versione in cui puoi testare le cose e tornare indietro. Non fare affidamento su di esso.

Di recente ho avuto problemi con un file system btrfs su un kernel 4.10.0 aggiornato. Il file system è stato distrutto in una VM virtualbox perché TRIM non sembra essere implementato correttamente da qualche parte e AFAIK aveva qualcosa a che fare con i numeri di indice dei sotto-volumi. Dopo essere passato a VMware, il file system era ancora corrotto e sorprendentemente btrfs checknon è stato in grado di trovare e correggere l'errore. Alla fine sono tornato a ext4.

Il bello: non ho perso i dati. btrfs sembra essere sempre coerente almeno per la lettura, ma mi ha mostrato che è ancora molto lontano dalla prontezza di produzione.

Ad ogni modo, su un server lo sto ancora usando come volume di backup perché lì ho bisogno della funzione di cow-copying per la deduplicazione (esattamente il tuo caso d'uso). I dati sono troppo grandi per un file system tradizionale.

Aggiornare

Ho ancora il filesystem sul mio server (vedi sopra), ma si è rotto subito dopo averlo pubblicato qui. Ora, ho un grande volume di backup di sola lettura di 700G che si espanderebbe a ~ 7 TB su ext4 se provassi a copiare tutto usando tar|tar. Per mancanza di tempo, non ho ancora verificato se le versioni più recenti del kernel sono in grado di gestirlo. Il vero problema è una "interruzione della transazione" che si verifica ~ 2 secondi dopo il montaggio scrivibile e che rimonta il volume in sola lettura. La causa originale è probabilmente una versione non funzionante btrfs-convert, che ho usato anni fa quando ho creato questo volume, e ancora un insieme limitato di funzionalità della corrente btrfs checkche almeno dovrebbe essere in grado di trovare tutti i danni su un volume che riproducono in modo riproducibile un'interruzione della transazione o qualsiasi altro problema, invece di dire semplicemente che il mio filesystem è integro.