Deduplicacao e compressao em backup: como reduzir custo de armazenamento sem perder retencao

O que realmente pesa na conta do backup

Quando uma empresa reclama que "backup está caro", o custo raramente vem da licença do software. Vem do armazenamento — e, mais especificamente, da multiplicação de dados que a política de retenção provoca. Um servidor de arquivos de 2 TB com retenção de 30 pontos diários não ocupa 2 TB no repositório: sem nenhum tratamento, ocuparia 60 TB. É esse fator multiplicador, e não o volume original, que define a fatura mensal de disco, fita ou nuvem.

Deduplicação e compressão existem justamente para quebrar essa multiplicação. São técnicas distintas, aplicadas em momentos diferentes do fluxo, com efeitos diferentes sobre CPU, rede e tempo de restore. Compressão reduz o tamanho de um bloco de dados aplicando um algoritmo que elimina redundância interna daquele bloco. Deduplicação reduz o volume total identificando blocos idênticos entre arquivos, entre servidores e entre pontos de restauração, e gravando apenas uma cópia física, com ponteiros para as demais ocorrências.

A diferença prática é grande. Compressão típica em dados de servidor entrega entre 1,5:1 e 2:1 — ou seja, corta algo entre 33% e 50% do volume. Deduplicação em um ambiente com muitas VMs de sistema operacional parecido e retenção longa entrega com frequência 8:1, 12:1 ou mais, porque o Windows Server instalado em 40 máquinas virtuais é essencialmente o mesmo conjunto de blocos repetido 40 vezes. Quem tem ambiente homogêneo e retenção longa ganha muito mais com dedup do que com compressão.

Como as duas técnicas funcionam por dentro

A deduplicação trabalha dividindo os dados em blocos e calculando um hash para cada bloco. Se o hash já existe no índice do repositório, o bloco não é gravado de novo — apenas a referência é registrada. O tamanho do bloco é a variável mais importante desse desenho. Blocos pequenos (64 KB ou menos) encontram mais repetições e economizam mais espaço, mas geram um índice de hashes gigantesco, que precisa caber em memória para o processo não ficar lento. Blocos grandes (1 MB ou 4 MB) reduzem o índice e aceleram tudo, ao custo de deixar economia na mesa.

Há ainda a escolha entre blocos de tamanho fixo e blocos de tamanho variável. Blocos fixos são mais rápidos, mas sofrem com o problema do deslocamento: se alguém insere alguns bytes no início de um arquivo grande, todos os blocos seguintes mudam de posição e nenhum casa mais com o índice. Blocos variáveis, delimitados por marcadores calculados sobre o próprio conteúdo, sobrevivem a esse deslocamento e mantêm a taxa de dedup em cargas com muita edição de documentos.

A compressão, por sua vez, roda depois da dedup no pipeline. A ordem importa: comprimir antes de deduplicar destrói a dedup, porque dois blocos idênticos comprimidos com dicionários diferentes geram saídas diferentes, e os hashes deixam de casar. Todo produto sério aplica dedup primeiro e compressão depois, sobre os blocos únicos que sobraram.

Os algoritmos de compressão também apresentam escolhas de trade-off claras:

• LZ4 / compressão "rápida" — taxa modesta (1,3:1 a 1,6:1), consumo de CPU quase irrelevante. Ideal quando a janela de backup é apertada e o gargalo é tempo, não espaço.
• Zstd / compressão "ótima" — taxa boa (1,8:1 a 2,2:1) com custo de CPU moderado. É o ponto de equilíbrio para a maioria dos ambientes corporativos hoje.
• LZMA / compressão "extrema" — taxa alta (2,5:1 ou mais), consumo de CPU pesado e restore mais lento. Faz sentido apenas em cópias de arquivamento de longo prazo, que raramente serão lidas.

Vale registrar o que não comprime: arquivos já comprimidos ou criptografados. JPEG, MP4, PDF moderno, ZIP, bancos com compressão nativa ligada e volumes com BitLocker não entregam ganho algum — em alguns casos o resultado fica marginalmente maior que a entrada. Um repositório dominado por acervo de mídia terá taxa global baixa por natureza, e isso não é defeito de configuração.

O efeito sobre a janela de backup e sobre a rede

Onde a dedup acontece muda completamente o perfil de consumo de recursos. Existem três lugares possíveis, e a escolha entre eles é uma das decisões de arquitetura mais consequentes do projeto.

Dedup na origem significa que o agente instalado no servidor produtivo calcula os hashes e consulta o repositório antes de transmitir. Só os blocos inéditos viajam pela rede. Isso reduz drasticamente o tráfego — é a única abordagem viável para filiais com link estreito ou para backup direto em nuvem — mas consome CPU e memória da máquina de produção, exatamente aquilo que ninguém quer sacrificar em horário comercial.

Dedup em linha no destino transfere tudo pela rede e deduplica no servidor de backup antes de gravar em disco. Não pesa na produção, mas exige um appliance ou servidor de backup robusto, com bastante RAM para o índice, e o link precisa aguentar o volume bruto.

Pós-processamento grava o backup cru primeiro e deduplica depois, em janela separada. É o mais rápido para fechar a janela de backup, e o que mais exige espaço: o repositório precisa de uma área de estágio capaz de armazenar o volume completo antes da redução.

Regra prática: se o gargalo é a janela noturna, escolha pós-processamento e pague em disco. Se o gargalo é o link, escolha dedup na origem e pague em CPU. Se não há gargalo declarado, dedup em linha no destino é o padrão sensato.

