Cópias de segurança do website: planeie a recuperação

Um plano útil de cópias de segurança do website explica o que pode ser recuperado, até que momento anterior é possível recuar e quem fará a recuperação. Antes de aceitar «cópias de segurança incluídas», peça uma lista dos sistemas abrangidos, dos pontos de recuperação conservados e uma demonstração segura de que o website acordado pode ser restaurado. Uma notificação de cópia concluída com sucesso, por si só, não responde a estas questões.

Esta lista de verificação de cópias de segurança e restauro ajuda uma empresa a acordar os requisitos de recuperação com o fornecedor do website ou do alojamento. A solução adequada depende do que o website guarda e de como a empresa o utiliza. Um website de serviços com cinco páginas, um website editorial e uma loja online podem ter necessidades de recuperação muito diferentes.

1. Liste aquilo de que o website depende

Comece pelos elementos necessários para o funcionamento do website, em vez do nome de um produto de cópias de segurança. Inclua os conteúdos das páginas, as imagens, o código, a configuração e qualquer base de dados. Depois, liste separadamente os serviços ligados: o destino de um formulário, um sistema de reservas, um prestador de pagamentos ou um sistema de gestão de relações com clientes podem guardar informação fora da conta de alojamento do website.

Uma cópia das páginas visíveis não inclui necessariamente esses outros registos. Por exemplo, o WordPress explica que uma cópia de segurança completa típica precisa tanto dos ficheiros do website como da base de dados. Descarregar apenas os ficheiros não inclui a base de dados. Os ficheiros e a base de dados devem também corresponder a um ponto compatível do histórico do website, sobretudo em torno de atualizações.

Num website criado a partir de um repositório de código, pergunte o que mais é necessário para o reconstruir e publicar. As orientações do GitHub sobre cópias de segurança distinguem os dados incluídos nos diferentes métodos. Uma cópia do repositório é útil, mas não se deve presumir que contém todos os recursos carregados, registos externos, definições de conta ou requisitos de publicação.

Use uma pequena tabela de cobertura para tornar estes limites visíveis. Trata-se de uma ficha de planeamento, não de uma afirmação de que todos os websites precisam de todas as linhas. Substitua os exemplos pelos sistemas que a sua empresa realmente utiliza e registe o responsável por cada um.

2. Acorde a perda de dados e a indisponibilidade aceitáveis

Duas perguntas em linguagem corrente tornam o plano mais útil: quanta informação recente poderia a empresa perder e durante quanto tempo poderia o serviço em causa estar indisponível? Responda tendo em conta o processo da empresa, não apenas a página inicial. Uma página estática de apresentação e um sistema que aceita encomendas pagas podem justificar respostas diferentes.

Estas perguntas correspondem ao objetivo de ponto de recuperação, ou RPO, e ao objetivo de tempo de recuperação, ou RTO. A AWS define estes objetivos de recuperação em termos do intervalo aceitável de perda de dados e da duração máxima aceitável da interrupção do serviço. Trate-os como metas de planeamento acordadas. Não constituem prova de que um determinado fornecedor consegue cumpri-los em todos os incidentes.

Por exemplo, um ponto de recuperação diário pode deixar um intervalo com alterações feitas após a última cópia concluída com sucesso. A sua existência, por si só, nada diz sobre a rapidez com que alguém o consegue localizar, obter acesso, restaurá-lo e verificar o resultado. Peça ao fornecedor que relacione a frequência proposta e o processo de recuperação com as metas que definiu.

Evite escolher «sem perda de dados» ou «recuperação instantânea» apenas porque estas expressões parecem tranquilizadoras. Explique que informação não pode ser recriada e que atividades da empresa podem recorrer temporariamente a uma alternativa. Depois, acorde uma solução viável, o seu custo e quaisquer limitações. Registe o horário em que está disponível ajuda à recuperação, incluindo como será tratado um incidente fora desse horário.

