Estratégias de Deduplicação de Ficheiros na Cloud

A deduplicação de ficheiros reduz o armazenamento na nuvem em 20 a 90% dependendo da carga de trabalho, usando uma de três técnicas: ao nível do ficheiro (armazenar ficheiros idênticos uma vez, indexados por hash SHA-256), ao nível do bloco (dividir ficheiros em blocos de 4-128 KB e deduplicar por bloco), ou divisão de comprimento variável via content-defined chunking (CDC) com impressões digitais Rabin. Os backups de VMs atingem reduções de 10:1; os ficheiros de escritório em geral, 2:1; as bibliotecas de media quase nada. Escolha a técnica que corresponde aos seus dados — executar deduplicação de blocos numa biblioteca de ficheiros .mp4 já únicos desperdiça CPU sem qualquer benefício.

Dedup ao Nível do Ficheiro: A Vitória Mais Simples

A dedup ao nível do ficheiro compara hashes de ficheiros completos. Dois ficheiros com o mesmo SHA-256 são idênticos; guarde um, aponte o outro para ele. A implementação demora um fim de semana:

1. Inventarie os conteúdos do bucket (S3 Inventory, Azure Inventory, lista de buckets GCS)
2. Calcule o SHA-256 para cada objeto (ou use as ETags fornecidas pelo fornecedor, com ressalvas)
3. Agrupe por hash, escolha uma chave canónica por grupo, atualize as referências, elimine duplicados

Ressalvas: as ETags do S3 correspondem ao SHA-256 apenas para carregamentos de parte única abaixo de 5 GB. Os carregamentos multipart usam uma fórmula diferente (hash de hashes). Para dedup fiável, calcule o seu próprio hash com aws s3 cp s3://bucket/key - | sha256sum ou calcule no momento do carregamento e armazene nos metadados.

A dedup ao nível do ficheiro destaca-se quando os utilizadores carregam rotineiramente os mesmos ficheiros — PDFs de fornecedores, modelos da empresa, imagens partilhadas. Espere poupanças de 10-30% em cargas de trabalho de escritório típicas.

Dedup ao Nível do Bloco: O Grande Multiplicador

O nível de bloco divide cada ficheiro em fragmentos de tamanho fixo (4 KB, 16 KB, 64 KB) e calcula o hash de cada fragmento. Dois ficheiros que partilham 80% dos seus fragmentos armazenam apenas os 20% únicos mais uma cópia dos blocos partilhados. Produtos de backup (Veeam, Rubrik, Commvault), sistemas de ficheiros (ZFS com dedup=on, Btrfs) e algumas nuvens de backup (Backblaze B2 com dedup do lado do cliente) usam isto.

Vantagens: compressão massiva em imagens de VM, backups de bases de dados e arquivos de registos onde os ficheiros partilham grandes intervalos. Desvantagens: uso elevado de memória (o índice de dedup vive na RAM), custo de CPU no momento da escrita, e amplificação catastrófica se o índice se corromper.

Para armazenamento de objetos na nuvem, a dedup ao nível do bloco geralmente acontece dentro de um produto de backup e não como funcionalidade nativa. O S3 em si não deuplica; o Backblaze B2 deduplica no carregamento quando o cliente envia primeiro os hashes dos blocos (b2_start_large_file com partes pré-calculadas).

Content-Defined Chunking (CDC)

A divisão em blocos de tamanho fixo falha quando um byte é inserido no início de um ficheiro — todos os blocos subsequentes têm hashes diferentes. O Content-Defined Chunking usa um hash deslizante (impressão digital Rabin-Karp) para definir os limites dos fragmentos com base em padrões de conteúdo. Insira um byte e apenas o fragmento imediato muda.

O CDC é a base do restic, BorgBackup, Duplicacy e Kopia. Estas ferramentas open-source deduplicam do lado do cliente com fragmentos variáveis de 1-4 MB em média. Para fazer backup de 500 GB de ficheiros que mudam incrementalmente, os backups baseados em CDC frequentemente usam menos de 50 GB de armazenamento único.

Se está a construir um sistema de backup ou sincronização, o CDC via uma biblioteca como fastcdc-rs ou chunky é a escolha moderna. Não implemente o seu próprio hash deslizante — os casos extremos são subtis.

Dedup Inline vs Pós-Processamento

A dedup inline corre no momento da escrita — antes de os dados atingirem o disco, o sistema verifica se o bloco já existe. Se sim, escreve uma referência; se não, escreve o bloco. Usada pelo ZFS, pela maioria dos appliances de backup e por algumas camadas de armazenamento na nuvem.

A dedup pós-processamento escreve primeiro e depois executa um trabalho em segundo plano para encontrar duplicados e recuperar espaço. Usada pela Deduplicação de Dados do Windows Server, pelo SnapVault da NetApp e pela maioria das ferramentas de espaço de utilizador. O pós-processamento tem menor latência de escrita mas precisa de mais armazenamento de pico (os duplicados existem brevemente antes da recuperação).