Existe ainda um efeito de segunda ordem que costuma passar despercebido: dedup e compressão reduzem o volume gravado, o que reduz o tempo de escrita em disco. Em repositórios com storage lento, uma compressão que custa 10% de CPU pode encurtar a janela de backup em vez de alongá-la, porque o disco deixa de ser o fator limitante. Medir antes de assumir é obrigatório.

O custo escondido: velocidade e confiabilidade do restore

Aqui está o ponto que planilhas de economia costumam ignorar. Dados deduplicados são, por definição, fragmentados. Um arquivo de 10 GB que parecia contíguo agora está espalhado em milhares de blocos únicos, referenciados por ponteiros, possivelmente gravados em momentos diferentes e em posições distantes do disco. Restaurar exige reidratar: seguir cada ponteiro, ler o bloco, descomprimir e remontar.

Em disco rotacional, essa fragmentação transforma leitura sequencial em leitura aleatória e pode derrubar a velocidade de restore em cinco a dez vezes. Em SSD ou NVMe, o impacto é bem menor, o que explica por que appliances de dedup modernos usam camadas de flash para o índice e para os dados recentes. É uma variável direta do RTO: um restore que a diretoria espera em duas horas pode levar doze se o repositório for dedup agressiva sobre disco lento e ninguém tiver testado.

Há também um risco de integridade. Como um bloco físico único atende centenas de arquivos e dezenas de pontos de restauração, a corrupção desse bloco não afeta um arquivo — afeta tudo que aponta para ele. Isso não é motivo para abandonar dedup, mas obriga a três disciplinas:

1. Verificação periódica de integridade do repositório, com checagem de hash agendada e alerta ativo em caso de divergência.
2. Cópia secundária em domínio de dedup separado, seguindo a regra 3-2-1: um segundo repositório, idealmente offsite e imutável, que não compartilhe o mesmo índice.
3. Teste real de restauração, com cronômetro, pelo menos trimestral — restaurando de fato, não apenas validando que o job terminou em verde.

Um detalhe operacional relevante: em repositórios deduplicados, apagar pontos de restauração antigos não libera espaço proporcionalmente. Os blocos só somem quando nenhuma referência restante aponta para eles, e o espaço só volta após o processo de coleta de lixo do repositório rodar. Planejar capacidade sem contar com esse atraso é receita para encher o disco no fim do mês.

Quando cada técnica compensa — e quando não

A decisão deve sair de características do ambiente, não de preferência de fornecedor. Alguns padrões se repetem com bastante consistência:

• Muitas VMs com SO parecido e retenção longa — dedup é a alavanca principal. Ganhos de 10:1 ou mais são realistas, e o retorno aparece já no primeiro ciclo completo de retenção.
• Banco de dados grande com backup full frequente — dedup entre pontos funciona muito bem, porque a maior parte das páginas não muda entre um full e o seguinte. Cuidado com bancos que já aplicam compressão nativa: nesse caso, desligue a compressão do backup e mantenha só a dedup.
• Acervo de mídia, CAD renderizado, imagens científicas — pouco ganho em ambas as técnicas. O caminho de economia aqui é política de retenção e camadas de armazenamento frio, não algoritmo.
• Filial com link estreito — dedup na origem, obrigatoriamente, mesmo pagando o preço de CPU. Sem ela, a janela de backup não fecha.
• Backup direto para nuvem — dedup e compressão reduzem armazenamento e também tráfego de saída. Vale checar se o provedor cobra por requisição: dedup com bloco muito pequeno gera muitas operações e a economia de disco pode ser anulada pelo custo de API.
• RTO agressivo, na casa de minutos — considere manter as cópias mais recentes com dedup leve ou desativada em camada rápida, e aplicar dedup pesada apenas nas cópias antigas, cujo restore é raro.

O último padrão merece destaque porque resume a lógica do desenho inteiro: a taxa de redução ideal não é a maior possível, é a maior compatível com o RTO acordado. Economizar 40% de disco e dobrar o tempo de recuperação de um ERP parado é um mau negócio que só fica visível no dia do incidente.

Como a Duk aborda esse dimensionamento

Em 18+ anos atendendo mais de 550 empresas, o erro que mais encontramos não é escolher o algoritmo errado — é escolher qualquer configuração sem medir o ambiente antes. A taxa de dedup de um cliente com 60 VMs Windows homogêneas não tem relação com a de um cliente cujo repositório é 80% arquivo de projeto renderizado, e copiar a configuração de um para o outro produz frustração garantida nos dois sentidos: espaço desperdiçado ou restore inaceitavelmente lento.

Nosso ponto de partida é sempre uma leitura do dado real: composição do conjunto protegido por tipo de arquivo, taxa de mudança diária, retenção exigida por contrato ou norma, e RTO/RPO efetivamente acordados com cada área de negócio. Com isso em mãos, dimensionamos o repositório, escolhemos onde a dedup roda, definimos o nível de compressão por camada e projetamos a curva de crescimento de capacidade para os 24 meses seguintes — incluindo a folga necessária para a coleta de lixo operar sem apertar o disco.

A operação continuada fecha o ciclo: monitoramento de taxa de redução ao longo do tempo (queda súbita costuma indicar mudança de perfil de dado ou criptografia nova em algum servidor), verificação de integridade agendada, cópia secundária imutável offsite e testes de restauração cronometrados, com relatório do tempo real medido — não do tempo estimado. Como Microsoft Gold Partner com data center próprio em Alphaville, conseguimos combinar repositório local para restore rápido e cópia em nuvem para retenção longa, cada camada com a configuração de dedup e compressão que faz sentido para o papel que ela cumpre.

Se o custo do seu backup vem crescendo e ninguém sabe dizer qual é a taxa de redução atual nem quanto tempo leva um restore completo, essas duas perguntas são o melhor lugar para começar. As respostas costumam apontar sozinhas onde está o desperdício.