3. Conserve pontos de recuperação utilizáveis durante tempo suficiente

A frequência das cópias de segurança e a sua retenção respondem a perguntas diferentes. A frequência diz respeito à regularidade com que é criado um novo ponto de recuperação. A retenção diz respeito ao tempo durante o qual os pontos mais antigos permanecem disponíveis. Uma cópia frequente que substitui repetidamente a única cópia existente pode ser de pouca ajuda quando uma alteração indesejada é descoberta vários dias depois.

Pergunte quantas versões são conservadas, como são identificadas as suas datas e o que acontece quando se atingem limites de armazenamento ou há uma alteração de subscrição. Inclua o tempo de que a equipa poderá precisar para detetar um problema. Se ninguém revê o conteúdo durante várias semanas, um prazo de retenção muito curto pode terminar antes de se descobrir uma eliminação acidental.

Esclareça como as cópias de recuperação estão separadas do ambiente de produção e quem as pode modificar ou eliminar. Uma cópia afetada pela mesma ação errada na conta ou pelo mesmo incidente de segurança pode não proporcionar a independência esperada. Discuta os controlos de acesso e a proteção com o fornecedor responsável, em vez de presumir que uma segunda pasta ou a sincronização automática são suficientes.

Mantenha o plano prático: identifique a localização de recuperação e o responsável pela conta sem colocar palavras-passe, chaves secretas ou registos de clientes num briefing partilhado. Registe onde são mantidas as instruções de acesso autorizado. Acorde também quem recebe as notificações de falha e o que faz quando uma cópia de segurança agendada não é concluída.

4. Distinga reversão de publicação, recuperação seletiva e restauro completo

Problemas diferentes exigem métodos de recuperação diferentes. A reversão de uma publicação repõe uma versão anterior do website publicado. A recuperação seletiva recupera um ficheiro, página ou registo específico. Um restauro completo reconstrói o ambiente abrangido a partir de um conjunto de recuperação. Pergunte quais destes métodos são suportados pela solução acordada e o que cada um altera.

Por exemplo, a documentação do Cloudflare Pages descreve a reversão para uma publicação de produção anterior bem-sucedida. Isto é útil para um problema introduzido por uma publicação. Não demonstra que uma plataforma de reservas separada ou uma base de dados externa de clientes também regressará a esse momento. Confirme o comportamento de cada dependência, em vez de tratar a «reversão» como um botão universal para anular alterações.

Antes de restaurar dados antigos, identifique as alterações feitas desde esse ponto de recuperação. Um restauro completo da base de dados pode substituir informação mais recente válida juntamente com a alteração indesejada. Decida se esses registos posteriores podem ser preservados, conciliados ou recuperados separadamente. A pessoa que autoriza a recuperação deve compreender esta contrapartida antes de começar uma operação destrutiva.

Registe o processo de decisão em linguagem corrente: quem avalia o problema, quem aprova o ponto de recuperação escolhido e quem executa o trabalho. Inclua uma forma de manter o estado atual disponível para investigação, quando adequado. O plano de recuperação deve explicar como a equipa escolhe um método, não incentivar o responsável da empresa a experimentar no website em produção.

5. Demonstre um restauro num ambiente seguro

Peça um teste de restauro coordenado antes de confiar no plano. A AWS recomenda testes periódicos de recuperação para verificar se os dados das cópias de segurança podem ser recuperados e utilizados. A questão prática é saber se o conjunto de recuperação acordado produz um website utilizável, não se existe um ficheiro de arquivo.

Use um destino de teste isolado, acordado com o responsável técnico. Mantenha o acesso à informação de clientes restaurada sob controlo e impeça as cópias de teste de enviar notificações reais, aceitar pagamentos ou substituir integrações em produção. A equipa responsável deve decidir que dados são adequados ao teste e como serão removidos depois.

