Resposta direta
Backup é uma cópia de dados ou sistemas. Recuperação é a capacidade de restaurar essa cópia e devolver o serviço a uma condição utilizável. Disaster recovery coordena tecnologia, pessoas, acessos, infraestrutura e fornecedores para recuperar serviços após uma interrupção relevante. Continuidade de negócios é mais ampla: mantém processos críticos dentro de limites aceitáveis, inclusive por procedimentos alternativos enquanto a tecnologia não volta.
A empresa precisa do nível de continuidade compatível com o impacto de cada processo, não da solução mais sofisticada disponível. O critério é quanto dado pode ser perdido, por quanto tempo a operação pode ficar indisponível e qual capacidade de recuperação foi comprovada em teste. Sem essas respostas, um painel de backup concluído informa que uma cópia foi criada, mas não demonstra que faturamento, produção, atendimento ou acesso a documentos voltarão no prazo necessário.
Backup, recuperação, disaster recovery e continuidade não são sinônimos
| Camada | O que entrega | O que não prova sozinha |
|---|---|---|
| Backup | Cópias de dados, configurações, imagens ou aplicações em pontos definidos no tempo. | Que a cópia está íntegra, isolada do incidente, completa e restaurável dentro do prazo necessário. |
| Recuperação | Restauração de dados e sistemas em ambiente adequado, com validação técnica e funcional. | Que todos os serviços dependentes voltarão ou que o processo de negócio conseguirá operar. |
| Disaster recovery | Estratégia para recuperar serviços de tecnologia após falha grave, perda de ambiente ou desastre. | Que pessoas, comunicação, fornecedores e procedimentos alternativos sustentam o negócio durante a interrupção. |
| Continuidade de negócios | Coordenação de processos, pessoas, instalações, tecnologia, terceiros e comunicação para manter atividades críticas. | Disponibilidade permanente ou ausência de impacto. Continuidade também envolve operar de forma degradada e priorizar o que volta primeiro. |
RPO e RTO traduzem tolerância de negócio em requisito técnico
O Recovery Point Objective (RPO) define o ponto no tempo ao qual os dados precisam voltar depois de uma interrupção. Na prática, ele representa a perda de dados tolerável. Se o RPO aprovado for de uma hora, a arquitetura precisa criar e preservar pontos de recuperação em intervalo compatível. Uma cópia diária não atende esse requisito, ainda que termine sem erros.
O Recovery Time Objective (RTO) define o limite de tempo para recuperar o serviço antes que a interrupção cause impacto inaceitável. Ele não é sinônimo de tempo de restauração do arquivo. Inclui detecção, decisão de acionar o plano, mobilização, acesso às cópias, reconstrução do ambiente, restauração, validação, liberação e eventual retorno das integrações.
RPO e RTO não devem ser escolhidos pela capacidade anunciada de uma ferramenta. Partem de uma análise de impacto: perda financeira, interrupção operacional, obrigação contratual ou regulatória, risco à segurança, efeito sobre clientes e dependências entre processos. Depois, são confrontados com custo, complexidade e capacidade técnica. Quanto menores os objetivos, maior tende a ser a necessidade de automação, replicação, infraestrutura disponível e testes frequentes.
O cenário de falha muda a resposta necessária
| Cenário | O backup pode ajudar | Capacidades adicionais |
|---|---|---|
| Exclusão ou corrupção de dados | Recupera uma versão anterior quando o item correto está no escopo e dentro da retenção. | Catálogo confiável, granularidade, permissões, validação funcional e procedimento de restauração. |
| Ransomware ou comprometimento de credenciais | Fornece um ponto limpo quando cópias e credenciais de backup não foram alcançadas pelo ataque. | Isolamento, imutabilidade ou cópia offline, credenciais separadas, investigação e reconstrução segura antes da restauração. |
| Falha de servidor ou storage | Preserva dados e, conforme a estratégia, imagens e configurações do sistema. | Hardware ou capacidade alternativa, compatibilidade, rede, sistema operacional, licenças e sequência de reconstrução. |
| Indisponibilidade do local | Permite recuperar dados em outro ambiente quando as cópias não dependem do mesmo local. | Site ou cloud de recuperação, conectividade, identidade, segurança, estações de trabalho e condições para a equipe operar. |
| Falha de conta, região ou provedor de cloud | Ajuda se a cópia estiver fora do mesmo domínio de falha e puder ser acessada sem a conta comprometida. | Arquitetura de recuperação, credenciais independentes, infraestrutura reproduzível, limites de serviço, DNS, chaves e testes entre ambientes. |
| Indisponibilidade de pessoas ou fornecedor | Preserva informação, mas não substitui conhecimento, autorização ou capacidade operacional. | Runbook, suplência, contatos, acessos de emergência, contratos, escalonamento e autoridade para acionar o plano. |
Por que um backup concluído pode falhar na hora necessária
O indicador de sucesso normalmente confirma a execução de uma tarefa, dentro do escopo que foi configurado. Ele não identifica, por si só, um banco novo fora da política, uma chave de criptografia inacessível, credenciais comprometidas, arquivos corrompidos antes da cópia ou uma aplicação que depende de componentes não documentados.
A capacidade de recuperação depende do conjunto. É preciso saber quais dados e sistemas estão protegidos, onde as cópias residem, quem administra as credenciais, como a integridade é verificada, qual ambiente receberá a restauração e quais dependências precisam voltar antes. Também entram no tempo real o volume de dados, a largura de banda, o desempenho do storage, a disponibilidade de licenças e a validação por quem conhece o processo de negócio.
Para ransomware, a CISA recomenda manter backups offline e criptografados de dados críticos e testar regularmente sua disponibilidade e integridade em um cenário de disaster recovery. O isolamento importa porque variantes de ransomware procuram apagar ou criptografar cópias acessíveis. Imutabilidade ajuda, mas não compensa configuração incorreta, credenciais compartilhadas ou ausência de teste.
Teste de restauração e exercício de continuidade verificam coisas diferentes
Testar não exige interromper a produção sem controle. Pode começar por amostras, ambiente segregado, simulações de mesa e exercícios técnicos programados. O nível do teste deve acompanhar a criticidade. O erro é usar um teste parcial como prova de uma capacidade que ele não avaliou.
| Teste | Pergunta respondida | Evidência mínima |
|---|---|---|
| Restauração de arquivo ou conjunto de dados | A cópia selecionada pode ser lida e devolvida com integridade? | Item recuperado, tempo registrado, validação de conteúdo e tratamento de falhas. |
| Recuperação de aplicação | Dados, sistema, configuração e integrações voltam juntos em condição utilizável? | Sequência executada, dependências validadas, teste funcional e tempo total comparado ao RTO. |
| Exercício de disaster recovery | A equipe consegue acionar o plano e recuperar o ambiente em um cenário relevante? | Critério de acionamento, decisões, responsáveis, comunicação, tempos, desvios e plano de correção. |
| Exercício de continuidade | O processo crítico consegue operar durante a indisponibilidade e a recuperação? | Procedimentos alternativos, capacidade degradada, prioridades, comunicação e impacto residual aceito pelo negócio. |
Como definir um nível de continuidade proporcional
1. Comece pelos processos críticos
Liste os processos cuja interrupção produz impacto material e identifique sistemas, dados, pessoas, fornecedores, instalações e integrações dos quais dependem. Faturamento, produção, atendimento e colaboração podem exigir respostas diferentes.
2. Defina tolerâncias com o negócio
Registre a perda de dados aceitável, o tempo máximo de indisponibilidade e a capacidade mínima para operar de forma degradada. A decisão deve ter responsável executivo, porque reduzir RPO e RTO consome orçamento e muda a arquitetura.
3. Meça a capacidade atual
Compare a meta com frequência das cópias, retenção, isolamento, tempo observado de restauração, disponibilidade do ambiente alternativo, dependências e conhecimento da equipe. Trate ausência de evidência como incerteza, não como conformidade.
4. Escolha a estratégia por criticidade
Serviços menos críticos podem aceitar restauração a partir de backup em horas ou dias. Serviços essenciais podem exigir infraestrutura previamente preparada, replicação, automação e recuperação em outro local ou região. Um único padrão para todos aumenta custo sem necessidade ou deixa processos críticos expostos.
5. Documente, teste e corrija
O runbook precisa indicar critérios de acionamento, ordem de recuperação, acessos, contatos, responsáveis, validação e retorno à operação normal. Cada exercício deve gerar tempos observados, falhas, decisões e responsáveis pela correção.
Responsabilidade não pode ficar implícita
A tecnologia executa parte relevante da recuperação, mas não pode decidir sozinha a prioridade dos processos nem o impacto aceitável. A direção aprova tolerâncias e investimento; responsáveis de negócio validam o que precisa voltar e em qual ordem; TI mantém arquitetura, cópias, acessos e procedimentos; segurança participa quando há comprometimento; fornecedores precisam ter escopo, contatos e limites definidos.
Terceirizar backup ou cloud não transfere integralmente a responsabilidade. O contrato precisa esclarecer o que é protegido, retenção, tempos, testes, suporte durante incidentes, acesso às cópias, portabilidade, exclusões e responsabilidades compartilhadas. Um SLA de atendimento também não equivale a RTO: iniciar o tratamento em quinze minutos não significa recuperar o serviço nesse período.
Perguntas executivas para avaliar prontidão
- Quais processos param se este sistema ficar indisponível e qual é o impacto por período de interrupção?
- Qual RPO e qual RTO foram aprovados para cada serviço crítico, por quem e com base em qual impacto?
- O último teste recuperou uma aplicação utilizável ou apenas alguns arquivos? Quanto tempo levou do acionamento à validação?
- As cópias permanecem acessíveis se o ambiente principal, a conta administrativa ou o fornecedor estiverem indisponíveis ou comprometidos?
- Identidade, chaves, rede, DNS, licenças, integrações e documentação também podem ser recuperados?
- Quem pode acionar o plano, quem executa cada etapa e quem valida que o processo voltou a operar?
- Qual capacidade mínima pode ser mantida durante a recuperação e por quanto tempo?
- Quais lacunas do último exercício continuam abertas, com responsável e prazo?
O próximo passo deve reduzir incerteza
Empresas com ambiente simples podem começar por escopo de backup, cópia isolada, teste periódico de restauração e responsabilidades documentadas. Quando a operação depende de vários sistemas, integrações ou cloud, é necessário mapear dependências, classificar serviços, comparar RPO/RTO com a capacidade observada e definir uma estratégia de recuperação por prioridade.
A frente de Infraestrutura de TI da G2C cobre backup, recuperação e continuidade na base tecnológica. A frente de Cloud trata arquitetura, replicação e recuperação em ambientes de nuvem e híbridos. Quando ainda não existe uma visão confiável de criticidade, dependências e lacunas, o Diagnóstico Executivo organiza a decisão e prioriza o que precisa ser testado ou corrigido primeiro.
Para uma avaliação mais ampla de controles, responsabilidades e evidências operacionais, veja também como avaliar se a TI da empresa está madura.
Fontes consultadas
- NIST SP 800-34 Rev. 1: Planejamento de contingência, análise de impacto, requisitos, estratégias de recuperação, testes e manutenção.
- NIST Glossary: Recovery Point Objective: Definição oficial do ponto no tempo ao qual os dados precisam ser recuperados após uma interrupção.
- NIST Glossary: Recovery Time Objective: Definição oficial do limite de tempo de recuperação antes de impacto negativo sobre a missão ou os processos.
- CISA: #StopRansomware Guide: Recomendação de backups offline e criptografados, testes regulares e preparação para resposta a ransomware.
- AWS Well-Architected: Plan for Disaster Recovery: RPO e RTO orientados pelo negócio, estratégia de recuperação, testes, automação e distinção entre disponibilidade e DR.
Quer aplicar isso na sua empresa?
O Diagnóstico Executivo de TI da G2C traduz o cenário atual em prioridades claras, sem compromisso comercial.