Backup e continuidade de operação: qual a diferença

Backup e continuidade de operação são tratados como sinônimos na maioria das empresas de pequeno e médio porte, e a confusão custa caro exatamente uma vez — no dia em que alguma coisa para. A rotina de cópia roda, o relatório chega verde, o assunto some da reunião de diretoria. Aí um servidor corrompe, um sistema é comprometido ou um equipamento não liga mais, e a empresa descobre que ter o dado guardado é bem diferente de conseguir trabalhar.

A distinção cabe em duas perguntas. O backup responde a uma: o dado ainda existe em algum lugar? A continuidade responde a outra, muito maior: a empresa consegue continuar entregando o que precisa entregar? Entre as duas há uma cadeia de elos que ninguém costuma montar antes da crise — e é a ausência deles, não a da cópia, que transforma uma parada de horas em uma parada de dias.

Este texto trata desse intervalo: o que a cópia entrega, o que fica de fora dela sem ninguém perceber, quais etapas separam restaurar um arquivo de voltar a operar, por que continuidade não é assunto exclusivo da TI, como escrever o compromisso de tempo que quase nenhuma empresa escreve e como testar se o seu backup sustenta esse compromisso.

O que o backup entrega — e o que ele não entrega

Backup é uma cópia de dado feita para um único propósito: recuperar informação perdida, corrompida, apagada por engano ou tornada inacessível. Ele é indispensável e resolve bem um conjunto específico de problemas. A planilha que alguém salvou por cima, a pasta apagada sem querer, a base inconsistente depois de uma atualização mal-sucedida, o arquivo criptografado por um ataque — todos têm no backup a resposta certa.

O que ele não faz é igualmente objetivo. O backup não decide o que precisa voltar primeiro, não sabe onde restaurar se o equipamento original não existe mais, não guarda o conhecimento de como subir o sistema, não avisa ninguém e não autoriza nada. Não substitui o link que caiu, a energia que faltou, a licença presa ao servidor queimado nem a pessoa que sabia executar o procedimento e está de férias.

A frase que resume o problema é simples: backup é um recurso, continuidade é uma capacidade. Recurso se contrata; capacidade se constrói, se documenta e se testa. Uma empresa pode ter um serviço de cópia excelente e nenhuma capacidade de retomada — e é esse cenário, não o da empresa sem backup, o mais comum hoje.

Vale medir o tamanho da diferença antes de discutir investimento. Quando a operação para, a conta corre em vários lugares ao mesmo tempo: faturamento que não sai, prazo externo que não espera, equipe ociosa, cliente sem resposta e retrabalho depois. Entender quanto custa uma hora de TI parada na sua empresa tira a continuidade da categoria de despesa opcional.

O que não está dentro da sua cópia

A maior parte das recuperações que dão errado não falha por causa do dado, e sim do que ficou fora da cópia sem ninguém inventariar. Percorra esta lista e verifique onde cada item está guardado na sua empresa:

• A configuração do ambiente. Regras de rede, permissões, ajustes de servidor, parâmetros do sistema de gestão. Restaurar o dado em ambiente cru devolve informação sem contexto, e reconstruir configuração na crise consome mais tempo que a restauração em si.
• As credenciais necessárias para começar. Senha de administrador, chave do console do provedor, segundo fator vinculado ao celular de uma pessoa só. Quando a credencial mora dentro do sistema que caiu, a recuperação começa por um impasse.
• As licenças e ativações. Software vinculado ao equipamento original, ativação que exige contato com o fabricante, certificado digital instalado em uma máquina. Nada disso vem junto no arquivo de cópia.
• As integrações, os certificados e as chaves. A conexão entre o sistema de gestão e o site, a rotina que joga dado para a contabilidade, o serviço que emite documento fiscal. Cada uma tem endereço, credencial e configuração próprios, quase sempre não documentados — e o que garante que um serviço confie no outro costuma estar onde a rotina de cópia nunca olhou.
• O ambiente onde restaurar. Se o equipamento morreu, o dado precisa ir para algum lugar. Ter destino disponível, com capacidade suficiente, é decisão que se toma antes.
• O procedimento escrito de retomada. A sequência do que subir e como. Quando existe só na cabeça de alguém, não é procedimento.
• As pessoas e os contatos externos. Quem executa, quem autoriza, quem comunica — e o fornecedor do sistema, o provedor de link, o suporte do fabricante. Sem canal e sem contrato, você depende da fila comum no pior dia.

Nenhum desses itens é caro de resolver antes; todos são caríssimos de resolver durante. E repare no padrão: a maioria não é dado, é conhecimento, acesso e decisão. Por isso comprar mais armazenamento não aumenta a continuidade da empresa em nada.

A distância entre restaurar e voltar a operar

Restaurar é uma tarefa técnica com fim definido. Voltar a operar é um estado do negócio. Entre um e outro existe uma cadeia, e ela só é tão forte quanto o elo mais fraco:

