Janela de backup estourando: causas e como voltar a caber na madrugada

Por que a janela de backup estoura

A janela de backup é o intervalo de tempo em que a rotina de cópia pode rodar sem atrapalhar a operação. Na maioria das empresas brasileiras, ela vai das 20h às 6h — dez horas de folga aparente. O problema é que essa folga foi dimensionada quando o volume de dados era outro. O dado cresce de forma composta: novos usuários, novas aplicações, mais anexos de e-mail, mais imagens em alta resolução, mais logs de sistema. A janela, por outro lado, é fixa. Ela não cresce junto. Em algum momento as duas curvas se cruzam, e o backup que terminava às 3h passa a terminar às 7h30, com usuários já logados e o storage brigando por IOPS.

O sintoma clássico chega em três estágios. Primeiro, o job atrasa mas termina — ninguém percebe. Segundo, o job invade o horário comercial e a equipe começa a reclamar de lentidão no ERP pela manhã. Terceiro, o job simplesmente não termina: é abortado por timeout, entra em conflito com o job da noite seguinte, ou falha por falta de espaço no repositório porque o incremental anterior nunca fechou a cadeia. É nesse terceiro estágio que a maioria das empresas descobre que tem um problema — e é o pior momento possível, porque agora existe uma lacuna real na proteção dos dados.

Vale separar duas coisas que costumam ser confundidas: backup lento e janela estourada. Um backup pode ser lento e ainda assim caber na janela. E um backup pode ter throughput excelente e mesmo assim estourar, porque começa tarde demais ou porque a fase de consolidação (merge, synthetic full, verificação) consome tempo depois que a leitura já terminou. Diagnosticar sem essa distinção leva a comprar link ou disco que não resolve nada.

Os quatro gargalos reais e como identificar cada um

Toda cadeia de backup tem quatro pontos onde o tempo pode ser perdido: origem (leitura no servidor de produção), rede (transporte), proxy (processamento, compressão, deduplicação) e destino (gravação no repositório). O gargalo é sempre o mais lento dos quatro, e otimizar qualquer um dos outros três não muda nada. Ferramentas como Veeam já expõem isso diretamente no relatório do job com a linha de bottleneck — vale ler antes de qualquer decisão de compra.

• Gargalo de origem: disco de produção saturado, VM com snapshot antigo pendurado, banco de dados em uso pesado durante a leitura. Sintoma: o throughput cai justamente nos servidores mais críticos.
• Gargalo de rede: link de 1 Gbps compartilhado com produção, backup atravessando VPN ou WAN, negociação de porta caída para 100 Mbps por cabo ruim. Sintoma: throughput travado num teto suspeito e redondo (~110 MB/s, ~11 MB/s).
• Gargalo de proxy: CPU do servidor de backup em 100% durante toda a janela, compressão em nível alto demais, poucos slots de tarefas concorrentes. Sintoma: rede e disco ociosos, CPU no talo.
• Gargalo de destino: NAS com discos SATA 7200 RPM em RAID 5, repositório fazendo dedup inline, storage de backup também servindo como file server. Sintoma: gravação em serrote, com picos e vales.

Existe um quinto fator que não aparece como "gargalo" nos relatórios mas destrói janela do mesmo jeito: quantidade de arquivos. Copiar 500 GB em 5 mil arquivos grandes é rápido. Copiar os mesmos 500 GB distribuídos em 4 milhões de arquivos pequenos é uma operação completamente diferente — cada arquivo exige abertura, leitura de metadados, verificação de mudança, fechamento. O tempo passa a ser dominado por overhead de metadata, não por transferência. Pastas de perfil de usuário, caches de aplicação, diretórios de e-mail em formato maildir e repositórios de código com node_modules são os culpados habituais.

Regra prática de campo: se o throughput médio do job está bom mas o tempo total está ruim, o problema não é banda — é contagem de arquivos ou fase de pós-processamento. Meça sempre as duas métricas juntas.

Medir antes de mexer: o diagnóstico em uma noite

Antes de trocar qualquer hardware, colete três noites de dados. Uma noite única pode ter sido atípica — atualização do Windows, reindexação do banco, sincronização de um cliente novo. Três noites já mostram padrão. Para cada job, registre: horário de início real, horário de término, volume processado, volume efetivamente transferido, throughput médio, throughput de pico e o gargalo reportado pela ferramenta.

Com esses números na mão, calcule o tempo teórico mínimo: volume transferido dividido pela capacidade real do elo mais lento. Se o link entre proxy e repositório entrega 110 MB/s na prática e o incremental move 400 GB, o piso é de aproximadamente uma hora. Se o job está levando cinco horas para mover esses 400 GB, o problema não é o link — sobra alguém segurando a fila. Esse cálculo simples elimina a maior parte dos palpites e evita a compra reflexa de um switch 10 GbE que ficaria ocioso.

Complete o diagnóstico com monitoramento no servidor de origem durante a janela: fila de disco, latência de leitura, uso de CPU e, em ambientes virtualizados, tempo de criação e remoção de snapshot. Em VMware, a remoção de snapshot de uma VM grande e movimentada pode sozinha consumir 40 minutos e travar a VM no final — e isso não aparece como "backup lento", aparece como "sistema caiu às 4h da manhã".

