Porque é que as cópias de segurança deduplicadas parecem menores do que o espaço ocupado após o restauro?

As cópias de segurança deduplicadas parecem mais pequenas porque os blocos repetidos são armazenados uma única vez, enquanto um restauro reconstrói cada ficheiro lógico e cada cópia independente.

Dez imagens de máquinas virtuais podem partilhar gigabytes de blocos idênticos do sistema operativo num repositório de cópias de segurança. Restaurá-las num sistema de ficheiros comum recria dez espaços de endereçamento, a menos que o destino também suporte partilha compatível, esparsidade ou compressão. Por isso, o tamanho do repositório e a capacidade de restauro descrevem representações diferentes, com regras de alocação e sobrecarga distintas no sistema de ficheiros de destino selecionado.

A deduplicação armazena a identidade uma vez e referencia-a várias vezes

O software de cópias de segurança divide os dados em blocos, calcula as respetivas impressões digitais e armazena apenas os blocos que ainda não estão presentes. Os manifestos preservam quais os blocos que pertencem a cada ficheiro e ponto de restauro. O repositório pode representar várias cópias lógicas com uma única carga física, além das respetivas referências.

Uma visão geral da deduplicação de cópias de segurança explica como as cópias redundantes são eliminadas do armazenamento de cópias de segurança. A poupança depende do conteúdo repetido, não simplesmente do número de ficheiros.

O restauro inverte esse mapeamento. Cada ficheiro recebe os seus bytes pela ordem correta no destino solicitado. Se o destino não suportar a partilha de blocos, os blocos repetidos voltam a consumir extensões separadas. A redução de dados era uma propriedade do repositório, não uma garantia de que todos os destinos de restauro permanecerão igualmente compactos.

A compressão, a esparsidade e os metadados aumentam a diferença

A compressão reduz os bytes armazenados de acordo com a entropia do conteúdo. Os ficheiros esparsos omitem longas regiões de zeros, mas uma opção de restauro pode materializar esses espaços vazios. As unidades de alocação, as somas de verificação, os atributos estendidos e os metadados do sistema de ficheiros acrescentam sobrecarga no destino que os resumos do repositório podem excluir.

Uma explicação sobre armazenamento distingue os ficheiros esparsos do tamanho alocado: um ficheiro pode indicar um comprimento lógico grande e, ao mesmo tempo, consumir menos blocos físicos. As ferramentas de restauro têm de preservar explicitamente os espaços vazios para manter essa poupança.

Também pode acontecer o contrário. Um destino comprimido ou um clone com cópia na escrita pode manter os dados restaurados abaixo do respetivo tamanho lógico. Não existe um multiplicador universal que converta bytes do repositório em bytes restaurados, porque a representação, o conjunto de retenção e o sistema de ficheiros de destino são todos relevantes.

Quando a deduplicação não é a causa principal

A explicação falha quando um único ficheiro não duplicado aumenta inesperadamente. A encriptação, os conteúdos multimédia pré-comprimidos, os formatos de exportação de bases de dados ou uma alteração no aprovisionamento fino podem ser os fatores dominantes. Um catálogo de cópias de segurança também pode apresentar apenas os dados únicos de um âmbito, enquanto o restauro inclui vários instantâneos selecionados.

Uma discussão técnica sobre o rácio de deduplicação salienta que os tamanhos lógicos e físicos têm de ser distinguidos ao comunicar rácios de deduplicação. Os rácios sem âmbito podem induzir em erro no planeamento da capacidade.

O mecanismo também deixa de se aplicar se os hashes ou as contagens dos ficheiros restaurados diferirem da cópia de segurança selecionada. Nesse caso, o problema está na seleção ou na integridade, não numa expansão esperada. Um número menor de bytes na cópia de segurança não justifica subdimensionar o espaço temporário antes da verificação.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Meça um restauro em vez de confiar no rácio

Escolha um conjunto representativo para restauro e registe os bytes lógicos de origem, os bytes únicos do repositório, os bytes comprimidos, as extensões esparsas, a contagem de ficheiros e a unidade de alocação do destino. Restaure para um destino isolado utilizando opções que preservem a esparsidade e opções predefinidas e, em seguida, verifique os hashes e o espaço alocado.

Utilize um plano de armazenamento de armazenamento partilhado de modelos para que o destino de teste não sobrecarregue os serviços ativos. Mantenha fixas as definições de retenção do repositório e de compressão do destino ao comparar as execuções.

Dimensione a recuperação com base no maior valor entre o resultado alocado medido e o tamanho lógico do conjunto de dados, acrescido de uma margem operacional, e não com base no número de repositório deduplicado. Se a preservação da esparsidade alterar o resultado, documente essa dependência. Se a identidade ou a contagem dos ficheiros mudar, pare e resolva a correção do restauro antes de ajustar a capacidade.