“Temos backup.”
Ótimo.
Mas quando foi a última vez que alguém tentou recuperar alguma coisa?
A pergunta parece provocação, mas existe uma diferença bastante importante entre ter uma cópia dos dados e possuir capacidade real de recuperação.
O backup pode executar todas as noites. O relatório pode chegar por e-mail. O painel pode ficar verde. Os arquivos podem estar na nuvem, em um disco externo, em outro servidor ou em todos eles ao mesmo tempo.
Ainda assim, no dia em que alguma coisa realmente acontecer, a pergunta continuará sendo a mesma:
Conseguimos voltar?
Backup concluído com sucesso. E agora?
Existe uma tranquilidade quase automática quando aparece aquela mensagem:
“Backup concluído com sucesso.”
Excelente.
Isso significa que determinada rotina conseguiu copiar aquilo que estava configurada para copiar.
Mas será que estava copiando tudo o que deveria? Os arquivos estão íntegros? O banco de dados pode ser restaurado? As configurações necessárias para o sistema voltar também estão protegidas? As credenciais estão disponíveis? Alguém sabe o procedimento?
E, talvez a pergunta mais desconfortável: quanto tempo levaria para colocar tudo novamente em funcionamento?
Perceba que já saímos da discussão sobre backup.
Agora estamos falando de recuperação.
O arquivo existe. Mas abre?
Pode parecer básico.
E é.
Mesmo assim, descobrir que uma cópia está corrompida justamente quando precisamos dela não é exatamente uma situação rara no universo da tecnologia.
Um backup pode falhar silenciosamente. Pode copiar arquivos incompletos. Pode manter versões que já não atendem à necessidade. Pode depender de uma senha que ninguém mais possui. Pode armazenar perfeitamente um banco de dados que ninguém sabe como restaurar.
E existe aquela situação particularmente interessante: a rotina funciona há anos e ninguém nunca precisou utilizá-la.
Isso é ótimo.
Até certo ponto.
Porque ausência de necessidade de recuperação não comprova capacidade de recuperação.
“Mas fazemos backup todos os dias”
Que bom. Excelente. Parabéns!
De quê?
Essa pergunta costuma mudar um pouco a conversa.
Documentos? Banco de dados? E-mails? Configurações? Máquinas virtuais? Aplicações? Dados armazenados nos computadores dos usuários? Arquivos que estão em serviços externos? Dependências necessárias para que os sistemas funcionem?
É possível proteger muito bem uma parte da operação e descobrir, durante um incidente, que justamente aquilo que faltou era necessário para colocar o negócio novamente de pé.
Backup não deveria começar pela ferramenta.
Deveria começar pela pergunta: o que precisamos recuperar para voltar a operar?
Quanto tempo você consegue esperar?
No FS anterior, discutimos quanto custa uma hora com a empresa parada.
Aqui aquela discussão começa a produzir consequência.
Imagine que todos os dados estejam perfeitamente protegidos.
Ótimo.
Mas restaurar o ambiente inteiro levará três dias.
A empresa consegue esperar?
Talvez sim.
Talvez três dias sejam perfeitamente aceitáveis para determinada aplicação.
Para outra, três horas podem ser demais.
Por isso, uma estratégia de recuperação não deveria considerar apenas se os dados podem ser recuperados, mas também em quanto tempo.
Na continuidade de negócios e na recuperação de desastres, aparecem conceitos como RTO e RPO.
O RTO (Recovery Time Objective) representa, de forma simplificada, quanto tempo uma operação pode tolerar ficar indisponível antes que o impacto ultrapasse o aceitável.
O RPO (Recovery Point Objective) ajuda a responder quanto de informação a organização pode tolerar perder, considerando o ponto no tempo para o qual conseguirá retornar.
Não precisamos transformar toda empresa em especialista nas siglas.
Mas precisamos responder às perguntas que elas representam.
Quanto tempo podemos ficar parados?
E quanto de informação podemos perder?
Uma cópia no mesmo lugar é proteção suficiente?
Depende do risco.
Se o objetivo é recuperar um arquivo apagado acidentalmente, talvez uma cópia local resolva muito bem.
Mas imagine um servidor com seus dados e, ao lado dele, o equipamento que mantém o backup.
Uma falha física mais grave, um incêndio, furto ou outro evento que atinja aquele ambiente pode afetar os dois.
O mesmo raciocínio vale para ataques.
Se a cópia está permanentemente acessível pelo mesmo ambiente comprometido, talvez ela também possa ser alterada, criptografada ou apagada.
Por isso estratégias de backup costumam considerar diversidade de mídias, locais distintos, cópias offline ou isoladas e diferentes níveis de retenção.
Não porque toda empresa precise construir uma fortaleza tecnológica.
Mas porque o backup precisa sobreviver ao evento contra o qual deveria proteger.
E quantas versões precisamos guardar?
Outra resposta frustrante:
Depende.
Se alguém percebe hoje que apagou um arquivo ontem, a cópia da noite passada talvez resolva.
Mas e se a alteração indevida ocorreu há vinte dias e ninguém percebeu?
Se todas as cópias antigas já foram substituídas, talvez tenhamos backups perfeitamente funcionais de um dado que já estava errado.
Retenção existe justamente para permitir voltar a diferentes pontos no tempo.
A quantidade e o período necessários dependem da operação, das obrigações legais, do volume de dados, do custo de armazenamento e dos riscos envolvidos.
Guardar tudo para sempre também não é estratégia.
É acúmulo.
Quem sabe recuperar?
Essa pergunta merece atenção.
Imagine que a empresa possui backups excelentes, documentados e testados.
Mas apenas uma pessoa conhece todo o procedimento de restauração.
E justamente no dia do incidente ela está de férias.
Ou indisponível.
Ou ganhou na Mega-Sena.
Parece familiar?
Tecnologia, processo e pessoas continuam se encontrando no mesmo lugar.
Uma capacidade crítica não deveria existir apenas na memória de alguém. Procedimentos, acessos, responsabilidades e critérios precisam ser conhecidos e suficientemente documentados para que a recuperação não dependa de uma combinação específica de pessoas disponíveis.
Testar backup significa apagar tudo?
Claro que não.
Um teste de recuperação precisa ser planejado para não criar o incidente que estamos tentando evitar.
Pode começar pequeno.
Recuperar um arquivo.
Restaurar uma pasta.
Validar um banco em ambiente isolado.
Simular a recuperação de uma máquina virtual.
Conferir se as credenciais funcionam.
Medir quanto tempo determinada restauração leva.
Depois, conforme a criticidade da operação, os testes podem evoluir.
O importante é que a primeira tentativa de restauração não aconteça justamente durante uma emergência real.
Então, o que vale conferir?
Algumas perguntas ajudam a descobrir se existe apenas backup ou uma capacidade efetiva de recuperação:
- Sabemos exatamente o que está sendo protegido?
- A rotina é monitorada e suas falhas são tratadas?
- Existem cópias suficientemente isoladas do ambiente principal?
- A retenção permite voltar ao período necessário?
- Já testamos a integridade das cópias?
- Já restauramos arquivos, bancos ou sistemas?
- Sabemos quanto tempo a recuperação leva?
- Esse tempo é compatível com o impacto para o negócio?
- As pessoas responsáveis possuem acesso e documentação?
- Se uma delas estiver indisponível, outra consegue executar?
Responder “não” a alguma dessas perguntas não significa necessariamente que a estratégia esteja errada.
Significa que existe algo a avaliar.
Backup não é o objetivo
O objetivo nunca foi possuir arquivos duplicados.
O objetivo é conseguir continuar — ou voltar.
Backup é um dos mecanismos utilizados para isso.
E talvez essa distinção pareça pequena enquanto tudo está funcionando.
No dia em que um arquivo desaparece, um servidor falha, um sistema é comprometido ou alguma informação precisa retornar a um estado anterior, ela deixa de ser pequena rapidamente.
Então, sim:
Ter backup é importante.
Mas conseguir recuperar é essencial.
E existe uma maneira relativamente simples de descobrir se sua estratégia funciona.
Teste.
Antes de precisar.
Backup, continuidade e recuperação precisam acompanhar a criticidade real da operação. A FLEURISILVA integra gestão, processos e tecnologia para apoiar decisões de risco e continuidade. www.fleurisilva.com.br
