solução de backup ativada para btrfs

Question

Com o btrfs atingindo a produção no Oracle EL 14º este mês (juntamente com o trabalho fsck e scrubbing do Linux 3.2), eu estava pensando em reprojetar minha solução de backup atual para utilizá-la. Observe que estou pensando em fazer isso para pequenas quantidades de dados, menos de 10 TB, o que é bastante estático (menos de 1% alterado diariamente). Em suma, uma solução de backup SMB / SOHO.

O que o backup deve fazer:

1. faça um instantâneo LVM de ext [234] / XFS / JFS no servidor de produção
2. rsync / transfere dados alterados para btrfs no servidor de backup
3. tire uma foto do sistema de arquivos btrfs
4. elimine instantâneos antigos quando o espaço livre estiver baixo

Prós:

• Todos os arquivos são facilmente disponíveis, não é necessária descompactação ou montagem de loop
• Instantâneos anteriores também estão disponíveis com facilidade ...
• ... para que eu possa compartilhá-los como compartilhamentos Samba somente leitura (com suporte a cópias de sombra)
• Os instantâneos ocupam uma quantidade mínima de espaço graças ao copy-on-write (o instantâneo sem alterações leva literalmente poucos KiB no disco)
• Alta consistência de backup: somas de verificação em arquivos, limpeza de todos os dados e redundância interna

Perguntas:

• Existe alguma solução de backup (em forma de Bacula, BackupPC, etc.) que é, ou pode ser facilmente feita, ciente do sistema de arquivos copy-on-write?
• Ou eu precisarei usar a solução rsync em casa?
• O que as pessoas com caixas ZFS dedicadas ao backup fazem para fazer backup de suas máquinas Linux?

Answer 1

Eu fiz uma pesquisa extensa na semana passada para algo semelhante. Não encontrei soluções para todos os 4 passos. Existem inúmeros blogs de usuários domésticos que experimentam o tipo de backup rsync to btrfs ' dos principais wikis Btrfs cobrem como realizar snapshots Btrfs.

Existem também algumas pessoas que estão tentando maneiras diferentes de rotar instantâneos Btrfs . No entanto, você é a primeira pessoa que eu vi que deseja girar instantâneos com base no espaço em disco. Eu estou jogando com o btrfs-snap que cria um conjunto de snapshots por hora, semanalmente e mensalmente, e é agradável e simples.

O projeto Dirvish parece satisfazer muitas das suas necessidades. Alguns desenvolvedores estão tentando integrar o Dirvish com o Btrfs . No entanto, o projeto Dirvish parece um pouco parado .

Neste momento, você está à frente da curva.

    

Answer 2

De acordo com Avi Miller (sua palestra durante o LinuxConf.AU), um envio / recebimento btrfs está sendo trabalhado. Ele será mais rápido que o rsync, já que ele não precisa percorrer diretórios para encontrar alterações nos arquivos. Ainda não sei se há uma data de lançamento esperada.

Existe, no entanto, um utilitário embutido no btrfs-progs que lista todos os arquivos que foram alterados entre instantâneos / etc. btrfs subvolume encontrar-novo

    

Answer 3

Estou trabalhando em um sistema de backup do sistema operacional semelhante ao BackupPC. Eu pensei sobre isso. O que tem me impedido de realmente implementar isso é que você não pode estabelecer hardlink entre subvolumes. Você também pode criar apenas instantâneos de subvolumes - > Um subvolume por cliente de backup. Portanto, o recurso de desduplicação em nível de arquivo não pode coexistir com essa abordagem. E essa desduplicação em nível de arquivo geralmente economiza muito espaço. Você quer fazer o backup de apenas um servidor?

Se o btrfs tiver desduplicação em nível de bloco, esse problema provavelmente poderá ser evitado, mas isso geralmente é insuportavelmente lento também ...

Então, tal abordagem implicaria, é claro, uma strong integração com um sistema de arquivos (btrfs), portanto, este deve ser um recurso opcional.

Estou perguntando porque estou pensando em adicionar esse recurso de vaca, mas não sei se devo devido aos inconvenientes listados acima.

Editar: O UrBackup suporta backups, conforme descrito na questão agora com kernels Linux > = 3.6 (com suporte ao crossink volumeink). Consulte como configurá-lo.

    

Answer 4

A página wiki btrfs " Casos de Uso " lista algumas ferramentas : SnapBtr , Snapper, btrfs-time-machine, UrBackup.

Existe uma proposta para uma ferramenta interna chamada autosnap :

Using the autosnap feature, you could configure btrfs to take regular or event based snapshots and further manage the snapshots automatically.

Autosnap is not just about taking the snapshot, but also managing the created snapshots, as of now you could configure autosnap to delete the snapshots based on filesystem used space.

No entanto, a partir de outubro de 2013, o wiki afirma que "A funcionalidade de autosnap não está incluída atualmente na versão upstream do btrfs. "

    

Answer 5

Eu tive frustrações semelhantes, então acabei criando alguns scripts que estou chamando de snazzer . Juntos, eles oferecem snapshot, poda, medição e transporte via ssh (mas a partir de hoje também podem enviar / receber para / de sistemas de arquivos locais). As medições são apenas relatórios de sha512sum e assinaturas PGP de caminhos de instantâneo. Ainda não está pronto para lançamento, mas eu adoraria ouvir feedback se alguém tiver tempo de revisá-lo nesse estágio inicial.

Somente para CLI neste momento, mas demorei um pouco para facilitar o uso em sistemas com muitos subvolumes btrfs - normalmente, tenho subvolumes separados para /var/cache , /home etc., que podem precisar ser excluído do snapshot ou ter agendas de poda mais / menos agressivas.

Eu tenho medo que o algoritmo de poda tome decisões apenas sobre a presença do conjunto de capturas instantâneas e suas datas, nada está lá para manter a remoção até que uma restrição de uso de disco seja satisfeita - o que você exclui primeiro? Reduzir o número de horas por hora primeiro ou por dia? Talvez deixe cair o mais antigo, Eg. anuários? Implementações diferentes terão prioridades diferentes; e não posso saber se essa é a única camada de backup (nesse caso, você não deve abandonar os backups mais antigos no caso de obrigações legais / de seguros) ou apenas uma intermediária (nesse caso, você provavelmente terá esses anuários arquivados em algum lugar seguro em outro lugar).

Eu adicionarei suporte ao ZFS e / ou interoperabilidade em algum momento; é escrito principalmente em posix-ish shell e perl devido a um strong desejo por dependências "zero" no momento, esperamos ter uma implementação alternativa de python mais limpa mantida em paralelo em algum momento.