Disaster recovery empresas: como não parar a operação

Disaster recovery em empresas de pequeno e médio porte quase sempre nasce torto. Alguém contrata uma ferramenta de backup, marca a caixinha do risco na reunião de diretoria e o assunto sai de pauta. Aí o servidor de arquivos corrompe numa terça-feira de fechamento: a cópia existe, mas ninguém sabe quem autoriza restaurar, o que precisa voltar primeiro, quanto tempo a restauração leva nem o que a operação faz enquanto espera. A empresa descobre no pior momento possível que tinha cópia e não tinha plano.

Este texto trata do que vem antes da ferramenta. Você vai ver como mapear os processos que realmente interrompem a operação, como transformar esse mapa em uma ordem de recuperação defensável, o que RTO e RPO significam e por que são decisão de negócio antes de serem decisão técnica, quem manda em quê durante o incidente, como testar o plano sem esperar o desastre e quais erros só aparecem no dia em que o plano é usado de verdade.

O recorte é de empresa com quadro enxuto, orçamento disputado e dependência total de sistemas que não podem ficar fora do ar. Nesse cenário, o plano não pode ser um calhamaço que ninguém lê: precisa ser curto, específico e testado. É isso que separa continuidade de improvisação bem-intencionada.

Backup e disaster recovery resolvem problemas diferentes

Backup é cópia de dado. Disaster recovery é a capacidade de voltar a operar. A confusão entre os dois é a causa raiz da maior parte das recuperações que dão errado, porque ela faz a empresa investir em armazenamento e não investir em procedimento.

A cópia responde a uma pergunta única: o dado ainda existe em algum lugar? O plano de recuperação responde a um conjunto muito maior. Onde esse dado vai ser restaurado, se o equipamento original não existe mais? Quem tem a credencial para subir o ambiente? Em que ordem os sistemas voltam, considerando que uns dependem dos outros? Quem avisa o cliente que o prazo combinado vai atrasar? O que a equipe faz manualmente enquanto o sistema não volta, e por quanto tempo esse contorno se sustenta?

Repare que a maioria dessas perguntas não é sobre dado. É sobre pessoa, sequência, decisão e comunicação. Uma empresa pode ter cópia íntegra de tudo e mesmo assim ficar parada por dias, porque ninguém definiu onde restaurar, porque a licença do sistema estava vinculada ao hardware que queimou ou porque a documentação do procedimento estava justamente no ambiente que caiu.

Vale reforçar o ponto: quando a infraestrutura de TI falha, a empresa inteira sente, e o efeito nunca fica contido no departamento técnico. Por isso o plano de recuperação é documento de negócio com apoio técnico, e não o contrário.

O que mapear antes de escolher qualquer ferramenta

O erro mais caro do disaster recovery em empresas é começar pela tecnologia. A conversa correta começa por uma pergunta desconfortável: se a empresa parasse agora, o que exatamente pararia junto?

Note que a pergunta não é sobre sistemas, e sim sobre processos. Sistema é meio; processo é o que gera receita, cumpre obrigação e mantém cliente. Liste as atividades que a empresa executa todo dia e, para cada uma, levante:

• Qual atividade de fato deixa de acontecer, quem para de trabalhar e quem percebe primeiro — o cliente, a equipe interna ou o fornecedor.
• Quais sistemas, bases de dados, arquivos e integrações essa atividade consome, incluindo os que não são oficiais.
• De que a atividade depende fora da TI: energia, link de internet, telefonia, acesso físico ao escritório, um serviço de terceiro.
• O que a área consegue fazer no modo manual e por quanto tempo esse contorno se sustenta antes de virar prejuízo ou erro.
• Qual dado dessa atividade não pode ser reconstruído a partir de outra fonte se for perdido.

O último item costuma ser o mais revelador. Boa parte do que a empresa acha crítico pode ser refeita a partir de outro sistema, de um e-mail ou de um documento assinado. Outra parte, bem menor, existe em um lugar só — e é aí que o plano precisa de mais cuidado.

