Porque é que um backup incremental é quase tão grande como um backup completo?

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Why Is an Incremental Backup Almost as Large as a Full Backup? - Zima Store Online

Um backup incremental pode tornar-se quase tão grande quanto um backup completo quando a origem reescreve genuinamente muitos blocos, o motor de backup perde a sua linha de base de alterações anterior, o âmbito protegido muda, ou o número que está a ler é crescimento do repositório em vez da carga incremental atual. Diagnostique essas possibilidades separadamente antes de eliminar pontos de restauro, reiniciar o trabalho ou iniciar um novo backup completo.

Primeiro Identifique Qual Número Parece Demasiado Grande

“O incremental tem tamanho completo” pode descrever quatro medições diferentes. Elas não são intercambiáveis e cada uma aponta para uma causa diferente.

Medição	O que Significa	O que um Valor Elevado Sugere
Bytes da origem verificados	Dados lidos para detetar alterações	O motor pode precisar inspecionar ficheiros inteiros mesmo que só carregue pedaços alterados
Bytes transferidos	Novos dados enviados para o destino	Muitos blocos alterados, a linha de base foi perdida ou a desduplicação não correspondeu
Tamanho do ficheiro incremental	Novos dados de ponto de restauro escritos por esta execução	O trabalho capturou um delta genuinamente grande ou comportou-se como uma nova linha de base
Crescimento total do repositório	Armazenamento líquido adicionado após fusões, retenção, metadados e operações sintéticas	O design da cadeia de backup ou o cronograma de limpeza podem ser a causa real

Registe os quatro números para uma execução. Um trabalho que verifica 8 TB mas transfere 12 GB está a comportar-se de forma muito diferente de um que transfere e escreve 7 TB.

Confirme se a Carga de Trabalho Realmente Mudou Tanto

O software de backup a nível de volume protege blocos de armazenamento alterados, não o tamanho visível ao utilizador dos documentos editados. Uma pequena edição pode alterar um bloco maior, e serviços ativos modificam continuamente registos, índices, bases de dados, caches e ficheiros do sistema operativo. Uma discussão recente de administradores explica por que um byte alterado pode fazer com que o bloco de backup que o contém faça parte do próximo incremento.

Verifique se a grande execução seguiu algum destes eventos:

Manutenção de base de dados, compactação, reindexação ou crescimento do log de transações
Atualizações de máquinas virtuais, atividade de swap, scans antivírus ou desfragmentação de convidados
Transcodificação de mídia, reindexação da biblioteca de fotos, regeneração de miniaturas ou reescritas de metadados
Arquivos grandes, contentores encriptados, caixas de correio ou imagens de disco a serem reescritos no local
Equilíbrio do sistema de ficheiros, expansão do pool, relocação de blocos ou consolidação de snapshots

Compare a janela de backup com os registos da aplicação e os gráficos de escrita de armazenamento. Se as escritas na origem aumentaram ao mesmo tempo, o backup pode estar a reportar um delta real em vez de uma falha no backup.

Verifique se o Rastreamento de Alterações Perdeu a Sua Linha de Base

Sistemas de rastreio por blocos comparam o estado atual com um ID de alteração anterior conhecido. Um revert de snapshot, reinício do rastreio, mapa de alterações inválido, migração de anfitrião, sessão anterior falhada ou recriação do trabalho de backup podem quebrar essa relação. A execução seguinte pode então ler ou proteger toda a origem para estabelecer uma linha base segura. Um guia prático de recuperação CBT nota que reiniciar o rastreio de alterações pode exigir um novo full ativo antes de os incrementais normais retomarem.

Procure termos nos registos como CBT reiniciado, ID de alteração inválido, jornal envolvido, linha base em falta, nova cadeia, ou varredura completa necessária. Não reinicie o rastreio repetidamente sem preservar os registos; reinícios repetidos podem ocultar o gatilho original e produzir execuções repetidas de tamanho completo.

Verifique se o âmbito do backup e a identidade da origem não mudaram

Um trabalho pode ainda ser rotulado como incremental enquanto protege uma origem diferente da anterior. Uma nova montagem sob um caminho incluído, um redimensionamento do sistema de ficheiros, um identificador de dispositivo alterado, um nome de anfitrião diferente, um novo caminho de partilha ou uma regra de inclusão expandida podem fazer o motor construir novas estruturas internas. A resolução de problemas comunitária mostra que volumes adicionais e pontos de montagem podem ser incluídos num trabalho que parece inalterado.

Exporte as definições do trabalho anterior e atual e compare:

Raízes protegidas, montagens, partilhas, conjuntos de dados e discos virtuais
Identificadores de anfitrião, volume e sistema de ficheiros
Padrões de inclusão e exclusão
Fornecedor de snapshot e modo de consistência
Configurações de encriptação, compressão e deduplicação

Se a origem aumentou intencionalmente, pode esperar-se um incremento de tamanho completo. Se cada execução posterior continuar grande, continue o diagnóstico.

Determine se a granularidade do backup se adequa aos ficheiros

Motores de fragmentação a nível de ficheiro, bloco e conteúdo reagem de forma diferente a edições, renomeações e reescritas. Um sistema de deduplicação por blocos pode registar apenas metadados quando uma pasta é movida; um motor mais simples a nível de ficheiro pode tratar o caminho movido como um ficheiro eliminado mais um ficheiro novo. Num exemplo baseado em blocos, renomear um diretório altera os metadados do caminho sem reenvio de todos os blocos de dados inalterados.