Para cargas de trabalho na nuvem, a dedup inline geralmente não está disponível — o S3 não a oferece. O pós-processamento com um trabalho agendado (inventário diário, execução diária de dedup) é o padrão prático.

Onde a Dedup Não Ajuda

Dados já comprimidos ou encriptados deduplicam mal. Dois ficheiros .mp4 diferentes, mesmo de conteúdo semelhante, partilham quase nenhum byte. Dois ficheiros .zip encriptados do mesmo texto simples partilham zero bytes após a encriptação — esse é precisamente o ponto da encriptação.

Isto significa que o armazenamento de ficheiros com cifração ponta a ponta não pode deduplicar entre utilizadores. A encriptação convergente (calcular o hash do texto simples e usar o hash como chave) foi uma tentativa de permitir dedup em E2EE, mas tem problemas de segurança — permite ataques de confirmação de ficheiro. Para serviços de ficheiros E2EE, aceite que a dedup acontece dentro dos ficheiros de um utilizador, não entre utilizadores.

O Lado da Segurança da Dedup

A dedup entre utilizadores em sistemas não-E2EE cria um canal lateral: se um ficheiro que carrega deduplica para um bloco existente, o servidor fica a saber que outra pessoa já tinha esse ficheiro. O Dropbox expôs isto em 2011; outros serviços também. Para contas empresariais partilhadas é aceitável, mas para serviços que afirmam privacidade, é uma fuga.

Se a confidencialidade é importante, deuplique apenas dentro dos dados de um utilizador (com salt por chave específica do utilizador), não em todo o sistema. Ou aceite que E2EE significa sem dedup e dimensione o armazenamento em conformidade. Ferramentas que priorizam a privacidade — como o HexaTransfer para transferências ad hoc encriptadas — trocam a eficiência da dedup pela garantia de que ninguém mais (incluindo o serviço) pode saber se dois utilizadores têm o mesmo ficheiro.

Medir a Eficácia da Dedup

Não basta ativar a dedup e esperar. Meça o rácio:

dedup_ratio = bytes_lógicos / bytes_físicos

Um rácio de 2:1 significa que está a armazenar 2 bytes lógicos por cada 1 byte físico. Ferramentas de relatório: zpool get dedupratio no ZFS, Get-DedupStatus no Windows Server, estatísticas por repositório no restic/Borg.

Rácios saudáveis por carga de trabalho:

• Imagens de VM: 8-20:1
• Backups de bases de dados: 10-30:1
• Servidor de ficheiros (documentos de escritório): 1,5-3:1
• Arquivos de e-mail: 2-5:1
• Bibliotecas de media: 1,0-1,1:1 (não vale a pena)
• Arquivos encriptados: 1,0:1 (impossível)

Se o rácio de uma carga de trabalho estiver abaixo de 1,5:1, desative a dedup — a CPU e a memória não estão a compensar.

Integração com Produtos de Backup

A maioria das empresas não implementa dedup do zero — usam um produto de backup que o faz. Pontos de comparação na seleção:

• Veeam: Dedup de blocos inline, fragmentos padrão de 512 KB, compressão após dedup
• Rubrik: Fragmentos variáveis definidos por conteúdo, dedup sub-bloco
• Commvault: Dedup do lado do cliente com pools por cliente e global
• restic/Borg/Kopia: CDC open-source, do lado do cliente, backends S3/B2/Azure
• BackupPC: Ao nível do ficheiro com hardlinks, simples mas datado

Para uma pequena empresa que faz backup de 2 TB para o S3 Glacier, o restic para o Glacier Instant Retrieval custa cerca de 15 EUR/mês com dedup 5:1. Para um conjunto de dados empresarial de 500 TB, uma plataforma de backup adequada com dedup amortiza-se no primeiro ano de poupança em armazenamento.

Quando Acrescentar Compressão

A dedup remove bytes duplicados; a compressão remove a redundância dentro dos bytes únicos. Estas operações somam-se. Após a dedup, aplique compressão zstd para uma redução adicional de 1,5 a 2 vezes em dados com muito texto. O BorgBackup suporta --compression zstd; o restic tem --compression max; o AWS EFS tem compressão transparente para OneZone-IA.

A ordem importa: dedup primeiro (para expor blocos duplicados), depois comprimir os blocos únicos. Comprimir primeiro geralmente derrota a dedup porque pequenas alterações na entrada se propagam pela saída comprimida. Todos os produtos de backup sérios lidam com isto corretamente — basta escolher as opções certas.

A dedup é aborrecida, sem glamour, e o maior alavancador de custo de armazenamento para cargas de trabalho mistas. Inventarie os dados, escolha a técnica que corresponde ao conteúdo, meça o rácio e recupere o orçamento.

Experimente em hexatransfer.com — gratuito, sem conta necessária, máximo de 10 GB.