Esse levantamento também expõe as dependências ocultas, que são as que mais atrapalham na hora da recuperação: a planilha de controle que mora na máquina de uma pessoa, a integração que ninguém documentou, o sistema legado que roda em um servidor que a empresa esqueceu que tinha, a conta de serviço cuja senha só uma pessoa conhece. O mesmo mapa alimenta a avaliação dos riscos de TI que podem parar a sua empresa e mostra onde a operação está apoiada em um ponto único de falha.

Sem esse mapa, qualquer prioridade que a empresa definir é palpite. Com ele, a conversa muda de “o que a TI acha importante” para “o que o negócio não consegue sustentar parado”.

Como definir a prioridade de recuperação

Prioridade não é ranking de importância declarada. Se você perguntar a cada área o que é crítico, tudo será crítico. A prioridade nasce de critérios comparáveis, aplicados igualmente a todos os processos mapeados.

Cinco critérios costumam bastar para ordenar a lista de uma PME:

1. Interrupção direta de receita. O processo parado impede faturar, vender, cobrar ou entregar? Quanto mais direto o vínculo com o caixa, mais alto ele sobe.
2. Obrigação com prazo externo. Existe entrega fiscal, contábil, regulatória ou contratual com data marcada que a parada compromete? Prazo externo não negocia com incidente interno.
3. Efeito cascata. Quantos outros processos travam quando esse trava? Serviços de base, como identidade e autenticação, rede e diretórios de acesso, quase sempre precisam voltar antes, porque sem eles nada mais faz sentido.
4. Risco a terceiros. A parada expõe dado de cliente, interrompe um serviço do qual outra empresa depende ou gera dano que não é só seu? Esse tipo de consequência não se recupera com restauração.
5. Reversibilidade manual. Existe contorno? Um processo que a equipe consegue tocar no papel por um período tem folga; um processo sem contorno nenhum precisa voltar primeiro, mesmo que pareça menos nobre.

Aplicados juntos, esses critérios produzem algo mais útil que uma lista de sistemas: produzem uma ordem de recuperação, que é a sequência em que as coisas voltam. E ordem importa porque restaurar na sequência errada desperdiça a janela mais valiosa do incidente. Não adianta subir o sistema de faturamento se ninguém consegue autenticar nele, nem restaurar a base sem o serviço que a alimenta.

Essa ordem precisa ser aprovada por quem responde pelo negócio, não apenas pela equipe técnica. Quando a diretoria assina a sequência com antecedência, ninguém precisa negociar prioridade no meio da crise — e essa é justamente a hora em que negociar sai mais caro.

RTO e RPO: os conceitos que organizam a decisão

Duas siglas aparecem em qualquer conversa séria sobre disaster recovery, e vale entendê-las como conceito antes de tratá-las como número.

RTO, ou Recovery Time Objective, é o tempo máximo que a empresa aceita ficar sem aquele processo. Ele começa a contar quando a falha acontece e termina quando a atividade volta a ser executável — não quando o técnico termina a tarefa dele. É uma medida de tolerância do negócio à ausência do serviço.

RPO, ou Recovery Point Objective, é o volume de trabalho que a empresa aceita perder. Ele mede a distância entre a última cópia íntegra e o momento da falha. Tudo o que foi produzido nesse intervalo precisa ser refeito, redigitado ou reconstruído a partir de outra fonte — quando isso é possível.

Três consequências práticas seguem daí, e elas valem para qualquer porte de empresa:

A primeira é que cada processo tem o seu próprio par. Adotar o mesmo objetivo para tudo é o atalho que estoura orçamento e, ao mesmo tempo, deixa desprotegido o que realmente importa. O sistema que sustenta o faturamento e o repositório de documentos antigos raramente merecem o mesmo tratamento.

A segunda é que quanto mais exigente o objetivo, mais cara e mais complexa a arquitetura necessária. Reduzir tolerância significa mais redundância, mais frequência de cópia, mais automação e mais teste. Isso é um trade-off legítimo, e precisa ser apresentado como tal a quem aprova o investimento.

