Dimensionar storage de backup errado tem consequências silenciosas: repositório cheio no meio da noite, backup falhando sem alerta, dados sem proteção por semanas antes de alguém perceber. Este artigo mostra como calcular o espaço necessário com uma fórmula prática e um exemplo real com 50 TB de dados.
As variáveis que determinam o tamanho do repositório
Imagine que você precisa calcular o tamanho de um armário de arquivos. Você precisa saber: quantos documentos existem hoje, quantos novos chegam por semana, por quanto tempo cada documento precisa ser guardado, e se você vai compactar os documentos ou guardar em papel tamanho normal. A mesma lógica se aplica ao dimensionamento de storage de backup.
As variáveis fundamentais são quatro. A primeira é o volume de dados protegidos — o tamanho total do que você está fazendo backup (dados primários, não o backup em si). A segunda é a taxa de mudança diária — que porcentagem dos dados muda por dia. Sistemas transacionais podem ter 5 a 10% de mudança diária; servidores de arquivo podem ter 1 a 3%; bancos de dados com alto volume de transações podem ter 15% ou mais. A terceira é a política de retenção — por quantos dias (ou semanas, meses) você precisa manter as cópias. A quarta são as razões de deduplicação e compressão que o seu software de backup aplica.
A fórmula de dimensionamento — passo a passo
A fórmula básica para calcular o espaço bruto necessário antes de deduplicação e compressão é:
Espaço bruto = (backup completo × 1) + (dados protegidos × taxa de mudança × retenção em dias)
O primeiro backup completo ocupa o tamanho integral dos dados. Os backups incrementais seguintes (diários) ocupam apenas os dados que mudaram. Com uma política de retenção de 30 dias, você acumula 1 backup completo mais 29 incrementais.
Depois de calcular o espaço bruto, você divide pela razão de deduplicação e compressão efetiva para chegar ao espaço real necessário no repositório. Adicione 20% de margem de segurança para crescimento orgânico e variações.
Espaço real = (Espaço bruto / razão de dedup+compressão) × 1,20
O impacto real da deduplicação e compressão
Na prática, deduplicação e compressão são os maiores fatores que separam uma estimativa correta de uma completamente errada. E os números variam muito dependendo do tipo de dado.
VMs de servidor Windows com sistema operacional e aplicações padrão têm altíssima redundância entre si. Dezenas de VMs com o mesmo Windows Server, o mesmo SQL Server, os mesmos binários de sistema — deduplicação pode encontrar razões de 5:1 a 20:1 facilmente. Cem VMs com Windows ocupam muito menos espaço no repositório do que cem vezes o tamanho de uma VM individual.
Bancos de dados relacionais têm compressão boa — os dados de texto e numéricos comprimem bem — mas deduplicação menor, porque os dados são mais únicos entre backups. Razões de 2:1 a 4:1 são realistas.
Dados de usuário (documentos Office, PDFs, emails) têm deduplicação boa entre versões do mesmo arquivo, mas compressão moderada porque formatos modernos já são comprimidos. Razão de 2:1 a 5:1 dependendo do perfil.
Vídeo, imagens e dados já comprimidos (ZIPs, ISOs) têm razão próxima de 1:1 — deduplicação e compressão praticamente não ajudam. Não conte com redução de espaço para esse tipo de dado.
Backup primário vs repositório de longo prazo
O problema real aqui é tratar backup de retenção curta e arquivamento de longo prazo como se fossem a mesma coisa, usando o mesmo storage para os dois.
O repositório de backup primário guarda as cópias recentes — os pontos de restore que você vai usar com frequência. Esse repositório precisa de acesso rápido, porque restore urgente acontece quando você menos espera. Storage Tier 1 (SSD ou NVMe) ou Tier 2 (HDD de alta velocidade) com acesso rápido.
O repositório de longo prazo (ou arquivo) guarda cópias para compliance, auditoria e recuperação de desastres. A retenção pode ser de 1, 5 ou 10 anos. Esse dado raramente é acessado e quando é, tolera horas de latência de recovery. Object storage de custo baixo ou fita são o destino natural.
A separação entre os dois reduz o custo global: você paga storage caro só pelo volume que realmente precisa de acesso rápido, e storage barato pelo volume histórico.
Por que o storage de backup não deve ser o mesmo do primário
Imagine que você tem um servidor de produção com banco de dados e o backup vai para um volume no mesmo array. Um ransomware atinge o servidor de produção, criptografa os dados e — porque o storage de backup está acessível pela mesma rede — criptografa o backup também. Você não tem nada para restaurar.
Essa não é uma hipótese improvável. É o cenário exato que acontece em incidentes de ransomware quando o backup não tem isolamento adequado. A regra básica de proteção é a 3-2-1: três cópias dos dados, em dois tipos diferentes de mídia, uma das quais em local fisicamente separado ou logicamente isolado (air-gap).
Fisicamente separado significa outro datacenter, outra localização geográfica. Logicamente isolado (air-gap lógico) significa que o repositório de backup usa um protocolo que os servidores de produção não conseguem escrever diretamente — como um appliance de backup com protocolo proprietário, ou object storage acessível apenas pelo servidor de backup através de credenciais rotacionadas automaticamente.
Exemplo numérico completo — 50 TB de dados
Pense assim: sua empresa tem 50 TB de dados para proteger, compostos de:
- 30 TB de VMs de servidor Windows (múltiplas VMs com sistema operacional similar)
- 15 TB de bancos de dados SQL
- 5 TB de dados de usuário (documentos, e-mails)
Taxa de mudança diária estimada: 5% das VMs (1,5 TB/dia), 10% do banco de dados (1,5 TB/dia), 2% dos dados de usuário (0,1 TB/dia). Total de mudança diária: aproximadamente 3,1 TB/dia.
Política de retenção: 30 dias de backup diário para uso operacional, 12 meses de retenção mensal para compliance.
Cálculo do repositório de 30 dias:
Backup completo inicial: 50 TB
Incrementais: 3,1 TB/dia × 29 dias = ~90 TB
Total bruto: 140 TB
Razões de deduplicação e compressão estimadas:
- VMs Windows: razão 8:1 → 30 TB vira 3,75 TB
- Bancos de dados: razão 3:1 → 15 TB vira 5 TB
- Dados de usuário: razão 4:1 → 5 TB vira 1,25 TB
- Incrementais com razão média 5:1 → 90 TB viram 18 TB
Total após dedup/compressão: ~28 TB
Com 20% de margem: ~34 TB
Repositório de 30 dias: aproximadamente 34 TB de storage Tier 1/2.
Retenção de 12 meses (backups mensais): 12 backups completos pós-dedup ≈ 12 × 10 TB = ~120 TB em object storage Tier 3 de custo baixo.
O total é ~34 TB de storage primário de backup (SSD/HDD rápido) e ~120 TB de repositório de longo prazo (object storage barato). Sem a análise correta de deduplicação, a estimativa bruta seria de 140 TB só para os 30 dias — mais de 4× o espaço real necessário.
O Backup Corporativo da Adentro já inclui storage dimensionado para seu volume de dados, deduplicação e compressão automáticas, e repositório de longo prazo em object storage — com faturamento em Real e dados nos datacenters Tier III no Brasil. Solicite uma análise do seu ambiente.