Backup, continuidade e recuperação para startups: do 3-2-1 ao plano de continuidade enxuto

Por que continuidade é decisão de arquitetura em startup

Em uma startup ou fintech, dados são o produto: cadastros de clientes, ledgers de transações, modelos, integrações com adquirentes e bancos. A perda ou indisponibilidade desses dados não é um incidente de TI isolado, é uma interrupção direta de receita e, em ambiente regulado, um problema de conformidade e de confiança com parceiros.

O erro comum é tratar backup como tarefa de infraestrutura delegada ao provedor de nuvem. Snapshots automáticos e replicação entre zonas protegem contra falha de hardware, mas não contra exclusão acidental, corrupção lógica, comprometimento de credenciais ou ransomware que cifra justamente os volumes e seus snapshots. Resiliência exige decisões deliberadas sobre onde, como e com que isolamento as cópias vivem.

O NIST SP 800-34 (Contingency Planning) e a ISO 22301 (Business Continuity) organizam esse raciocínio em torno de uma análise de impacto: identificar os processos críticos, o quanto a empresa tolera ficar sem eles e quanto dado pode perder. Para uma startup, isso não precisa virar um projeto de meses; precisa virar um documento de uma página que orienta as próximas escolhas de arquitetura.

A regra 3-2-1 e suas variações modernas

A base reconhecida (presente nos CIS Controls, controle de Data Recovery) é o 3-2-1: manter três cópias dos dados, em dois tipos de mídia ou tecnologia distintos, com pelo menos uma cópia fora do ambiente principal. A produção conta como uma cópia; isso significa pelo menos dois backups adicionais, e nunca todos no mesmo provedor, mesma conta ou mesma região.

As variações 3-2-1-1-0 endurecem a regra para a era do ransomware: o primeiro '1' extra exige uma cópia imutável ou offline (air-gapped), e o '0' exige zero erros na verificação do backup. Para uma startup em nuvem, isso se traduz em usar object lock no storage de objetos, uma conta ou tenant separado para os backups e checagem automática de integridade após cada job.

Separe também o plano de identidade: se a mesma credencial que administra a produção também pode apagar ou alterar os backups, você tem uma cópia, não um backup. Use contas dedicadas, com permissões mínimas e MFA, e mantenha as cópias de retenção longa fora do alcance operacional do dia a dia.

Se durante esse desenho você perceber que não tem quem monitore tentativas de acesso indevido aos backups ou quem responda quando o alerta dispara, esse é exatamente o tipo de lacuna que a Decripte cobre. Nosso monitoramento contínuo e a resposta a incidentes funcionam como time externo de segurança para startups que ainda não têm um SOC próprio, e há um plano gratuito para começar a ter visibilidade antes de precisar dela em uma crise.

RTO e RPO: medindo o que a continuidade significa

RTO (Recovery Time Objective) é quanto tempo um sistema pode ficar indisponível antes que o impacto se torne inaceitável. RPO (Recovery Point Objective) é quanto dado, medido em tempo, a empresa aceita perder, ou seja, a distância máxima entre o último backup válido e o momento da falha. Esses dois números, definidos por sistema, são o que separa continuidade planejada de improviso.

Os valores não são uniformes. O ledger de transações de uma fintech pode exigir RPO de minutos e RTO de poucas horas, justificando replicação contínua e backups frequentes. Já um data warehouse analítico pode tolerar RPO de 24 horas e RTO de um dia inteiro. Definir tudo no patamar mais agressivo é caro e desnecessário; definir tudo no mais frouxo é arriscado.

O RPO governa diretamente a frequência dos backups: se o RPO é uma hora, backups diários não atendem. O RTO governa a arquitetura de recuperação: metas curtas pedem ambientes em pré-aquecido ou infraestrutura como código pronta para recriar tudo rapidamente. Documente esses alvos junto a cada sistema crítico e revise quando a arquitetura mudar.

Backups imutáveis e offline contra ransomware

Ransomware moderno mira os backups antes de cifrar a produção, porque um backup intacto neutraliza a extorsão. Por isso a propriedade decisiva de uma cópia não é a frequência, é a impossibilidade de ser alterada por quem comprometeu o ambiente. Imutabilidade e isolamento são o que mantém uma cópia confiável durante um ataque.

Imutabilidade WORM (write once, read many) em storage de objetos, via object lock em modo de conformidade, impede que mesmo um administrador comprometido exclua ou sobrescreva os dados durante o período de retenção. É o mecanismo mais prático para startups em nuvem, pois não exige hardware dedicado e se integra a pipelines existentes.