A terceira é que esses valores são definidos pelo negócio e validados pela técnica, nesse sentido. A área diz quanto aguenta; a TI diz o que a arquitetura atual entrega e o que seria necessário para chegar ao que foi pedido. Quando as duas respostas não batem, a empresa tem uma decisão para tomar — investir para fechar a distância ou aceitar formalmente o risco. O que não pode acontecer é a distância existir sem ninguém saber.

Registre o par acordado para cada processo prioritário e revise periodicamente. Operação muda, sistema novo entra, processo migra de área — e a tolerância de ontem pode não valer mais.

Quem decide o quê durante o incidente

Plano de recuperação sem papéis definidos vira reunião de emergência com muita gente opinando e ninguém autorizando. Antes do incidente, defina por nome quem faz o quê.

• Quem declara o incidente. Alguém precisa ter autoridade para dizer “isso não é um chamado comum, é um evento de continuidade” e acionar o plano. Sem esse gatilho, a empresa perde tempo tratando um desastre como suporte de rotina.
• Quem coordena a resposta. Uma pessoa acompanha a execução, mantém o registro do que foi tentado e evita que dois técnicos mexam no mesmo ponto ao mesmo tempo. Coordenar não é executar.
• Quem executa cada frente técnica. Restauração, rede, acessos, contato com fornecedor de sistema. Nomes e suplentes, porque incidente não consulta a escala de férias.
• Quem decide operar em contorno manual. Essa é decisão de negócio: a área aceita registrar no papel e digitar depois, ou prefere esperar? Quem responde por isso precisa estar nomeado.
• Quem fala com o público externo. Cliente, fornecedor, parceiro e, quando for o caso, autoridade. Uma voz só, com mensagem alinhada.
• Quem declara o encerramento. O incidente acaba quando o negócio volta a operar de forma sustentável, não quando o serviço sobe. Alguém precisa dar essa palavra final e abrir a revisão pós-incidente.

Dois detalhes práticos fazem diferença. O primeiro é que a lista de contatos e o próprio plano precisam estar acessíveis fora dos sistemas que podem cair — se o procedimento mora no ambiente comprometido, ele não existe quando você mais precisa. O segundo é combinar um canal de comunicação alternativo, porque o meio de sempre pode ser exatamente o que está indisponível.

Quando a origem é segurança, a ordem natural muda: restaurar rápido pode significar restaurar o problema junto. Antes de retomar, é necessário entender o que aconteceu, e ajuda muito saber como identificar um incidente de segurança na sua empresa para não confundir falha operacional com ataque em curso.

Como testar o plano de disaster recovery em empresas

Plano não testado é hipótese. A única forma de saber se ele funciona é usá-lo em condições controladas, com regularidade, e tratar cada falha do teste como economia — porque falhar no ensaio custa infinitamente menos que falhar na estreia.

Existem níveis de teste, e eles se complementam:

• Revisão de mesa. A equipe lê o plano em conjunto e confere se contatos, sistemas, ordens e responsáveis continuam válidos. É o teste mais barato e o que mais captura desatualização.
• Simulação de cenário. Alguém descreve uma falha específica e o grupo percorre a resposta passo a passo, sem tocar em produção. Expõe lacunas de decisão e dependências que ninguém tinha lembrado.
• Restauração de amostra. Restaure um conjunto real de dados em ambiente separado e confira integridade, não apenas conclusão do processo. Arquivo que abre não é o mesmo que base consistente.
• Ensaio de retomada completa. Subir um serviço prioritário em ambiente alternativo, com janela agendada e critério de sucesso definido. É o teste mais trabalhoso e o único que valida a cadeia inteira.

Em todos eles, registre três coisas: se o objetivo foi alcançado, quanto tempo cada etapa levou de verdade e o que a documentação não previa. As pendências viram tarefas com dono e prazo — teste que não gera ação é teatro.