Primeiro, a cópia precisa existir e estar íntegra. Rotina concluída com sucesso significa que o processo rodou, não que o conteúdo abre. Base copiada com o sistema em uso pode voltar inconsistente e simplesmente não subir.

Segundo, a cópia precisa estar acessível. Se ela está no mesmo ambiente e sob a mesma credencial do original, o evento que atingiu um atinge o outro — e isso vale em dobro quando a causa é um ataque, porque quem entra procura justamente a cópia antes de agir.

Terceiro, precisa existir destino. Máquina, servidor, ambiente em nuvem, capacidade contratada. Sem destino, a restauração fica esperando uma compra ou uma liberação.

Quarto, alguém precisa ter acesso e autorização. Credencial disponível fora do ambiente afetado e alguém com autoridade para mandar restaurar. Equipe parada esperando aprovação é a forma mais silenciosa de perder a janela.

Quinto, o sistema precisa subir. Aplicação, banco, serviços dependentes, integrações reconectadas, certificados no lugar. Dado restaurado não é sistema funcionando.

Sexto, alguém precisa validar que está certo, e essa validação é de quem usa o sistema. O técnico confirma que o serviço respondeu; só a área confirma que o último lançamento está lá e que os números batem.

Sétimo, a operação precisa retomar. Acesso devolvido, fila acumulada redistribuída, cliente informado, o que foi feito no papel digitado de volta. Essa etapa quase nunca entra na conta e costuma ser a mais longa.

Colocar essa cadeia no papel muda a conversa: em vez de “temos backup?”, ela vira “qual desses elos está frouxo hoje?”. Como mostra o que a infraestrutura de TI faz e por que a empresa para quando ela falha, o efeito de uma falha nunca fica contido no departamento técnico — e a cadeia acima é o mapa de onde ele se espalha.

Continuidade não é assunto exclusivo da TI

Um erro estrutural comum é entregar a continuidade inteira para a TI e cobrar dela um resultado que ela não controla sozinha. Sistema é um componente da operação, não o único. Continuidade responde também por:

• As pessoas. Se a equipe não consegue trabalhar, tanto faz o servidor estar de pé. Onde elas trabalham se o escritório estiver inacessível? Como se comunicam se o canal de sempre for o que está fora?
• O modo manual. Que parte do trabalho a empresa toca no papel, quem autoriza entrar nesse modo e por quanto tempo ele se sustenta antes de virar retrabalho.
• A comunicação. Cliente, fornecedor e equipe precisam saber o que está acontecendo e o que muda para eles. Silêncio durante a parada gera mais dano à confiança que a própria parada.
• Os terceiros dos quais você depende. Provedor de link, fornecedor do sistema, plataforma de emissão fiscal, banco. A parada deles é parada sua, e você precisa saber de antemão a que atendimento tem direito.
• As obrigações com prazo externo. Entrega fiscal, contábil ou contratual não negocia com incidente interno, e precisa estar na lista de prioridades desde o começo.
• A ordem de retorno das pessoas ao trabalho. Devolver acesso a todo mundo de uma vez em ambiente recém-restaurado costuma derrubar de novo o que acabou de subir.

Mapear essas dependências fora da TI é o que separa um plano técnico de um plano de operação — o mesmo raciocínio da avaliação dos riscos de TI que podem parar a sua empresa: risco só vira decisão quando alguém descreve o efeito dele no negócio, e não apenas no equipamento.

O compromisso que quase nenhuma empresa escreve

Aqui está o item que torna a discussão verificável, e ele não exige ferramenta nenhuma. Defina por escrito quanto tempo cada sistema pode ficar parado sem quebrar a operação. Não é o tempo que a TI acha que consegue entregar — é o que a área suporta sem que o dano vire irreversível. Faturamento, emissão fiscal, sistema de gestão, e-mail, telefonia, arquivos, site: cada um tem a sua tolerância, e adotar a mesma para tudo é o atalho que estoura o orçamento e deixa desprotegido justamente o que importa.

Defina também quanto trabalho a empresa aceita refazer. Tudo o que foi produzido depois da última cópia íntegra precisa ser reconstruído a partir de outra fonte, quando isso é possível. Para cada base, escreva o que aconteceria se o trabalho do intervalo entre a última cópia e a falha simplesmente sumisse.

Depois, teste se o seu arranjo atual cumpre esses dois compromissos. É aqui que a maioria descobre a distância entre o que precisa e o que tem. Quando as respostas não batem, há uma decisão de negócio a tomar: investir para fechar a distância ou aceitar formalmente o risco, com quem responde pela empresa ciente e por escrito. O que não pode é a distância existir sem ninguém saber.

Três cuidados evitam que esse documento morra na gaveta. Ele precisa ser assinado por quem responde pelo negócio, porque é uma decisão de tolerância. Precisa ser revisado quando a operação muda, entra sistema novo ou um processo migra de área. E precisa ser curto: uma linha por sistema, com o tempo tolerado, o volume de trabalho que se aceita perder e quem valida a retomada.