Ficheiros mutáveis grandes precisam de atenção especial. Uma base de dados, imagem de VM, cofre encriptado ou arquivo monolítico pode ser lido na totalidade para descobrir pequenas alterações internas, e a quantidade armazenada depende dos limites dos fragmentos e da deduplicação. Uma discussão sobre bases de dados grandes descreve como um ficheiro de base de dados multi-gigabyte pode ser lido na totalidade mesmo quando apenas os fragmentos alterados são transferidos.

Se a aplicação fornecer uma exportação consistente, backup de registo de transações ou método de backup consciente da aplicação, compare esse fluxo de trabalho com o backup do ficheiro monolítico ativo.

Separe um Incremental Grande da Atividade de Completo Sintético e Retenção

Um completo sintético é montado dentro do repositório a partir de um completo anterior mais incrementais posteriores. Pode criar um objeto de recuperação em tamanho completo sem ler toda a fonte novamente. Uma visão geral dos tipos de backup explica que os backups completos sintéticos são construídos a partir da cadeia existente de completo e incremental.

O crescimento do repositório também pode manter-se elevado quando pontos de restauro antigos permanecem bloqueados, a poda não foi executada, instantâneos eliminados ainda referenciam fragmentos, ou uma mesclagem temporariamente necessita de espaço de trabalho. Verifique a linha temporal do trabalho em vez de julgar uma listagem de diretório:

Padrão Observado	Interpretação Provável	Próxima Verificação
Transferência de rede é pequena, escrita no repositório é grande	Completo sintético, mesclagem ou reempacotamento	Registo de tarefas do repositório
Ficheiro incremental é pequeno, uso total continua a aumentar	Retenção, imutabilidade, instantâneos ou poda atrasada	Ponto retido mais antigo e calendário de recuperação
Bytes transferidos e escritos aproximam-se do tamanho completo	Rotatividade real, linha base perdida ou escopo alterado	Atividade da fonte e registos de rastreamento
Apenas a primeira execução após uma alteração é grande	Nova linha base ou transição do layout da fonte	Próximas duas execuções incrementais

Execute um Teste de Uma Variável Antes de Reconstruir a Cadeia de Backup

Guarde a configuração atual do trabalho, registos detalhados, lista de pontos de restauro e capacidade do repositório.
Escolha uma janela de teste tranquila e pause aplicações conhecidas por escreverem muito, se for seguro fazê-lo.
Crie um pequeno ficheiro de teste, modifique-o uma vez e execute o mesmo trabalho incremental sem alterar quaisquer definições.
Registe os bytes digitalizados, transferidos, escritos, deduplicados e retidos.
Execute um segundo incremental sem alterações na fonte.

Se ambas as execuções controladas permanecerem em tamanho completo, concentre-se no rastreamento, identidade da fonte ou configuração da cadeia de trabalho. Se ficarem pequenas, restaure as cargas de trabalho normais uma de cada vez até que a taxa de mudança retorne. Isso separa o comportamento do motor de backup da rotatividade da aplicação.

Associe a Correção à Causa

Causa Confirmada	Ação Corretiva	Resultado Esperado
Taxa real de escrita elevada	Reduza o âmbito dos ficheiros temporários, use exportações conscientes da aplicação ou agende após manutenção	O tamanho do incremento segue alterações significativas dos dados
Linha base de rastreamento perdida	Repare o rastreamento uma vez, crie a linha base necessária e depois verifique os incrementos posteriores	Uma execução grande seguida de deltas menores
Âmbito expandido	Confirme que os novos dados são pretendidos ou divida-os num trabalho separado	Crescimento previsível ligado à fonte adicionada
Ficheiros grandes e mutáveis	Use dumps consistentes com a aplicação ou um método de backup consciente dos fragmentos	Menos reprocessamento desnecessário e restauros mais seguros
Retenção ou operações sintéticas	Ajuste o planeamento da capacidade, o tempo de poda ou a política de pontos de restauro	O crescimento do repositório corresponde ao histórico pretendido

Ao dimensionar o destino, lembre-se que o histórico de versões e a retenção podem tornar um repositório maior do que a fonte ativa. A mesma distinção é abordada no guia ZimaSpace para planeamento da capacidade do NAS para versões e histórico de backups.

Pare e Escale Quando Cada Execução Cria uma Nova Linha Base

Escale antes de eliminar a cadeia quando os logs mostram repetidas invalidações da linha base, os identificadores da fonte mudam inesperadamente, pontos de restauro desaparecem, os metadados do repositório reportam corrupção ou um teste sem alterações ainda escreve quase toda a fonte. Mantenha os pontos de restauro atuais até que pelo menos um restauro representativo tenha sido testado. Recriar o trabalho pode ocultar a evidência e remover o único histórico recuperável.

Perguntas Frequentes

Mover ou renomear uma pasta grande pode causar um incremento do tamanho de um full?

Depende do motor de backup. Ferramentas que deduplicam conteúdo ou blocos podem reutilizar os dados existentes e armazenar principalmente metadados do caminho, enquanto ferramentas ao nível de ficheiro podem tratar os ficheiros movidos como novos objetos. Teste o produto exato com uma pasta representativa antes de reorganizar um conjunto de dados grande.

Significa um full sintético que o NAS enviou novamente toda a fonte?

Nem sempre. Um full sintético é normalmente montado a partir de dados já existentes no repositório. Compare os contadores de leitura da fonte e de transferência de rede com os contadores de escrita no repositório para ver onde ocorreu o trabalho.

Porque é que uma pequena edição na base de dados pode criar um incremento grande?

A aplicação pode reescrever muitos blocos de armazenamento, compactar a base de dados, rodar logs ou alterar os limites dos fragmentos mesmo quando a alteração visível do registo é pequena. Utilize um backup ou exportação consistente com a aplicação e compare o seu delta com o ficheiro da base de dados em uso.