Isolamento offline ou air-gapped, lógico ou físico, complementa a imutabilidade: uma cópia que só é acessível por um canal separado, com credenciais distintas, e que fica desconectada da rede operacional na maior parte do tempo. Combine retenção longa imutável com cópias offline periódicas para os dados mais críticos, e mantenha pelo menos um conjunto de backups fora da nuvem ou da conta onde roda a produção.

Teste de restore: o backup que ninguém restaurou não existe

A falha mais cara em continuidade não é não ter backup, é descobrir na hora do incidente que o backup está corrompido, incompleto ou que ninguém sabe restaurá-lo dentro do RTO prometido. O NIST SP 800-34 trata o teste do plano como parte indissociável dele; um backup nunca restaurado é uma hipótese, não uma garantia.

Teste o restore com regularidade e em ambiente isolado, não em produção. Restaure um banco completo, suba a aplicação contra ele, valide integridade referencial e cronometre o processo de ponta a ponta. O tempo medido é seu RTO real; se ele excede o alvo, ajuste a arquitetura ou a meta antes que a realidade ajuste por você.

Documente cada teste: o que foi restaurado, quanto tempo levou, o que falhou e o que mudou desde então. Essa trilha vira evidência de conformidade e, mais importante, o roteiro que a equipe seguirá sob pressão. Inclua cenários adversos no teste, como restaurar a partir da cópia imutável presumindo que a conta de produção está comprometida.

Plano de continuidade (BCP/DRP) enxuto para quem tem pouca gente

BCP (Business Continuity Plan) descreve como o negócio continua operando durante uma interrupção; DRP (Disaster Recovery Plan) detalha como a tecnologia volta a funcionar. Para uma startup, ambos devem ser curtos e executáveis: poucas páginas que respondem quem decide, quem executa, em que ordem os sistemas voltam e a quem comunicar, incluindo clientes e reguladores quando aplicável.

Estruture em torno de cenários concretos, não de teoria: perda da região de nuvem principal, comprometimento de credenciais, exclusão acidental de banco, ransomware. Para cada um, registre os passos de recuperação, o RTO/RPO alvo, os responsáveis e os contatos de escalonamento, incluindo o parceiro externo de resposta a incidentes. Mantenha uma cópia do plano fora dos sistemas que ele protege.

A ISO 22301 trata continuidade como ciclo: planejar, exercitar, revisar e melhorar. Para uma startup, isso significa revisar o plano a cada mudança relevante de arquitetura e exercitá-lo ao menos com uma simulação de mesa por período. Um plano enxuto que é lido, testado e atualizado supera, em todo cenário real, o manual extenso que ninguém abriu desde a auditoria.

Checklist prático

1. 1

   1. Inventarie dados e defina criticidade

   Liste os sistemas e conjuntos de dados, marque os críticos para receita e conformidade e registre onde vivem. Sem inventário, qualquer estratégia de backup tem pontos cegos.

2. 2

   2. Defina RTO e RPO por sistema

   Para cada sistema crítico, determine o tempo máximo de indisponibilidade tolerável (RTO) e a perda máxima de dados aceitável (RPO). Esses números orientam frequência de backup e arquitetura de recuperação.

3. 3

   3. Implemente o 3-2-1 com isolamento

   Garanta três cópias, duas mídias, uma externa, sempre em conta ou provedor separado da produção e com credenciais dedicadas e MFA para acessar os backups.

4. 4

   4. Adicione uma cópia imutável ou offline

   Ative object lock WORM no storage de backup e mantenha ao menos uma cópia air-gapped dos dados mais críticos, fora do alcance das credenciais operacionais.

5. 5

   5. Automatize verificação de integridade

   Configure checagem automática após cada job de backup e alertas para falhas. Um backup que falha silenciosamente é pior que nenhum, porque cria falsa segurança.

6. 6

   6. Teste e cronometre o restore

   Restaure periodicamente em ambiente isolado, valide a integridade e meça o tempo total. Compare com o RTO alvo e ajuste arquitetura ou meta conforme o resultado real.

7. 7

   7. Documente e exercite o BCP/DRP

   Escreva um plano curto com papéis, ordem de recuperação e contatos de escalonamento, guarde uma cópia fora dos sistemas que ele protege e exercite-o com simulações periódicas.

Perguntas frequentes