Como testar se o seu backup sustenta a continuidade

Cópia que nunca foi restaurada é hipótese, não proteção. O teste que responde à pergunta certa tem quatro características, nenhuma delas sofisticada:

• Ele restaura de verdade, em ambiente separado. Conferir o relatório da rotina não é teste; abrir o conteúdo restaurado é.
• Ele é cronometrado do começo ao fim. Conte do momento em que a falha é declarada até a área confirmar que consegue trabalhar. É esse tempo, e não o da tarefa técnica, que você compara com o compromisso escrito.
• Ele é validado por quem usa o sistema. A pessoa da área confere se os últimos lançamentos estão lá e se os números fecham. Integridade se comprova no uso.
• Ele é executado por quem não escreveu o procedimento. Se só funciona nas mãos de quem redigiu, o que você tem é conhecimento pessoal — e conhecimento pessoal tira férias e pede demissão.

Cada teste precisa terminar em três registros: o tempo real de cada etapa, o que a documentação não previa e as pendências com responsável e prazo. Teste que não gera tarefa é encenação, e cada falha do ensaio é economia — falhar no teste custa muito menos que falhar na estreia.

Um ponto que costuma passar despercebido: quem opera o ambiente precisa ter esse teste na rotina, e não como evento heroico. É uma das razões para levar a sério as vantagens de manter a gestão do ambiente em nuvem sob método — ambiente gerenciado com rotina de verificação transforma a restauração em procedimento conhecido, não em improviso.

O que precisa estar escrito para a cópia virar continuidade

Três documentos curtos fazem quase todo o trabalho:

O compromisso de tolerância por sistema. Uma linha por sistema, com o tempo máximo de parada aceito, o volume de trabalho que se aceita refazer e quem valida a retomada. Assinado por quem responde pelo negócio.

O procedimento de retomada. A sequência do que sobe primeiro, onde restaurar, quais credenciais são necessárias e onde estão guardadas, quais integrações precisam ser reconectadas e quem executa cada frente. Guardado fora dos sistemas que podem cair, em formato que abra sem depender do ambiente afetado.

O registro dos testes. Data, cenário, tempo real de cada etapa, quem executou, o que falhou e o que virou tarefa. É o documento que prova que a sua continuidade é real, e é o que você leva para a diretoria e para o cliente que audita a sua operação.

Do fornecedor que cuida do seu backup, exija três respostas por escrito: o que exatamente está incluído na cópia e o que não está, com que frequência a restauração é testada e qual foi o resultado do último teste, e em quanto tempo ele entrega o ambiente restaurado a partir do acionamento. Descrição de recurso não responde a nenhuma das três.

Checklist: o seu backup sustenta a operação?

Marque apenas o que existe hoje de forma documentada e verificável:

• Existe lista do que está incluído na cópia e, principalmente, do que não está.
• Configurações, licenças, certificados, chaves e dados de integração estão preservados fora do ambiente de origem.
• As credenciais para iniciar a recuperação estão acessíveis mesmo com o ambiente principal fora do ar.
• Existe destino definido para restaurar caso o equipamento original não esteja disponível.
• As cópias estão separadas do ambiente de origem, com controle de acesso próprio.
• Cada sistema tem, por escrito, o tempo máximo de parada tolerado e o volume de trabalho que se aceita refazer.
• Esse compromisso foi aprovado por quem responde pelo negócio, e não só pela equipe técnica.
• A restauração já foi testada de verdade, com tempo cronometrado e conteúdo aberto e conferido.
• A validação do teste foi feita por quem usa o sistema, não apenas por quem restaurou.
• O procedimento de retomada está escrito e guardado fora dos sistemas que podem cair.
• As dependências fora da TI — pessoas, local, link, energia, fornecedores e prazos externos — estão mapeadas.
• Existe um modo de trabalho temporário definido, com quem autoriza entrar nele e por quanto tempo ele se sustenta.
• Cada teste gera pendências com responsável e prazo, acompanhadas até fechar.

Se a maior parte ficou sem marcação, a sua empresa tem backup e não tem continuidade — e só uma das duas mantém a operação de pé.

Próximo passo

A diferença entre backup e continuidade de operação não é técnica, é de escopo: a cópia protege a informação, a continuidade protege a capacidade de trabalhar. Quem confunde as duas descobre a distância no pior momento, quando cada elo frouxo cobra o próprio preço de uma vez só.

A OpTec IT trabalha com empresas que precisam sair da confiança na rotina de cópia e chegar a uma retomada testada, com ambiente, procedimento e responsáveis definidos. Se a sua operação depende de sistemas que não podem ficar parados, conheça a estruturação de infraestrutura de TI da OpTec IT e leve o checklist acima para a conversa. Descreva quanto tempo cada sistema pode ficar fora do ar e a nossa equipe verifica se o arranjo atual entrega isso.