Fazendo backup de domínios Xen

Question

Atualmente, estou desenvolvendo um sistema de backup do Xen, mas encontrei o seguinte problema:

Eu tenho dois métodos de backup:

• fazendo dd da captura instantânea do LVM e tar tocando. e rsync remotamente
• monte o instantâneo do LVM e rale tudo em um local remoto

Agora, a segunda opção me permite o uso de rdiff-backup , para que eu possa salvar backups incrementais e economizar muito espaço, enquanto a primeira opção é realmente muito pesada.

Agora, tenho duas perguntas:

• Existe alguma maneira de não ter "espaço em branco" ao usar dd ? Digamos que eu tenha um volume LVM de 50 GB e apenas 3 GB sejam usados. Quando usar dd , ele criará uma imagem de 50 GB (e, portanto, 47 GB serão desperdiçados). tar pode consertar isso, mas leva muito tempo extra (o que eu não tenho basicamente)
• Esses arquivos img criados por dd podem ser salvos de forma incremental de alguma forma?

Answer 1

Compressão para espaço em branco

Vamos voltar ao básico do seu instantâneo. Em primeiro lugar, vou pedir-lhe para ver porque está a acumular um ficheiro. Pare e pense sobre o que o alcatrão faz um pouco e por que você está fazendo isso.

$ dd if=/dev/zero of=zero bs=$((1024*1024)) count=2048
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 46.748718 secs (45936739 bytes/sec)
$ time gzip zero

real    1m0.333s
user    0m37.838s
sys     0m1.778s
$ ls -l zero.gz
-rw-r--r--  1 user  group  2084110 Mar 11 16:18 zero.gz

Dado que, podemos ver que a compressão nos dá uma vantagem de 1000: 1 em um espaço vazio. A compactação funciona independentemente do suporte do sistema para arquivos esparsos. Existem outros algoritmos que irão aumentar ainda mais, mas para o desempenho global bruto, gzip ganha.

Utilitários Unix e arquivos esparsos

Dado um sistema com suporte para arquivos esparsos, dd às vezes tem uma opção para salvar o espaço. Curiosamente, meu mac inclui uma versão de dd que tem um conv=sparse flag, mas o sistema de arquivos HFS + não suporta isso. Oponentemente, uma nova instalação do Debian que eu usei para testes tem suporte para arquivos esparsos no ext4, mas essa instalação do dd não tem o sinalizador. Vá a figura.

Assim, outro exercício:

Eu copiei / dev / zero para um arquivo igual ao anterior. Foram necessários 2G de espaço no sistema de arquivos, como confirmado por du , df e ls . Então eu usei cp nele e me encontrei com 2 arquivos usando 4GB de espaço. Então, é hora de tentar outro sinalizador:

'cp --sparse=always sparse sparse2'

Usar isso força o cp a pegar um arquivo regular e usar alocação esparsa sempre que ele vir uma longa seqüência de zeros. Agora, tenho dois arquivos que relatam ter 4 GB de acordo com ls , mas apenas 2 GB de acordo com du e df .

Agora que eu tenho um arquivo esparso, o cp vai se comportar? Sim. cp sparse2 sparse faz com que ls mostre 2 GB de espaço consumido para cada arquivo, mas du mostra como ocupando zero blocos no sistema de arquivos. Conclusão: alguns utilitários respeitarão um arquivo já esparso, mas a maioria irá escrever tudo de volta. Mesmo cp não sabe transformar um arquivo escrito de volta em escasso, a menos que você force sua mão a tentar.

Em seguida, criei um arquivo de 1 MB e fiz uma entrada esparsa e, em seguida, tentei editá-lo em vim . Apesar de apenas inserir alguns caracteres, estamos de volta a usar a coisa toda. Uma pesquisa rápida encontrou uma demonstração semelhante: link

Conclusões esparsas

Então meus pensamentos deram tudo isso:

• Instantâneo com LVM
• Execute o zerofree no snapshot
• Use rsync -S para copiar com arquivos esparsos resultantes
• Se você não puder usar o rsync, gzip seu instantâneo se estiver transportando pela rede e, em seguida, executar cp --sparse=always na imagem não expandida para criar uma cópia esparsa.

Backups diferenciais

A desvantagem do problema com um backup diferencial em dispositivos de bloco é que as coisas podem se mover um pouco e gerar grandes diffs incontroláveis. Há alguma discussão sobre o StackOverflow: link que concluiu que o melhor uso foi o xdelta. Se você for fazer isso, tente novamente zerar seu espaço vazio primeiro.

    

Answer 2

Suas duas perguntas ...

dd apenas toma os setores como uma imagem. Não há como dizer para pular pontos em branco; Ele criará uma imagem fiel da unidade que você está duplicando. No entanto, se você redirecionar a saída por meio de um utilitário de compactação como zip ou 7z, o espaço em branco deverá diminuí-lo para quase o mesmo efeito. Ele ainda levará tempo (já que o utilitário dd ainda está duplicando o espaço em branco), mas o fator de tamanho para armazenamento será bastante reduzido; Eu tenho uma imagem de disco com mais de 100 gigabytes da VMWare que é comprimida para cerca de 20 GB devido ao espaço não utilizado.

Quanto à poupança incremental, não é do meu conhecimento. Como você saberia o que mudou e o que não mudou? Não foi realmente destinado a isso. Os salvamentos incrementais provavelmente teriam que ser feitos com um utilitário como rdiff-backup ou rsync e compactá-los, tendo isso feito no nível do arquivo.

    

Answer 3

tar não pode consertar o espaço desperdiçado a menos que esteja cheio de zeros (normalmente não será). A execução de uma ferramenta para zerar o espaço livre, como Jeff sugeriu, faria com que o instantâneo criasse grandes quantidades de dados, gastando muito tempo e usando um monte de snapshots para armazenar o espaço da loja. Existe uma razão pela qual você não deseja montar o instantâneo e rsync ou rdiff-backup disso? Você também pode olhar para dump , que pode fazer backup rapidamente do instantâneo sem montá-lo (se estiver ext [234]) e fazer backups incrementais de vários níveis. Pode ser muito mais rápido que o tar ou rsync para sistemas de arquivos que possuem muitos arquivos pequenos. Também pode fazer compressão multithread.