Come si può fare una copia completa del contenuto di un filesystem btrfs? Per copia completa intendo non solo i dati attuali , ma anche diversi sottovolumi con le loro istantanee , preservando idealmente le loro strutture CoW (cioè: non duplicare blocchi con lo stesso contenuto.
Sembra che una copia a livello di blocco (come con dd) non sia una buona idea, poiché duplica l'UUID e apparentemente non c'è modo di cambiarlo facilmente .
Risposte:
Assicurarsi che la partizione di origine sia smontata e non verrà montata automaticamente.
Usa dd(lento, muto) opartclone.btrfs -b -s /dev/src -o /dev/target
Utilizzare btrfstune -uper modificare l'UUID dopo la copia e prima del montaggio.
Avviso perdita di dati : Do NON tentare di (auto) montare sia originale o copia fino a quando l'UUID è cambiato
btrfs-cloneNon ho provato personalmente btrfs-clone, ma pretende di clonare un file system BTRFS esistente su uno nuovo, clonando ogni sottovolume in ordine.
Ad oggi non ho trovato alcuna soluzione pronta (06/05/2016), ma ho risolto il problema per i miei scopi, inclusa la gestione di Copia su scrittura. La procedura per "clone" /sourcedi /targetsono:
Ottenere un elenco di sottovolumi ordine di ogen: btrfs subvolume list -qu --sort ogen /source. L'ordinamento è probabilmente sufficiente per garantire che le istantanee o i volumi secondari che dipendono da quelli precedenti vengano gestiti per primi. Questo è importante per gestire Copy-on-Write, perché è necessario prima trasferire i volumi di base.
Rendi tutti i sottovolumi di sola lettura usando btrfs property set -ts /source/some-volume ro true.
Ora, per ogni sottovolume dall'elenco sopra, iniziando dall'alto, procedi come segue:
Se il volume non ha un UUID padre (visualizzato come -) o l'UUID padre non esiste più nell'elenco, eseguire:btrfs send /source/some/volume | btrfs receive /target/some/
Se il volume ha un UUID padre che esiste ancora, avremmo dovuto trasferirlo già a causa di --sort ogene possiamo usarlo come base per evitare la duplicazione dei dati. Quindi, trova il percorso dell'UUID padre nell'elenco ed esegui: btrfs send -p /source/parent/volume/ -c /source/parent/volume/ /source/some/volume/ | btrfs receive /target/some/(probabilmente btrfs indovinerebbe -pautomaticamente l' argomento, ma preferisco essere esplicito).
Dopo l'esecuzione di uno dei comandi sopra rendono la porta e sorgente lettura-scrittura nuovamente: btrfs property set -ts /source/some/volume ro false; btrfs property set -ts /target/some/volume ro false. Questo passaggio può essere ignorato se l'origine è stata precedentemente di sola lettura.
Questo dovrebbe gestire molti casi. Avvertenze:
Potrebbero esserci alcune complicazioni rispetto all'ordinamento quando si annidano sottovolumi / istantanee.
L'intero processo è ovviamente più divertente se scritto.
btrfs sendaccetta più -cargomenti clone source ( ). Può essere vantaggioso specificare non solo il percorso del volume del genitore, ma anche quelli di tutti gli antenati o semplicemente i volumi inviati in precedenza. Non ha fatto alcuna differenza qui, ma potrebbe - solo un'ipotesi - aiutare ad evitare la duplicazione dei dati in alcuni casi.
Non sono sicuro se qualsiasi meta informazione su istantanee o sottovolumi venga persa lungo la strada, ma quasi tutto il resto interessante per la maggior parte dei casi d'uso dovrebbe essere preservato.
L'intero processo mi ha aiutato a trasferire un filesystem da 800 GB con 3,8 GB utilizzati (secondo df) a un'immagine da 10 GB con 3,8 GB utilizzati. Il trasferimento senza -pe -cavrebbe utilizzato circa 190 GB, quindi la duplicazione dei dati è stata effettivamente evitata.
ogensignifica?
ogenè la "generazione di origine" del sottovolume. Devo ammettere che non capisco appieno le differenze o se l'uso della generazione (non di origine) sarebbe corretto, ma suppongo che alcuni test abbiano indicato che funzionava meglio (evitare la duplicazione). La generazione sembra essere aggiornata quando si creano snapshot basati su un volume secondario, ogen no. Sarei interessato a conoscere alcuni risultati. Probabilmente è meglio controllare su IRC o sulla mailing list di Btrfs.
Ho creato uno strumento Python che può fare questo. L'ho fatto perché ho provato l'approccio di @Thomas Luzat sia nella mia implementazione di @Johannes Ernst, sia nello spazio utilizzato raddoppiato da 20 GB a 40 GB nella procedura di clonazione. Pensavo fosse necessario qualcosa di più efficiente.
Considera questa cronologia del file system comune:
current ---------------------------------\
| | | |
snap4 snap3 snap2 snap1
Con l'algoritmo di Thomas, "corrente" verrebbe prima clonata, e tutte le istantanee (essendo istantanee di precedenti stati di "corrente") userebbero "corrente" come sorgente / genitore clone. Ovviamente, sarebbe meglio basare snap3 su snap4, snap2 su snap3, ecc.
E questa è solo la punta dell'iceberg; trovare le fonti "migliori" del clone (in termini di risparmio di spazio) in un file system btrfs con una storia complessa è un problema non banale. Ho escogitato altre 3 strategie per risolvere questo problema, che sembra utilizzare lo spazio in modo molto più efficiente. Uno ha effettivamente portato a dimensioni dei cloni leggermente inferiori a quelle della fonte.
Puoi leggere i dettagli sulla pagina di github se sei interessato.
C'è una domanda simile su unix.stackexchange.com che punta a partclone.btrfs, ma non ne conosco i dettagli.
C'è anche una discussione sulla mailing list del kernel , non molto promettente ...
Con btrfs-send, che ho visto l'ultima volta, c'erano ancora patch sperimentali che fluttuavano sulla mailing list di btrfs.