A maioria dos programas de backup é posta à prova no dia em que é necessária, e muitos falham nesse dia por motivos visíveis muito antes: uma tarefa que pula um volume sem avisar, um banco de dados copiado no meio de uma escrita, uma restauração que leva dias por um link que ninguém mediu, ou backups criptografados pelo mesmo atacante que criptografou a produção.
Este guia parte desses números, o objetivo de ponto de recuperação (RPO) e o objetivo de tempo de recuperação (RTO), e avança a partir deles: quantas cópias manter, como fazer uma delas sobreviver a um ransomware, como capturar bancos de dados de forma consistente, com que frequência comprovar que as restaurações funcionam, como escrever runbooks e para onde vai o dinheiro.
Comece pelo RPO e pelo RTO de cada sistema
O RPO é quanto de dados você pode se dar ao luxo de perder, medido em tempo. Um RPO de 24 horas significa que um backup noturno é aceitável. Um RPO de 15 minutos significa log shipping contínuo, replicação ou snapshots muito frequentes. O RTO é por quanto tempo um sistema pode ficar indisponível, medido da falha até os usuários voltarem a trabalhar.
Esses números devem vir do responsável de negócio por cada sistema, e não apenas da TI, e devem ser documentados. Os sistemas geralmente se enquadram em alguns níveis:
- Tier 1. Sistemas de receita e voltados ao cliente, como processamento de pedidos, pagamentos e bancos de dados centrais. Metas típicas: RPO de minutos, RTO de 1 a 4 horas.
- Tier 2. Sistemas internos dos quais as pessoas dependem diariamente, como ERP, compartilhamentos de arquivos, e-mail e chamados. Metas típicas: RPO de 1 a 4 horas, RTO de 8 a 24 horas.
- Tier 3. Arquivos, réplicas para relatórios, ambientes de desenvolvimento e de teste. Metas típicas: RPO de 24 horas, RTO de vários dias.
- Reconstruíveis. Servidores stateless construídos a partir de código ou imagens. Faça backup da configuração e do pipeline de build, não dos próprios servidores.
O RTO inclui tudo: detectar a falha, decidir pela recuperação, acessar o sistema de backup, provisionar hardware, transferir os dados e validar a aplicação.
A regra 3-2-1 e sua extensão moderna
A regra 3-2-1 clássica diz para manter três cópias dos seus dados (a produção mais dois backups), em dois sistemas ou mídias de armazenamento diferentes, com uma cópia fora do local.
Muitas equipes hoje usam a regra 3-2-1-1-0: uma cópia fica offline ou imutável, e as restaurações são verificadas com zero erros. Os termos extras existem porque os operadores de ransomware procuram e apagam os backups acessíveis antes de criptografar a produção. Um backup que uma conta de administrador consegue apagar é só mais um alvo.
Na prática, "duas mídias" hoje costuma significar dois sistemas de armazenamento independentes, e não disco e fita. Um appliance de backup local mais um armazenamento de objetos em outra instalação atende ao critério. Dois volumes no mesmo storage não atendem, e um snapshot sozinho não é backup, porque compartilha hardware e credenciais com os dados que protege.
Cópias imutáveis e isoladas contra ransomware
Uma cópia imutável não pode ser modificada nem excluída até que seu período de retenção expire, nem mesmo por um administrador. Opções comuns são armazenamento de objetos com travas de retenção write-once em modo compliance, appliances de backup com retenção reforçada e mídias desconectadas fisicamente.
A imutabilidade só ajuda se os controles ao redor estiverem à altura. Parta do princípio de que um atacante tem direitos de administrador de domínio em produção e pergunte o que ele ainda não consegue alcançar:
- Identidade separada. A plataforma de backup usa contas próprias, não o diretório de produção, com autenticação multifator em todo login administrativo.
- Retenção travada. Travas de retenção que não podem ser encurtadas posteriormente, com qualquer alteração na política de retenção exigindo duas pessoas.
- Separação de rede. Armazenamento de backup acessível apenas pelos servidores de backup, em uma rede de gerenciamento separada, sem acesso de entrada a partir das redes de usuários.
- Profundidade de retenção. Histórico suficiente para voltar a antes da infecção. Os atacantes costumam permanecer dentro de uma rede por semanas, então 30 a 90 dias é um mínimo realista para a camada imutável.
- Alertas de anomalias. Alertas para picos de dados alterados, conjuntos de backup excluídos e alterações de retenção, que muitas vezes são os primeiros sinais visíveis de um ataque.
Planeje a restauração pós-ransomware separadamente da restauração após falha de hardware. Depois de um ransomware, pode ser necessário restaurar em um ambiente isolado, analisar os dados, encontrar o último ponto íntegro conhecido e recriar credenciais antes de reconectar qualquer coisa.
Consistência de banco de dados: o ponto em que backups de arquivos falham
Copiar os arquivos de um banco de dados em execução normalmente produz um backup que parece completo e falha na restauração, porque as páginas foram capturadas em momentos diferentes. Use métodos que o banco de dados entende.
- Ferramentas nativas ou de backup a quente. Use o método de backup online suportado pelo engine do banco de dados ou um agente de backup integrado a ele, para que a cópia seja transacionalmente consistente.
- Log shipping para RPO curto. Combine backups completos periódicos com arquivamento contínuo dos logs de transação. Isso permite recuperação point-in-time, inclusive voltar a um momento imediatamente anterior a um deploy ruim ou a uma alteração maliciosa.
- Snapshots consistentes com a aplicação. Se você depende de snapshots de armazenamento ou de VM, coloque o banco de dados em quiesce ou congele-o antes (ou use a integração de snapshot do próprio engine) para que o snapshot capture um estado consistente.
- Replicação não é backup. Uma réplica copia fielmente exclusões, corrupção e atualizações erradas em questão de segundos. Mantenha-a para disponibilidade e RTO curto, e mantenha backups separados para garantir a recuperabilidade.
Meça o tempo de restauração do banco de dados, não apenas o tempo de backup. Uma restauração frequentemente inclui reaplicar horas de logs e reconstruir índices, o que pode levar várias vezes mais do que o backup. Se um banco de dados de 4 TB tem RTO de 2 horas, confirme se uma restauração consegue cumpri-lo ou se você também precisa de uma réplica standby.
Um link de 1 Gbps em plena carga transfere cerca de 125 MB por segundo, ou aproximadamente 10 TB por dia. Na prática, o overhead de protocolo, a reidratação da deduplicação e a velocidade de leitura do armazenamento costumam limitar a taxa sustentada a 50 a 80 por cento da velocidade nominal do link.
- Exemplo. Restaurar 20 TB por um link de 1 Gbps com 70 por cento de eficiência leva cerca de 2,9 dias. Com 10 Gbps, leva cerca de 7 horas, se o armazenamento nas duas pontas acompanhar.
- Cópia local primeiro. Uma camada de backup local próxima à produção atende rapidamente a maioria das restaurações; as camadas offsite e imutável atendem desastres e ataques.
- Restaure primeiro o subconjunto crítico. Projete de forma que os dados Tier 1 possam ser restaurados primeiro e de forma independente, em vez de esperar pelo conjunto completo de dados.
Um cronograma de testes de restauração que comprova a recuperabilidade
Um backup que nunca foi restaurado é uma suposição. Ajuste o esforço de teste ao tier:
- Diariamente. Verificações automatizadas do status dos jobs e verificação automatizada da integridade dos arquivos de backup, quando a plataforma suportar. Qualquer job com falha ou ignorado abre um chamado.
- Semanalmente. Restaure uma amostra aleatória de arquivos e pastas de sistemas diferentes e compare-os com checksums ou com a origem.
- Mensalmente. Restaure pelo menos um banco de dados Tier 1 em um ambiente isolado, execute uma verificação de consistência e confirme que a aplicação consegue lê-lo. Registre o tempo decorrido.
- Trimestralmente. Restaure uma stack completa de aplicação Tier 1, incluindo dependências, a partir da camada offsite ou imutável. Compare o tempo real de recuperação com o RTO.
- Anualmente. Realize um exercício completo de recuperação de desastres, incluindo um cenário de ransomware, com as pessoas que realmente estariam de plantão. Inclua o processo de decisão, não apenas as etapas técnicas.
Registre cada teste: data, sistema, cópia de origem, volume, tempo decorrido e problemas encontrados. Quando um teste excede o seu RTO, trate-o como um incidente, com responsável e prazo.
Runbooks que as pessoas conseguem seguir sob pressão
As recuperações geralmente são conduzidas por quem estiver disponível, em um horário inconveniente e sob pressão. Escreva os runbooks para essa pessoa: específicos, numerados e testados, com comandos, hostnames e saídas esperadas.
- Gatilho e autoridade. Quais condições iniciam a recuperação, quem pode declarar um desastre e quem precisa ser informado.
- Contatos. Responsáveis, fornecedores e provedores, com números de telefone que não dependam de o e-mail estar funcionando.
- Acesso. Como acessar a plataforma de backup e o ambiente de recuperação se o diretório principal, a VPN ou o gerenciador de senhas estiverem indisponíveis. Guarde as credenciais de emergência em um processo de break-glass lacrado e auditado.
- Ordem de recuperação. A sequência dos sistemas com base nas dependências: rede e DNS, identidade, bancos de dados e, depois, aplicações.
- Procedimentos passo a passo. Etapas exatas por sistema, com o tempo esperado para cada uma e como verificar o sucesso.
- Validação e devolução. Como o responsável pelo negócio confirma que o sistema está utilizável e que os dados estão suficientemente atualizados, e como as operações normais e os backups são retomados.
Guarde os runbooks em um lugar que sobreviva ao desastre que eles descrevem: uma cópia impressa, uma cópia criptografada offline e uma cópia fora do ambiente de produção.
Trade-offs de custo e como decidi-los
Cada redução no RPO ou no RTO custa dinheiro, e a curva é íngreme na ponta mais baixa. Passar de um RPO de 24 horas para 1 hora custa principalmente jobs mais frequentes e armazenamento de logs. Aproximar-se de zero normalmente significa replicação contínua e um ambiente standby, o que praticamente dobra a infraestrutura desses sistemas.
- Volume de armazenamento. A profundidade de retenção multiplica o armazenamento. Deduplicação e compressão ajudam bastante em backups de arquivos e de VMs, e menos em dados já comprimidos ou criptografados.
- Camada imutável. Retenção travada significa que você paga pelo período inteiro, mesmo por dados que gostaria de excluir antes. Dimensione-a de forma deliberada.
- Egress e transferência. Alguns serviços de armazenamento cobram pelos dados lidos ou transferidos para fora, o que torna restaurações grandes e testes frequentes mais caros. Inclua os custos de restauração na sua estimativa, não apenas o armazenamento.
- Computação standby. Um warm standby atende RTOs curtos, mas custa quase o mesmo que um segundo ambiente de produção. Uma arquitetura pilot light replica os dados e provisiona a computação durante a recuperação: mais barata, porém mais lenta.
- Pessoas e tempo de teste. Testes de restauração e manutenção dos runbooks consomem horas da equipe todos os meses. Inclua-as no orçamento, porque sem elas o restante do investimento não está comprovado.
Uma regra de decisão simples: para cada tier, compare a perda anual esperada com as metas atuais e o custo anual da arquitetura que atende metas mais rígidas. Se a melhoria custar menos do que a perda que ela evita, faça. Se não, documente o risco aceito e obtenha a aprovação formal do responsável pelo negócio.
Checklist de backup e recuperação
- Cada sistema: RPO, RTO, tier e responsável por escrito.
- Dependências mapeadas; a ordem de recuperação as segue.
- Três cópias por sistema no escopo, em 2 ou mais sistemas de armazenamento independentes, uma fora do local.
- Ao menos uma cópia imutável ou offline, retenção de 30 dias ou mais para dados críticos.
- Administração de backups com contas separadas e MFA. Mudanças de retenção exigem duas pessoas.
- Backups em rede isolada, inacessível a partir das redes de usuários.
- Backups de bancos de dados consistentes e compatíveis com o engine, com arquivamento de logs onde o RPO é inferior a algumas horas.
- Throughput de restauração medido; a maior restauração Tier 1 cabe no RTO.
- Agendados e registrados: verificação diária dos jobs, restaurações semanais de arquivos, mensais de bancos de dados, trimestrais de aplicações e exercício completo anual.
- Runbooks numerados, testados, offline e revisados após testes ou grandes mudanças.
- Alertas: jobs com falha, backups excluídos, mudanças de retenção, picos de alteração de dados.
- Custos: armazenamento, transferência, computação standby, tempo da equipe. Os responsáveis aprovam os riscos aceitos.
Próximos passos
Comece preenchendo RPO, RTO e responsável para os seus dez sistemas mais importantes e depois faça uma restauração cronometrada do maior deles.
Se você está criando ou migrando destinos de backup, a Vonahost oferece servidores dedicados com NVMe local ou armazenamento em bloco em rede de até 1 PB na região que você escolher, e sua nuvem gerenciada inclui backups. Cada proposta informa configuração, localização, responsabilidades e preço mensal em dólares americanos, deixando claro quais partes do plano de recuperação ficam sob sua operação e quais ficam com o provedor.