linux tar listado-incremental não confiável

Question

Estou procurando uma maneira de solucionar problemas de backups incrementais com o tar no linux.

Eu tenho conjuntos de dados enormes (cerca de 3 TB) que precisam de backup em fita. Para isso eu uso o comando linux tar e mt / mtx no dispositivo LTO4.

Como o backup é muito, muito, muito, muito lento (suponho que terei que colocar isso em outra pergunta), não há escolha para mim, mas fazer backup com incrementais para evitar que ele seja executado durante o tempo de produção.

basicamente, é assim:

1. Um tar completo é feito: (com nível 0)

   tar --new-volume-script=changetape.sh \
     --exclude=.zfs \
     --listed-incremental=file.index \
     --label=full_DS01 \
     -cvf /dev/nst0 \
     /mnt/storage/sharename >>filelisting.log 2>>errlisting.errlog
   

2. Alcatrão incremental por dia:

   mtx -f /dev/sg1 load X #(load correct tape)
   mt -f /dev/nst0 eod #(forward to end of data to write a new incremental tar)
   tar --exclude=.zfs \
     --listed-incremental=file.index \
     --label=incremental_DS01 \
     -czvf /dev/nst0 \
     /mnt/storage/sharename >>filelisting.log 2>>errlisting.errlog
   

3. Repetir tars incrementais. usando o mesmo processo de 2, eu sempre uso o incremental listado no nível 0, que é adaptado a cada vez. Isso deve significar que sempre faço backup dos arquivos que foram alterados desde a atualização incremental anterior. (como oposto ao diferencial, onde você sempre compara com a atualização completa)

Problema:

Após algumas iterações, os incrementais começam a falhar, o que significa: o backup é executado, mas parece que todos os arquivos foram alterados e, na verdade, ele faz um backup completo.

Isso aconteceu em diferentes conjuntos de dados.

Como posso solucionar isso? E como isso é possível? Tudo parece correr bem e, em seguida, acha que todos os arquivos foram alterados?

para maior clareza:

1. o conjunto de dados é um ponto de montagem somente leitura
2. a estrutura da pasta é a mesma que no backup completo
3. o nome da pasta superior não foi alterado

Como posso resolver este problema?

    

Answer 1

Os recursos incrementais no gtar têm um problema conceitual e não podem funcionar corretamente em todos os casos. Quando tentei verificar os recursos incrementais na estrela em 2004, o gtar falhou cedo e não pôde ser testado.

Você tentou fazer backups incrementais de estrela?

O Freebsd usa o asterisco para backups do zfs e isso funciona bem, já que o freebsd consertava alguns kernelbugs antigos.

gtar tem vários problemas com backups incrementais:

• Importantes metadados maiores não estão dentro dos arquivos de backup, mas sim em um arquivo separado que é criado como resultado do uso da opção gtar específica do fornecedor -g . Em caso de falha total do sistema, é muito provável que este arquivo seja perdido (pelo menos na versão mais recente). A existência deste arquivo separado dos backups, no entanto, não é o problema real. O problema real é que esse arquivo não pode rastrear renomeações.

• Os arquivos de backup do gtar não contêm informações sobre arquivos renomeados. Há apenas um rastreio que permite assumir que um nome de arquivo que não é mencionado no novo arquivo, mas presente no arquivo atual, deve ter desaparecido e, portanto, removido.

• O gtar precisa arquivar uma árvore de diretórios completa com todo o conteúdo se um diretório no nível superior for renomeado. Isso torna os incrementos gtar enormes e isso pode facilmente transbordar o sistema de arquivos de destino durante uma operação de restauração.

• O gtar tem problemas com arquivos que não são de diretório e que alteram o tipo de arquivo entre dois incrementais.

• O gtar não é capaz de manipular um nome de diretório seguido pela criação de um novo diretório do nome anterior.

• Eu, portanto, não pude executar o teste inicial criado manualmente com o gtar que criei em setembro de 2004 para estrela.

Star, por outro lado, usa um algoritmo básico que está correto desde 35 anos, como foi desenvolvido para o ufsdump / ufsrestore em 1981. Os backups incrementais da Star funcionam da seguinte maneira:

• Há arquivos de dumpdates que registram não mais que data e hora, nível e sistema de arquivos para cada dump completo ou incremental.

• Cada arquivo tar contém todos os metadados necessários para rastrear todas as alterações em um sistema de arquivos entre dois backups. Além de todos os arquivos alterados, a estrela arquiva uma lista de nomes de arquivos para todos os diretórios alterados juntamente com os números de inodes relacionados. Isso permite rastrear todas as remoções de arquivos e todas as renominações de arquivos a qualquer momento para qualquer backup incremental.

• Quando a estrela restaura um sistema de arquivos a partir de backups, ele cria uma base de dados com entradas para todos os objetos extraídos que contém o nome do arquivo, o número original do inode do sistema de arquivos backuped e o novo número inode usado no sistema de arquivos extraído . Isso permite que a estrela rastreie todas as alterações entre dois incrementais.

• Quando você renomeia um diretório no nível superior de um sistema de arquivos, star precisa apenas fazer o backup do diretório raiz e do diretório renomeado com seus metadados, mas não de um único arquivo do conteúdo desse diretório.

• O Star foi usado para executar backups cumulativos incrementais diários e restaurações nos sistemas de arquivos do Berlios (geralmente de 2 a 10 GB de dados alterados por dia) durante 10 anos e nunca falhou.

Antes de começar a usar o gtar para seus backups, você pode querer executar testes de restauração semelhantes primeiro.

BTW: aqui está um script que verifica como o GNU tar falha com as restaurações incrementais: É possível usar o tar para backups completos do sistema?