Quando o objetivo é reduzir custo de retenção sem abdicar de controlo, a combinação entre Veeam e Wasabi surge com frequência nas decisões de infraestrutura. Para muitas equipas de TI, perceber como configurar backup no Wasabi com Veeam não é apenas uma tarefa técnica – é uma decisão com impacto direto na recuperação, na proteção contra ransomware e na previsibilidade de custos.
A boa notícia é que a configuração é relativamente direta. A parte menos óbvia está nos detalhes que afetam produção: a região do bucket, a imutabilidade, o dimensionamento da cache local e a forma como a política de retenção influencia consumo e desempenho. É aí que a diferença entre um backup funcional e uma estratégia de continuidade operacional bem montada se torna evidente.
Como configurar backup no Wasabi com Veeam sem erros comuns
Antes de criar jobs, convém garantir três pré-requisitos: uma conta Wasabi ativa, um bucket previamente criado na região correta e uma infraestrutura Veeam atualizada para uma versão com suporte consistente a object storage e políticas de imutabilidade. Num ambiente empresarial, também é recomendável confirmar requisitos de firewall, resolução DNS e largura de banda disponível para janelas de backup e restore.
No Wasabi, o primeiro passo é criar o bucket que vai receber os backups. A escolha da região não deve ser feita apenas por proximidade geográfica. Deve considerar latência, requisitos de residência de dados e a estratégia global de disaster recovery. Se os dados primários estiverem em Portugal, faz sentido avaliar uma região europeia para reduzir latência e simplificar enquadramentos de conformidade.
Depois disso, é necessário gerar uma Access Key e uma Secret Key no console do Wasabi. Estas credenciais serão usadas pelo Veeam para autenticar no serviço S3 compatible. A recomendação, num contexto empresarial, é criar credenciais dedicadas ao backup e não reutilizar chaves associadas a outras operações. Isso simplifica auditoria e reduz risco operacional.
No lado do Veeam, a configuração começa em Backup Infrastructure. A partir daí, adiciona-se um Object Storage Repository e escolhe-se o tipo compatível com S3. O Wasabi não surge sempre como opção destacada em todas as versões, mas funciona através da compatibilidade com Amazon S3. Nesta fase, é importante introduzir o service point correto da região Wasabi escolhida, bem como as credenciais criadas anteriormente.
Depois da ligação validada, seleciona-se o bucket e, se necessário, uma pasta lógica dentro desse bucket. Em ambientes com múltiplas cargas de trabalho, separar repositórios por função, criticidade ou unidade de negócio ajuda bastante na gestão. Nem sempre vale a pena consolidar tudo no mesmo destino. Embora simplifique a administração inicial, pode complicar retenções diferenciadas, reporting e controlo de crescimento.
Configurar Scale-out Backup Repository para Wasabi
Na maioria dos cenários empresariais, o Wasabi não deve ser tratado como destino isolado logo à partida. A abordagem mais comum e mais equilibrada consiste em usá-lo como Capacity Tier num Scale-out Backup Repository, mantendo um repositório local como Performance Tier.
Isto permite ao Veeam escrever primeiro para armazenamento local, com melhores tempos de ingestão e recuperação rápida, e depois descarregar ou copiar blocos para o object storage. O resultado é uma arquitetura mais flexível: restores operacionais continuam rápidos no local e a retenção prolongada passa para uma camada com custo mais previsível.
Para isso, cria-se primeiro um repositório local, que pode estar num servidor Windows ou Linux hardened repository, consoante a arquitetura existente. Depois, num Scale-out Backup Repository, adiciona-se esse repositório como Performance Tier e o Wasabi como Capacity Tier. Aqui surgem decisões importantes.
Se ativar a opção para mover backups antigos para o object storage, reduz consumo local ao fim de determinado número de dias. Se ativar a cópia imediata de todos os backups para o Capacity Tier, aproxima-se mais de uma estratégia 3-2-1 com réplica adicional externa. A escolha depende do RPO, da capacidade local disponível e do orçamento. Nem sempre a política mais agressiva de offload é a mais adequada, sobretudo quando a largura de banda é limitada.
Imutabilidade no Wasabi com Veeam
Se há um motivo para esta combinação ser tão procurada, é a possibilidade de reforçar proteção contra eliminação maliciosa ou encriptação por ransomware. Ao configurar o repositório object storage no Veeam, pode ativar a opção de imutabilidade, desde que o bucket e a plataforma suportem Object Lock.
Na prática, isto impede a alteração ou remoção dos dados durante o período definido. É uma camada muito relevante para cópias de segurança que precisam de resistir a erro humano, credenciais comprometidas ou ações maliciosas. Ainda assim, a imutabilidade deve ser configurada com critério. Um período demasiado curto pode ser insuficiente para detetar incidentes. Um período demasiado longo pode aumentar custos e reduzir flexibilidade operacional.
O equilíbrio costuma depender do perfil da organização. Uma PME pode optar por uma janela mais conservadora, suficiente para proteção contra eventos recentes. Uma entidade com requisitos regulatórios ou risco elevado pode precisar de retenções mais extensas e políticas mais rígidas. O ponto essencial é alinhar a configuração técnica com a política real de recuperação, e não apenas ativar a funcionalidade porque está disponível.
Boas práticas de desempenho, retenção e custos
Configurar é apenas o início. O comportamento do backup ao longo do tempo vai depender muito mais das definições de retenção e do desenho da solução do que do assistente inicial.
No Veeam, convém rever o tipo de job, o número de restore points e a frequência de full backups. No object storage, as full sintéticas e a forma como os blocos são geridos podem influenciar ocupação e transferência. É por isso que uma retenção mal calculada tende a gerar surpresas de capacidade alguns meses depois, mesmo quando o projeto começou com números prudentes.
Outro ponto relevante é a cache local. O Veeam usa componentes intermédios para indexação e movimentação de dados para o object storage. Se essa camada estiver subdimensionada, pode haver impacto no desempenho dos jobs e nas operações de manutenção. Em ambientes mais exigentes, vale a pena dedicar armazenamento adequado a esta função, em vez de a tratar como detalhe secundário.
Também importa olhar para a conectividade. O Wasabi oferece um modelo de custo apelativo, mas a experiência prática vai depender da qualidade da ligação de saída, da concorrência com outras aplicações e da janela disponível para backup. Quando há volumes elevados, pode ser necessário escalonar jobs, ajustar paralelismo ou combinar retenção local com retenção cloud de forma mais gradual.
Erros frequentes na configuração
Um erro comum é apontar diretamente todos os jobs para o object storage sem considerar tempos de recuperação. Para retenção longa, o modelo funciona bem. Para restores frequentes ou exigências de RTO apertadas, a ausência de uma camada local pode tornar a operação menos eficiente.
Outro erro recorrente é ignorar a validação de restores. O backup pode estar a correr corretamente e mesmo assim falhar no momento de recuperação por questões de consistência aplicacional, largura de banda ou expectativas erradas sobre tempos de reposição. Testar restores faz parte da configuração real, não é uma etapa opcional.
Também se vê com frequência a criação de buckets sem convenções claras, sem segmentação por cliente interno ou sem políticas coerentes entre ambientes. Isso não trava a operação no primeiro dia, mas complica crescimento, troubleshooting e governação quando a solução escala.
Quando esta arquitetura faz mais sentido
A combinação Wasabi com Veeam é particularmente interessante para organizações que precisam de retenção externa, proteção adicional contra ransomware e maior controlo de custos face a outros hyperscalers. Faz sentido em cenários de backup off-site, ficheiro de longo prazo e extensão de capacidade sem investimento imediato em storage local adicional.
Ainda assim, não é uma resposta universal. Se a operação exigir restores massivos e muito frequentes, ou se a conectividade for limitada, pode ser preferível manter uma estratégia híbrida com maior peso no armazenamento local. O desenho certo depende sempre do perfil de dados, dos objetivos de recuperação e da maturidade operacional da equipa.
Para empresas que procuram um modelo tecnicamente sólido e ajustado ao contexto real do negócio, o mais importante não é apenas saber como configurar backup no Wasabi com Veeam. É garantir que essa configuração responde ao que realmente interessa: recuperar dados quando for preciso, dentro do tempo esperado e com risco controlado. Quando essa base está bem definida, a tecnologia deixa de ser apenas infraestrutura e passa a ser continuidade operacional com critério.