O que deve recuperar uma cópia de segurança de um site?

Uma cópia de segurança pode ser concluída com sucesso sem que a recuperação tenha sido testada. O relatório não demonstra que a cópia permite recuperar as partes do site de que a empresa precisa. Mesmo que a página inicial seja reposta, isso pouco diz sobre a possibilidade de a equipa iniciar sessão, encontrar os dados dos clientes ou abrir documentos carregados.

Comece pelo trabalho. O que precisaria de fazer no site depois de o perder? Depois, peça ao seu fornecedor que explique o que teria de ser recuperado para tornar esse trabalho possível.

A reserva e o documento anexado têm de estar juntos

Imagine um site de reservas que guarda os agendamentos numa base de dados e os documentos dos clientes como ficheiros carregados. É um exemplo hipotético, mas o problema é fácil de imaginar: recupera a reserva, clica no anexo e percebe que o documento está em falta.

Tem os dados da reserva. Ainda assim, não consegue fazer o trabalho para o qual precisa do documento.

Num site WordPress típico, as orientações de cópia de segurança do WordPress explicam que tanto a base de dados como os ficheiros são importantes e devem ser mantidos como um conjunto coerente. Outros sites podem ser construídos de forma diferente. Pergunte onde estão realmente os seus registos e ficheiros carregados, em vez de presumir que uma cópia de uma única pasta os inclui.

O software do site, as respetivas definições e os acessos necessários para o recuperar e utilizar também são importantes. O mesmo se aplica aos serviços ligados. As orientações de gestão de sistemas da Direção Australiana de Sinais recomendam recuperar dados, aplicações e definições até ao mesmo ponto e identificar previamente as dependências. Para quem gere uma empresa, isso significa perguntar se todas as peças vão funcionar em conjunto e quem tem acesso para as repor.

Quanto trabalho recente poderá faltar?

Uma cópia recuperada corresponde a um momento anterior do site. Uma reserva feita depois desse momento poderá não estar lá, mesmo que a recuperação corra exatamente como previsto.

Peça ao seu fornecedor que indique até que momento consegue recuperar o site e qual seria a antiguidade dessa informação quando precisasse dela. Depois, pense no impacto do trabalho em falta. A equipa conseguiria reconstruí-lo a partir de outro registo? Seria preciso contactar os clientes? A resposta adequada depende do que o seu site faz.

Também conta o tempo até voltar ao trabalho. Copiar os dados de volta é apenas uma parte. Alguém tem de repor as outras peças e confirmar que as tarefas importantes funcionam. As orientações da AWS para testar a recuperação recomendam testar à parte, confirmar que os dados recuperados estão acessíveis e podem ser utilizados, e medir a sua antiguidade e o tempo necessário para os recuperar e validar face às necessidades da empresa.

Pergunte quanto tempo demoraram esses passos no teste. Assim terá um dado concreto para discutir. Não é uma promessa sobre quanto tempo demorará um incidente futuro do princípio ao fim, que também inclui descobrir o problema e decidir o que fazer.

O pagamento pode já ter sido feito

Voltemos ao exemplo da reserva. Imagine que o cliente pagou um sinal através de um serviço de pagamentos externo. Recuperar uma cópia antiga do site não anula esse pagamento nem prova que os registos do site coincidem com os do serviço de pagamentos.

Se a reserva estiver guardada num serviço externo, poderá nem sequer estar incluída na cópia do site. Pergunte qual é o sistema com o registo em que a equipa deve confiar, o que esse serviço consegue recuperar e como será feita a verificação entre os registos. Recuperar o seu site não faz recuar tudo o que está ligado a ele.

Peça uma recuperação segura

O passo seguinte é uma recuperação planeada, feita por pessoas autorizadas num ambiente isolado. Combine quem a fará e o que vai verificar. A cópia recuperada deve proteger os dados pessoais e da empresa, não ficar acessível ao público e deixar intactos os registos em uso.

Também é preciso impedir o envio de emails reais, a cobrança de pagamentos, o acionamento de pedidos automáticos a outros serviços e a criação de reservas reais. Contas e ligações de teste controladas podem ajudar quando estiverem disponíveis. Se não for seguro utilizar um serviço no teste, registe essa limitação e verifique a sua função à parte.

No nosso exemplo hipotético, o fornecedor recuperaria uma cópia coerente, iniciaria sessão com acesso controlado, abriria a reserva escolhida e o respetivo anexo, e compararia ambos com o que deveria existir naquele ponto de recuperação. Isto é muito mais útil do que uma captura de ecrã da página inicial.

O relato da interrupção da base de dados de janeiro de 2017 da GitLab é um lembrete histórico da importância desta questão: o relato da GitLab sobre a interrupção de janeiro de 2017. As cópias da base de dados que se esperava que existissem não estavam disponíveis e os emails de falha tinham sido rejeitados; a recuperação recorreu a outra cópia de segurança. A perda afetou dados da base de dados do GitLab.com, não os dados dos repositórios nem os clientes que geriam as suas próprias instalações. O caso mostra a diferença entre ter cópias de segurança planeadas e ter uma forma utilizável de recuperar.

Use o resultado para decidir o que precisa de mudar

Peça um breve registo do que foi recuperado e a partir de que momento, das tarefas verificadas e do resultado. Deve também indicar a antiguidade da informação recuperada, quanto tempo demoraram a recuperação e as verificações, que acessos e serviços ligados foram necessários, e o que falhou ou ficou por testar.

Uma verificação bem-sucedida da reserva demonstra que essa tarefa funcionou naquelas condições de teste. Não prova que todos os registos estão intactos, que todas as funcionalidades funcionam ou que uma recuperação futura demorará o mesmo. Uma cópia isolada também não demonstra, por si só, que o site recuperado é seguro ou está livre de um ataque.

Compare o resultado com as necessidades da sua empresa. Poderá ter provas suficientes de que a cobertura acordada serve. Poderá encontrar uma falha concreta, como ficheiros carregados em falta ou falta de acesso a uma conta. Ou o teste poderá deixar uma tarefa importante sem resposta e ser preciso avançar mais.

Se estiver a falar com a LINK-V sobre manutenção de sites, leve as tarefas de que a sua equipa e os seus clientes precisariam depois da recuperação. Podem então acordar o que fica abrangido e que testes de recuperação fazem sentido para o seu site.