Jobs escalonados: a correção que quase sempre funciona

A maioria dos ambientes com janela estourada tem todos os jobs começando às 20h em ponto. Faz sentido intuitivo — quanto antes começar, antes termina. Na prática é o pior arranjo possível: dez jobs disputando o mesmo proxy, a mesma NIC e o mesmo repositório ao mesmo tempo, cada um entregando um décimo do throughput, todos terminando tarde. Escalonar significa distribuir os inícios de forma que os recursos fiquem saturados mas não em contenção.

1. Classifique por criticidade e RPO. O que precisa de cópia diária às 20h e o que aceita rodar às 2h? Servidor de arquivos e banco do ERP são prioridade; estação de trabalho de departamento pode esperar.
2. Meça a duração real de cada job. Você precisa saber quanto cada um leva sozinho, sem concorrência, para conseguir encaixá-los.
3. Limite a concorrência. Defina quantas tarefas simultâneas o proxy e o repositório aguentam sem degradar. Dois jobs a 100% cada terminam antes de quatro jobs a 40% cada.
4. Encaixe em ondas. Onda 1 às 20h com os críticos, onda 2 às 23h, onda 3 às 2h. Deixe folga de 20% entre ondas para absorver variação.
5. Separe a fase de verificação. Health check, synthetic full e cópia para offsite não precisam competir com a leitura. Programe para depois da janela ou para o fim de semana.

Junto ao escalonamento, revise o que está sendo copiado. Muita janela é gasta protegendo dado que não precisa de proteção: arquivos temporários, cache de navegador, pastas de download, imagens ISO que podem ser baixadas de novo, arquivos de paginação e hibernação, bases de dados que já têm dump próprio sendo copiado em paralelo (dupla proteção do mesmo dado). Uma revisão de exclusões bem feita corta de 15% a 40% do volume em ambientes que nunca passaram por essa limpeza — sem custo nenhum de hardware.

Para o problema específico de milhões de arquivos pequenos, a saída raramente é otimizar o backup em nível de arquivo. É mudar de estratégia: backup em nível de bloco ou imagem, que lê o volume inteiro ignorando a estrutura de diretórios, ou changed block tracking em ambientes virtualizados, onde só os blocos alterados desde a última cópia são lidos. A diferença de tempo em pastas de perfil costuma ser de uma ordem de grandeza.

Quando o problema é mesmo de infraestrutura

Se depois do escalonamento, da revisão de exclusões e do ajuste de concorrência a janela continua estourando, aí sim o gargalo é físico. Os investimentos que efetivamente devolvem janela, em ordem de custo-benefício típico: separar a rede de backup em VLAN ou NIC dedicada (barato, resolve contenção com produção); trocar o repositório de RAID 5 em SATA para RAID 10 ou storage com SSD de cache (resolve o gargalo mais comum de destino); adicionar um segundo proxy para paralelizar leitura; e, por último, subir o link para 10 GbE — que só faz diferença se a medição provou que a rede é o elo mais lento.

Vale também revisitar a estratégia de retenção e o modelo de cadeia. Full semanal com incrementais diários é o arranjo clássico, mas em ambientes grandes o full de sábado pode ser justamente o que não cabe. Alternativas como forever incremental com synthetic full, ou full sintético gerado no próprio repositório sem reler a origem, eliminam o pico semanal e distribuem o esforço. A contrapartida é maior exigência de IOPS no destino e necessidade real de verificação periódica de integridade da cadeia — não adianta trocar janela por risco silencioso.

Backup que não cabe na janela é backup que, mais cedo ou mais tarde, vira backup que não existe. A lacuna começa como atraso e termina como job desligado "temporariamente" para liberar o ambiente.

Como a Duk trata janela de backup

Na Duk Informática & Cloud, a análise de janela faz parte do onboarding de qualquer cliente de backup gerenciado — antes de propor hardware, medimos três noites, identificamos o gargalo real e testamos o ganho de escalonamento e exclusões. Em boa parte dos casos a janela volta a caber sem nenhum investimento em equipamento, apenas com reorganização de jobs e limpeza do escopo. Quando o gargalo é mesmo físico, a recomendação vem com o número que a justifica, não com um palpite.

São mais de 18 anos de operação e 550+ empresas atendidas, com data center próprio em Alphaville para quem precisa de cópia offsite sem depender de link doméstico ou de disco externo levado para casa. Como Microsoft Gold Partner, integramos a proteção de Microsoft 365 — Exchange Online, SharePoint e OneDrive — à mesma política e ao mesmo painel de monitoramento do backup local, com relatório diário de sucesso e falha e teste de restauração periódico agendado.

O ponto que mais insistimos com os clientes é este: janela de backup é um indicador de saúde, não uma tarefa de TI. Quando ela começa a apertar, está avisando com meses de antecedência que a infraestrutura de proteção não acompanhou o crescimento do negócio. Monitorada e tratada cedo, custa uma reorganização de agenda. Ignorada até o job falhar, custa um incidente de dados. Se a sua rotina está terminando mais tarde a cada mês, vale conversar antes de a curva cruzar.