Reveja as páginas restauradas, as imagens, a navegação e a configuração necessária. Verifique um percurso representativo da atividade da empresa através de condições de teste coordenadas. Uma página apresentada corretamente não prova que o serviço a que está ligada esteja configurado corretamente. Quando não for possível testar uma dependência em segurança, registe essa limitação em vez de assinalar todo o percurso como demonstrado.

Guarde um breve registo do teste: o ponto de recuperação utilizado, os sistemas abrangidos, o destino, as horas de início e fim, as verificações realizadas e os problemas por resolver. Meça as etapas relevantes para o objetivo de recuperação acordado, incluindo o acesso e a verificação. Repita as verificações relevantes após alterações significativas ao website, ao alojamento ou à solução de recuperação, com uma frequência de revisão acordada para as suas circunstâncias.

6. Analise uma decisão de recuperação realista

Considere uma consultora hipotética com um pequeno website de serviços. As páginas são publicadas a partir de um repositório e os pedidos de contacto são guardados num sistema separado. Na terça-feira à tarde, a equipa descobre que uma publicação de segunda-feira removeu uma página de serviço. Chegou um novo pedido de contacto na terça-feira de manhã.

A primeira pergunta é se o problema afeta apenas as páginas publicadas ou também o sistema de pedidos de contacto. Se uma publicação anterior contiver a página em falta, a equipa pode avaliar a reversão dessa publicação sem presumir que tem de restaurar os registos de contacto separados. Verifica que outras alterações do website também seriam revertidas e se recuperar apenas essa página é uma opção melhor.

Numa pré-visualização isolada, o fornecedor responsável demonstra a versão proposta e verifica as ligações e a configuração do formulário acordadas. O responsável da empresa revê as alterações afetadas e autoriza a recuperação em produção através do processo estabelecido. O registo mais recente do sistema de pedidos de contacto é considerado separadamente, porque o seu armazenamento e as condições de recuperação são independentes.

Este exemplo descreve um método de decisão, não um resultado relatado de um cliente nem uma promessa de tempo de recuperação. Numa loja online com encomendas guardadas na base de dados do website, a mesma decisão teria de ter em conta as encomendas criadas após o ponto de recuperação proposto. A lição útil é mapear onde a informação reside antes de escolher o que restaurar.

7. Inclua as responsabilidades de recuperação no acordo

Termine com uma pequena lista de verificação a que ambas as partes possam responder. Guarde-a com os materiais de entrega do website e volte a revê-la quando o website mudar. Deve continuar a ser compreensível para quem tiver de comunicar um incidente, mesmo que essa pessoa não tenha encomendado o projeto original.

• Sabemos que componentes do website e sistemas externos estão abrangidos.
• Acordámos os objetivos de recuperação, a frequência das cópias e a retenção.
• Sabemos quem verifica as falhas e quem pode obter acesso autorizado para recuperação.
• Compreendemos os métodos de recuperação suportados e o risco para os dados mais recentes.
• Temos um registo datado do teste de restauro, com as suas limitações e ações seguintes.
• Acordámos a responsabilidade, a disponibilidade e quaisquer custos de recuperação separados.

Acrescente os requisitos por resolver ao briefing do projeto do website. Se o planeamento da recuperação acompanhar a substituição do website, use a lista de verificação de reformulação para a transição mais ampla. Um acordo de recuperação claro reduz as suposições quando ocorre um incidente; deve descrever o que foi acordado e demonstrado.

O serviço de websites da Digital Studio começa nos EUR 2.190 para a criação pontual de um website com até cinco páginas, usando conteúdo fornecido, com design responsivo, bases de SEO, um formulário de captação de contactos e lançamento no seu domínio. As condições das cópias de segurança, os testes de restauro e o apoio contínuo à recuperação têm de ser discutidos e ter um âmbito explicitamente definido para o seu projeto. Descreva o seu website e os requisitos de recuperação para que as responsabilidades e qualquer trabalho adicional possam ser acordados antes de começar a construção.