Como copiar um sistema de arquivos btrfs


17

Como fazer uma cópia completa do conteúdo de um sistema de arquivos btrfs? Por cópia completa, quero dizer não apenas os dados atuais , mas também subvolumes diferentes com seus snapshots , preservando idealmente suas estruturas CoW (ou seja: não duplicando blocos com o mesmo conteúdo.

Parece que uma cópia em nível de bloco (como com dd) não é uma boa ideia, pois duplica o UUID e , aparentemente, não há uma maneira de alterá-lo facilmente .

Respostas:


4

Opção 1 - cópia de dados burros e, em seguida, altere o UUID

Verifique se a partição de origem está desmontada e não será montada automaticamente.

Use dd(lento, burro) oupartclone.btrfs -b -s /dev/src -o /dev/target

Use btrfstune -upara alterar o UUID após a cópia e antes da montagem.

Aviso de perda de dados : Do NOT tentar (auto) montar quer original ou cópia até que o UUID mudou


Opção 2 - btrfs-clone

Eu não tentei pessoalmente btrfs-clone, mas ele pretende clonar um sistema de arquivos BTRFS existente para um novo, clonando cada subvolume em ordem.


1
Para completar, isso foi adicionado como uma opção ao btrfs-progs durante 2015: github.com/kdave/btrfs-progs/commit/…
goncalopp

16

Não encontrei nenhuma solução pronta até hoje (06/05/2016), mas resolvi o problema para meus propósitos, incluindo o manuseio Copy-on-Write. Os passos para "clone" /sourcepara /targetsão:

  1. Obter uma lista de subvolumes ordenados por ogen: btrfs subvolume list -qu --sort ogen /source. A classificação é provavelmente suficiente para garantir que os instantâneos ou subvolumes que dependem dos anteriores sejam manipulados primeiro. Isso é importante para lidar com o Copy-on-Write, porque precisamos transferir os volumes base primeiro.

  2. Tornar todos os subvolumes somente leitura usando btrfs property set -ts /source/some-volume ro true.

  3. Agora, para cada subvolume da lista acima, começando no topo, faça o seguinte:

    1. Se o volume não tiver um UUID pai (exibido como -) ou o UUID pai não existir mais na lista, execute:btrfs send /source/some/volume | btrfs receive /target/some/

    2. Se o volume tiver um UUID pai que ainda exista, já o teremos transferido por causa disso --sort ogene podemos usá-lo como base para evitar a duplicação de dados. Portanto, encontre o caminho do UUID pai na lista e execute: btrfs send -p /source/parent/volume/ -c /source/parent/volume/ /source/some/volume/ | btrfs receive /target/some/(o btrfs provavelmente adivinharia o -pargumento automaticamente, mas eu prefiro ser explícito).

    3. Depois de executar um dos comandos acima fazem o alvo e fonte de leitura e escrita de novo: btrfs property set -ts /source/some/volume ro false; btrfs property set -ts /target/some/volume ro false. Esta etapa pode ser ignorada se a fonte tiver sido anteriormente somente leitura.

Isso deve lidar com muitos casos. Ressalvas:

  1. Pode haver algumas complicações com relação à solicitação ao aninhar subvolumes / instantâneos.

  2. Todo o processo é obviamente mais divertido quando roteirizado.

  3. btrfs sendaceita vários -cargumentos de origem de clone ( ). Pode ser vantajoso não apenas especificar o caminho do volume do pai, mas também o de qualquer ancestral ou simplesmente qualquer volume enviado anteriormente. Não fez nenhuma diferença aqui, mas pode - apenas um palpite - ajudar a evitar a duplicação de dados em alguns casos.

  4. Não tenho certeza se alguma informação meta sobre instantâneos ou subvolumes é perdida ao longo do caminho, mas praticamente tudo o que é interessante para a maioria dos casos de uso deve ser preservado.

Todo o processo me ajudou a transferir um sistema de arquivos de 800 GB com 3,8 GB usado (de acordo com df) para uma imagem de 10 GB com 3,8 GB usados. Transferir sem -pe -cteria usado cerca de 190 GB, portanto a duplicação de dados foi realmente evitada.


Resposta bem escrita, obrigado. Você pode explicar o que ogensignifica?
drumfire

@drumfire ogené a "geração de origem" do subvolume. Devo admitir que não compreendo completamente as diferenças ou se o uso da geração (não de origem) estaria correto, mas assumo que algum teste indicou que isso funcionou melhor (duplicação evitada). A geração parece ser atualizada ao criar snapshots com base em um subvolume, ogen não. Eu estaria interessado em ouvir sobre algumas descobertas. Provavelmente, é melhor verificar o IRC ou a lista de discussão Btrfs.
Thomas Luzat 4/06/16

2
Eu apenas peguei o algoritmo do @ThomasLuzat, adicionei um pouco de penugem (verificação de erros, etc.) e coloquei aqui: github.com/jernst/btrfs-copy-filesystem/blob/master/… . Ele funcionou para o meu problema ao sair de um disco corrompido e não há garantias de que funcione para mais ninguém. Mas eu estou postando isso aqui de qualquer maneira, caso alguém queira começar de outro lugar que não seja o zero para codificar isso. Atualmente depende de um novo método UBOS, mas deve ser fácil de portar.
Johannes Ernst

6

Eu criei uma ferramenta python que pode fazer isso. Fiz isso porque tentei a abordagem do @Thomas Luzat tanto na minha implementação quanto na do @Johannes Ernst, e o espaço usado dobrou de 20 GB para 40 GB no procedimento de clonagem. Eu pensei que algo mais eficiente era necessário.

Considere este histórico comum do sistema de arquivos:

current ---------------------------------\
             |       |        |          |
           snap4   snap3    snap2      snap1

Com o algoritmo de Thomas, "atual" seria clonado primeiro e todos os instantâneos (sendo instantâneos de estados anteriores de "atual") usariam "atual" como origem / pai do clone. Obviamente, seria melhor basear o snap3 no snap4, snap2 no snap3, etc.

E isso é só o topo do iceberg; encontrar as "melhores" fontes de clones (em termos de economia de espaço) em um sistema de arquivos btrfs com um histórico complexo é um problema não trivial. Eu criei outras três estratégias para resolver esse problema, que parecem usar o espaço com muito mais eficiência. Na verdade, resultou no tamanho dos clones um pouco abaixo do da fonte.

Você pode ler os detalhes na página do github, se estiver interessado.



Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.