Nem toda aplicação pertence à nuvem pública. Um controle de máquina que precisa responder na faixa de milissegundos, um sistema de gestão de mercadorias com grandes acervos locais de dados, um procedimento especializado com exigências rígidas de soberania de dados – tais cargas de trabalho rodam, por boas razões, onde surgem: na própria casa. Latência, controle sobre os dados e a estrutura de custos com carga constante falam então claramente a favor do servidor local.
O problema não é o servidor local. O problema é o servidor local como único lugar. Uma sala de servidores em um único site é uma construção de ponto único de falha – contra incêndio, dano por água, roubo, queda de energia e, há muito o caso mais frequente, contra um atacante que criptografa toda a rede ao mesmo tempo. Quem quer manter as vantagens da operação local sem aceitar sua fragilidade não escapa de uma pergunta: o que acontece se essa única sala amanhã não existir mais?
A falsa alternativa: ou local ou nuvem
A narrativa difundida diz que é preciso decidir – data center ou sala de servidores própria, nuvem ou on-premises. Isso é uma falsa alternativa. A operação local resolve exigências reais de latência e soberania de dados que uma migração puramente para a nuvem não elimina argumentando. Por outro lado, o data center externo resolve o risco de site que uma operação puramente local não cobre estruturalmente. Ambos os lados são fortes para tarefas distintas.
A resposta sustentável não é um ou outro, mas uma divisão de trabalho: os sistemas produtivos rodam onde pertencem – no local. Seu backup e um caminho de reinício ficam onde sobrevivem a um evento local – no data center geograficamente separado. Chamamos isso de ponte híbrida: operação local e capacidade externa de reinício como um único modelo operacional contínuo, não como dois contratos separados.
O que permanece local – e o que é replicado
A divisão não segue nenhuma ideologia, mas a pergunta sobre onde uma carga de trabalho desdobra seu benefício e onde uma cópia é necessária no caso concreto.
Local permanece a operação produtiva. Tudo o que se beneficia de caminhos curtos e baixa latência ou precisa de grandes volumes de dados constantemente acessíveis roda no servidor na casa: hosts de virtualização, serviços de arquivos e de banco de dados, aplicações especializadas, proximidade de máquinas e de site. Aqui conta o tempo de resposta, aqui conta o controle total sobre o local físico dos dados.
Replicada é a recuperabilidade. Para o data center externo migra não a operação produtiva, mas sua proteção: pontos de backup consistentes das máquinas virtuais e dos dados – como cópia replicada fora da casa, geograficamente separada do original. Com isso, a última cópia nunca está apenas em um lugar, e o reinício não depende exatamente do prédio que o incidente atingiu.
Que ao menos uma cópia adicional precisa estar armazenada de forma imutável, para que sobreviva a um atacante com privilégios de administrador, é a segunda condição. Como a imutabilidade e a regra ampliada 3-2-1-1-0 funcionam tecnicamente descrevemos detalhadamente em outro lugar; para este modelo operacional basta o lema: a cópia replicada no data center só é uma opção de recuo verdadeira se não puder ser nem apagada nem alterada a partir da rede comprometida.
O verdadeiro ganho: reinício centralizado
Uma cópia de backup fora da casa é pré-requisito, mas ainda não todo o valor. Decisivo é o que acontece com essa cópia no caso concreto.
Se a sala de servidores local falhar – seja por incêndio, dano total de hardware ou criptografia – os serviços podem ser reiniciados de forma centralizada no data center a partir da cópia replicada, enquanto o ambiente local é restaurado com calma. Isso desacopla dois relógios que, de outra forma, estão implacavelmente acoplados: o tempo até a operação voltar a funcionar e o tempo até a sala de servidores estar novamente de pé. Sem essa ponte, o negócio espera pelo reparo do hardware. Com ela, os serviços críticos seguem funcionando de forma centralizada, e a restauração local passa de uma emergência a um trabalho planejado.
É justamente aqui que está a diferença entre “temos um backup” e “conseguimos voltar a subir”. Um backup que está na mesma sala em chamas não responde à segunda afirmação.
RTO e RPO: os números antes da técnica
O quão rápido e com qual estado de dados um serviço precisa voltar a funcionar é uma decisão de negócio, não técnica. Dois indicadores a tornam discutível:
- RTO (Recovery Time Objective) – por quanto tempo um serviço pode ficar parado após uma falha? Minutos, horas, um dia útil?
- RPO (Recovery Point Objective) – quanta perda de dados é suportável? O estado de uma hora atrás, da última noite, do fim de semana?
Esses valores variam conforme o serviço – e esse é o ponto em que a ponte híbrida faz por merecer seu dinheiro. Um sistema ERP com RTO de duas horas e RPO de 15 minutos precisa de replicação frequente e de um reinício preparado no data center. Um arquivo, que salvo uma vez por dia suporta um dia de atraso, não precisa disso. Quem aplica a tudo o valor mais rígido paga por reservas de que ninguém precisa; quem aplica a tudo o valor mais frouxo descobre a lacuna só no incidente. A sequência limpa é: primeiro priorizar os processos e definir suas metas de RTO/RPO, depois dimensionar a frequência de replicação e o caminho de reinício conforme isso.
E porque um plano de reinício sem comprovação é apenas uma alegação, faz parte da ponte híbrida o caso concreto exercitado: recuperações são testadas, não presumidas. O marco estruturado para isso – da priorização de processos ao plano de contingência documentado – pertence a um conceito de business continuity bem pensado, e não a um palpite.
Um modelo operacional, não um produto
O atrativo dessa arquitetura está no fato de que ela não força nada de que a operação não precise de qualquer forma. Os servidores ficam onde latência e soberania de dados o exigem. A proteção fica onde um evento de site não a alcança. E a atribuição não está gravada em pedra: se a exigência mudar – uma carga de trabalho se torna apta à nuvem, outra precisa voltar para a casa por razões de compliance – a fronteira se desloca, sem que o modelo precise ser reinventado. Importante é apenas que a cópia replicada e o caminho central de reinício sejam planejados desde o início, e não surjam como uma retrofit cara após a primeira falha.
Como a sector7 apoia
Planejamos, adquirimos e operamos servidores, storage e virtualização diretamente na sua casa – como parceiro HPE a condições de parceiro, e, em caso de necessidade fundamentada, também Dell, Fujitsu ou sistemas especiais sob consulta. A proteção implementamos de forma baseada em Veeam e a replicamos para o nosso próprio parque de servidores, geograficamente redundante, na Alemanha – para que a última cópia nunca esteja apenas em um lugar e os serviços possam reiniciar de forma centralizada no caso concreto, enquanto restauramos o seu ambiente local. Novos sistemas rodam documentados no nosso monitoramento NOC 24 horas por dia. Como empresa de gestão própria de Solingen, certificada pelos fabricantes para Juniper, Cisco, HPE, F5, Fortinet e Palo Alto Networks, unimos proximidade local e data center de uma só fonte. Como construímos e protegemos a sua infraestrutura local descrevemos na nossa página Servidor e Backup local.