Um cuidado que costuma passar batido: teste com quem não escreveu o plano. Se o procedimento só funciona nas mãos de quem o redigiu, ele não é um procedimento, é conhecimento pessoal. E conhecimento pessoal tira férias, adoece e pede demissão.

Os erros que só aparecem no dia do problema

Alguns problemas ficam invisíveis enquanto tudo funciona. São estes que transformam uma parada previsível em uma crise longa, e são eles que separam um plano de disaster recovery que existe no papel de um que funciona na prática:

• A cópia roda todo dia, é registrada como concluída e nunca foi restaurada de fato. Rotina de backup verifica execução, não recuperabilidade.
• O arquivo do banco de dados foi copiado com o sistema em funcionamento, sem consistência, e a restauração devolve uma base que não sobe.
• A credencial necessária para iniciar a recuperação está guardada dentro do sistema que ficou indisponível.
• A documentação do procedimento mora no mesmo repositório que caiu.
• O software exige ativação ou vínculo com o equipamento original, e ninguém testou subir a aplicação em outro hardware.
• A recuperação depende de um fornecedor de sistema que não tem canal de atendimento contratado para urgência, e a empresa descobre isso no telefone.
• A cópia está no mesmo ambiente e sob a mesma credencial do original, de modo que o mesmo evento leva as duas — cenário especialmente cruel em incidente de segurança.
• Ninguém com autoridade para decidir está disponível, e a equipe técnica fica parada esperando aprovação para agir.
• O plano foi escrito por alguém que saiu da empresa e nunca foi revisado desde então.
• Existe plano para o servidor e não existe plano para a ausência das pessoas que sabem operá-lo.

Cada item dessa lista já foi, em algum lugar, a diferença entre uma retomada de algumas horas e uma parada que consumiu a semana. Nenhum deles é caro de corrigir antes; todos são caríssimos depois. Se a sua empresa ainda não organizou esse tipo de avaliação, entender como fazer o gerenciamento de riscos na prática é um bom ponto de partida.

Checklist para revisar o seu plano de recuperação

Antes da próxima reunião com a diretoria ou com o fornecedor, passe o plano de disaster recovery da sua empresa por estes pontos e marque apenas o que existe de fato, documentado e acessível — não o que deveria existir:

• Os processos críticos estão mapeados por atividade de negócio, com os sistemas e dados que cada um consome.
• Existe uma ordem de recuperação escrita, aprovada por quem responde pelo negócio.
• Cada processo prioritário tem tolerância de tempo e de perda de dados definida e registrada.
• As dependências externas — fornecedor de sistema, link, energia, serviços de terceiros — estão listadas com canal de acionamento.
• Os papéis do incidente estão nomeados, com suplentes, incluindo quem declara e quem encerra.
• O plano e a lista de contatos ficam acessíveis fora dos sistemas que podem cair.
• As cópias estão separadas do ambiente de origem, com controle de acesso próprio.
• A restauração é testada periodicamente, com registro de tempo real e de integridade verificada.
• Existe procedimento específico para o caso em que a causa é um incidente de segurança.
• Cada teste gera pendências com responsável e prazo, e elas são acompanhadas até fechar.
• O plano tem data de última revisão e um responsável nomeado por mantê-lo vivo.

Se a maioria dos itens ficou sem marcação, o problema não é falta de ferramenta. É ausência de método — e método se constrói antes, com calma, não durante a crise.

Próximo passo

Disaster recovery maduro não é o que promete evitar qualquer falha. É o que garante que a empresa sabe o que para, em que ordem volta, quem decide o quê e quanto tempo isso leva — porque já testou.

A OpTec IT trabalha com empresas que precisam sair da dependência de improvisação e organizar backup, ambiente e procedimento de retomada sob um mesmo método. Se a sua operação já está avaliando onde os dados críticos devem morar para tornar a recuperação viável, veja como estruturar o ambiente em nuvem da operação e leve o checklist acima para a conversa. Descreva os processos que não podem parar e a nossa equipe ajuda a definir o que precisa ser resolvido primeiro.