Se o seu WordPress desaparecesse agora, de que momento conseguiria recuperar os dados?
A resposta que interessa não é «temos backups». É uma data, uma hora e uma demonstração de que a cópia pode ser recuperada. A documentação do WordPress distingue os ficheiros da base de dados: um restauro completo precisa de ambos. O NCSC, organismo britânico de cibersegurança, recomenda também testar regularmente a recuperação. (developer.wordpress.org)
Para decidir o que pedir à manutenção, comece pelo negócio. Quanto trabalho aceita refazer? E quanto tempo pode ficar sem o site? Só depois vale a pena discutir a ferramenta que fará as cópias.
Primeiro, escolha o que aceita perder
Imagine uma empresa de formação que publica o calendário no WordPress. Numa semana sem alterações, recuperar a versão da véspera pode ser aceitável. Durante a abertura de inscrições, se estas ficarem guardadas no site, a mesma perda pode deixar a equipa sem saber quem se inscreveu.
O website é o mesmo. A exigência de recuperação mudou.
Proponha à sua equipa duas perguntas, com respostas escritas:
- Perda aceitável: até quantas horas de alterações ou registos conseguimos reconstruir sem prejudicar a operação?
- Interrupção aceitável: quanto tempo podemos ficar sem as funções essenciais do site?
Não confunda os dois limites. No exercício acima, a empresa pode aceitar algumas horas sem o calendário público, mas não aceitar perder inscrições. Outra empresa pode reconstruir facilmente uma página, mas precisar de a manter disponível durante uma apresentação comercial.
Peça ao responsável de operações que valide estas respostas. Não deixe uma decisão sobre perda de trabalho entregue à configuração inicial de um plugin.
A frequência deve acompanhar os dados, não apenas as páginas
A orientação oficial do WordPress relaciona a frequência dos backups com a atividade do site. Recomenda ainda uma cópia antes de atualizações. Isso dá um princípio útil, mas não substitui a avaliação dos dados que o seu negócio guarda. (developer.wordpress.org)
A tabela seguinte é uma proposta de decisão, não uma norma nem uma garantia de serviço. Use-a para conversar com quem mantém o WordPress.
| Situação do site | Ponto de partida a avaliar | Condição para aceitar |
|---|---|---|
| Conteúdos pouco alterados, sem novos registos locais | Cópia diária e antes de intervenções | O negócio aceita reconstruir as alterações feitas desde a última cópia |
| Catálogo atualizado várias vezes durante o dia | Cópias em intervalos inferiores à perda de trabalho tolerada | A equipa consegue recuperar imagens, preços e restantes alterações dentro desse limite |
| Inscrições ou reservas guardadas no WordPress | Frequência ajustada ao ritmo de entrada de registos | O teste confirma que a perda possível cabe no limite aprovado |
| Operação que não aceita perder transações confirmadas | Avaliação de uma solução de recuperação mais exigente do que um backup periódico simples | O fornecedor demonstra como protege e reconcilia as transações |
Considere este exemplo hipotético: uma cópia diária termina às 02h00 e ocorre uma falha às 18h00. Se essa for a última cópia utilizável, há dezasseis horas de alterações fora dela. «Diário» pode soar frequente e, ainda assim, ficar longe do que a empresa precisa.
Peça que a proposta identifique a idade máxima esperada do último ponto recuperável, não apenas a hora a que a tarefa começa. Exija também um aviso quando a cópia não terminar, com uma pessoa responsável por o tratar.
O que tem de estar dentro da cópia?
Num WordPress típico, a base de dados guarda conteúdos e configurações, enquanto os ficheiros incluem temas, plugins e carregamentos, como imagens e documentos. Copiar apenas a pasta do site não equivale a copiar a base de dados. Os dois conjuntos devem permitir uma recuperação coerente. (developer.wordpress.org)
Peça ao fornecedor que faça um inventário específico do seu projeto. Em vez de aceitar «backup completo», solicite a confirmação destes pontos:
- A base de dados está incluída, com as tabelas usadas pelas funcionalidades do negócio?
- As imagens, os documentos e o código desenvolvido à medida estão abrangidos?
- Existem pastas ou tipos de ficheiro excluídos? Porquê?
- Está documentado o que é necessário configurar para o site voltar a funcionar?
- Há dados guardados noutros serviços que exigem um plano separado?
Esta última pergunta delimita responsabilidades. Se, no seu projeto, os vídeos estiverem numa plataforma externa ou os registos comerciais forem enviados para outro sistema, peça que isso fique assinalado. Não aceite que «backup do WordPress» seja usado como promessa de recuperação de toda a operação digital.
Guardar durante quanto tempo — e onde?
Frequência e retenção respondem a problemas diferentes: a primeira determina os intervalos entre cópias; a segunda, durante quanto tempo essas cópias permanecem disponíveis.
O NCSC alerta que um ataque pode atingir também os backups e que uma cópia pode já conter software malicioso quando o problema é descoberto. Recomenda cópias separadas, versões anteriores protegidas e verificação antes do restauro. (ncsc.gov.uk)
Para escolher a retenção, proponho um exercício simples: identifique uma alteração errada que a sua equipa só notaria mais tarde. Pode ser a substituição de um documento técnico consultado apenas no fim do mês. Que versão precisaria de recuperar nessa altura?
Peça ao fornecedor um calendário que combine pontos recentes com versões mais antigas, adequado a esse intervalo de deteção. Não escolha o maior prazo disponível por reflexo; peça justificação para o espaço ocupado, o custo e a utilidade de cada conjunto de cópias.
Quanto à localização, não se limite a perguntar se o backup está «na cloud». O NCSC esclarece que o armazenamento na cloud não torna uma cópia resistente à destruição por si só. (ncsc.gov.uk)
Pergunte antes: se alguém conseguir apagar o site através da conta de administração, consegue também apagar todas as cópias? Peça que a resposta seja demonstrada através das permissões e das proteções de eliminação existentes.
Um teste de restauro tem de provar mais do que a abertura da página
Testar regularmente a recuperação é uma recomendação expressa do NCSC. Para o seu WordPress, proponho que o teste tenha um resultado verificável: recuperar uma cópia identificada, num ambiente separado, e demonstrar as funções que o negócio considera essenciais. (ncsc.gov.uk)
Não use o site público como bancada de ensaio. A sequência abaixo é um modelo de aceitação a adaptar pela equipa técnica, não uma instrução para executar um restauro sem acompanhamento.
1. Escolher a cópia. Registar a data dos dados e o motivo da escolha. Num exercício, pode interessar testar uma versão antiga, não apenas a mais recente.
2. Preparar o ambiente de teste. Restringir o acesso e confirmar que o ensaio não interfere com clientes nem com os sistemas reais.
3. Medir a recuperação. Contar desde o início do procedimento até às verificações finais, incluindo obtenção de acessos e transferência das cópias.
4. Validar os dados. Conferir conteúdos e documentos cuja presença nessa data seja conhecida.
5. Executar tarefas essenciais. Entrar na administração, abrir uma área reservada ou consultar um catálogo, conforme o projeto.
6. Registar o resultado. Anotar falhas, trabalho manual necessário e tempo total. Atribuir responsáveis às correções.
No exemplo da empresa de formação, abrir a página inicial não seria suficiente. Eu pediria a confirmação de uma inscrição de teste existente à data da cópia e o acesso ao documento associado ao curso.
Antes do ensaio, peça ainda que a equipa neutralize envios, cobranças e sincronizações reais aplicáveis ao projeto. A documentação de WooCommerce Subscriptions ilustra o risco: ao recuperar dados antigos, ações de renovação já executadas podem voltar a ficar pendentes e ser repetidas. (woocommerce.com)
Com que frequência deve testar?
As fontes consultadas recomendam testes regulares, mas não estabelecem uma periodicidade universal para todos os sites WordPress. (ncsc.gov.uk)
Como ponto de partida editorial, proponho um teste quando se assume a manutenção e depois de alterações relevantes ao sistema de backups ou ao alojamento. Acrescente uma recorrência acordada: por exemplo, trimestral num site institucional de baixa criticidade, mais frequente se o risco ou a operação o justificarem.
Estes intervalos são propostas para discussão. Se o primeiro ensaio falhar, não espere pela próxima data: corrija e repita antes de considerar o processo validado.
Preencha esta ficha antes de aprovar a manutenção
Use a ficha numa reunião com o fornecedor. Uma resposta «não sabemos» identifica trabalho por fazer; não deve ser convertida numa garantia.
| Campo | Resposta a deixar por escrito |
|---|---|
| Funções a recuperar primeiro | Quais são indispensáveis à operação? |
| Perda máxima aceite | Até que intervalo de dados aceita perder? |
| Tempo máximo de interrupção | Qual é o objetivo aprovado pelo negócio? |
| Conteúdo das cópias | Que ficheiros, bases de dados e exclusões existem? |
| Frequência e retenção | Quando são feitas as cópias e quando são eliminadas? |
| Proteção independente | Que cópia continua disponível se a conta principal for comprometida? |
| Responsável por falhas | Quem recebe o alerta e acompanha a correção? |
| Último teste | Que cópia foi recuperada, quando e com que resultado? |
| Autorização de restauro | Quem pode aprovar a reposição do site público? |
| Âmbito contratado | Testes e restauros estão incluídos? Que situações exigem orçamento? |
Não peça apenas um prazo de resposta ao pedido de ajuda. Solicite que se distinga esse prazo do objetivo de recuperação e que se indiquem as condições necessárias para o cumprir.
Se os valores propostos não couberem no orçamento, peça alternativas explícitas. É preferível aprovar uma perda tolerada maior, conscientemente, a contratar uma promessa que ninguém testou.
Antes de carregar em «restaurar», decida o que preservar
Recuperar uma cópia antiga também exige tratar o que aconteceu depois dela. A documentação de WooCommerce identifica, entre os riscos, encomendas e contas de clientes ausentes no período entre a cópia e o restauro. (woocommerce.com)
Por isso, proponho uma regra de autorização: nenhum restauro do site público avança sem identificar a data de destino, os dados posteriores em risco e quem valida a reconciliação necessária. A execução deve ficar com a equipa técnica.
Para rever a manutenção do seu WordPress, peça agora três elementos concretos: o calendário das cópias, esta ficha preenchida e uma data para o teste acompanhado. Se ninguém conseguir mostrar um restauro bem-sucedido, trate a recuperação como uma capacidade por demonstrar — e inclua essa demonstração no próximo trabalho de manutenção.