«Temos backups.» É uma resposta tranquilizadora, mas não chega para saber se um website pode ser recuperado. Quando uma atualização falha, o servidor fica indisponível ou ocorre um incidente de segurança, as perguntas são outras: existe uma cópia utilizável, que dados podemos perder e quanto tempo demoramos a retomar a atividade?
Uma estratégia de cópias de segurança deve começar pelas necessidades de recuperação do website, e não apenas pela tarefa automática que guarda os ficheiros.
Ter uma cópia de segurança é diferente de conseguir recuperar
O backup é a cópia dos dados. O restauro é a operação de os repor; a recuperação só fica concluída quando o website volta a funcionar corretamente.
É possível ter várias cópias e continuar sem um plano de recuperação: os ficheiros podem estar incompletos, a base de dados pode não ter sido incluída, a única cópia pode estar no servidor que falhou ou ninguém pode ter acesso ao sistema de restauro. Mesmo uma cópia válida pode demorar demasiado a recuperar para as necessidades do negócio.
Uma mensagem de «backup concluído» não demonstra, por si só, que o website pode ser restaurado. Essa capacidade precisa de ser verificada.
O que deve estar incluído nas cópias
Um WordPress depende de dois conjuntos principais de informação, que devem ser protegidos de forma coerente:
| Elemento | O que inclui |
|---|---|
| Ficheiros | WordPress, temas, plugins, imagens, documentos, personalizações e ficheiros de configuração, como o wp-config.php. |
| Base de dados | Páginas, artigos, utilizadores, definições e dados dos plugins. Numa loja WooCommerce, inclui também produtos, encomendas e outros registos operacionais. |
Uma cópia apenas dos ficheiros não recupera, normalmente, a base de dados. O inverso também não devolve imagens, documentos ou personalizações guardadas no servidor. É ainda importante que os dois conjuntos correspondam a momentos compatíveis, sobretudo em websites com alterações frequentes.
Algumas integrações mantêm informação noutros serviços, como plataformas de faturação, sistemas de gestão ou prestadores de pagamentos. O backup do WordPress não protege automaticamente esses dados externos.
Frequência, perda aceitável e tempo de recuperação
Não existe uma frequência de backup adequada a todos os websites. Um site institucional com alterações ocasionais tem necessidades diferentes de um blogue atualizado diariamente ou de uma loja WooCommerce ativa que recebe encomendas ao longo do dia.
A decisão deve partir de dois objetivos:
| Objetivo | Pergunta a responder |
|---|---|
| RPO — objetivo de ponto de recuperação | Qual é o período máximo de alterações que podemos aceitar perder? |
| RTO — objetivo de tempo de recuperação | Durante quanto tempo pode o website ficar indisponível até voltar a funcionar? |
O RPO orienta a frequência das cópias ou a necessidade de mecanismos de recuperação mais frequentes, eventualmente até um ponto específico no tempo. O RTO obriga a considerar o acesso às cópias, a disponibilidade de quem intervém, a duração do restauro e os testes posteriores.
Por exemplo, uma cópia diária pode ser razoável para um website pouco alterado, mas insuficiente para um WooCommerce com transações constantes. Fazer backups mais frequentes reduz a janela potencial de perda; não garante, por si só, uma recuperação rápida.
Retenção: guardar mais do que a última versão
Conservar apenas a cópia mais recente também cria riscos. Se uma alteração incorreta ou uma infeção só for detetada dias depois, os backups recentes podem já conter o problema.
Uma retenção adequada combina vários pontos de recuperação, incluindo versões de diferentes datas. A quantidade e os prazos devem refletir a importância dos dados, o espaço disponível e o tempo que um problema pode demorar a ser descoberto.
Onde guardar as cópias e como protegê-las
Se o website e a única cópia estiverem no mesmo servidor, uma falha de disco, um ataque ou um erro de eliminação pode afetar ambos. É recomendável manter pelo menos uma cópia fora da infraestrutura principal, com acesso e proteção suficientemente independentes para não ficar exposta ao mesmo incidente.
Essa cópia pode estar num serviço de armazenamento externo, noutro servidor ou numa solução própria de backups. O importante não é apenas a localização: é também controlar quem pode aceder, alterar ou eliminar as versões guardadas. Quando contêm dados pessoais ou informação sensível, devem existir medidas adequadas de proteção, incluindo cifragem quando aplicável.
O backup do alojamento é suficiente?
Pode ser, dependendo do serviço e da importância do website. Antes de confiar exclusivamente nele, convém confirmar o que inclui, a frequência, a retenção, a localização das cópias e as condições de restauro. Em alguns serviços, recuperar depende de um pedido ao suporte técnico, o que pode influenciar o tempo de indisponibilidade.
Combinar o backup do alojamento com uma solução externa independente pode reduzir a dependência de um único fornecedor, sem obrigar a uma infraestrutura complexa.
Automatizar, acompanhar e testar o restauro
Cópias manuais são úteis antes de intervenções pontuais, mas não devem ser a única proteção de um website ativo. A automatização pode ser feita pelo alojamento, pelo servidor, por um plugin ou por um serviço externo. Em qualquer dos casos, é necessário acompanhar as execuções, os erros, o espaço disponível, a retenção e o destino dos ficheiros.
Um sistema configurado para fazer backups não significa que esteja a produzir cópias válidas. O teste decisivo é conseguir recuperar os dados e utilizar o website restaurado.
Um teste de restauro deve, de forma proporcional à importância do projeto:
- Restaurar uma cópia num ambiente isolado, sem afetar o website em produção nem desencadear emails, cobranças ou integrações reais.
- Verificar o conteúdo e as funções principais: páginas, imagens, acesso à administração, formulários e, quando aplicável, produtos, encomendas e processo de compra em modo de teste.
- Confirmar a consistência dos dados e medir o tempo necessário, identificando falhas e registando o procedimento para futuras intervenções.
O tempo registado num teste é uma referência útil, não uma garantia de duração idêntica durante um incidente real.
Nem todos os incidentes exigem repor o website inteiro. Por vezes, é possível recuperar um ficheiro, uma pasta ou determinados dados. Mas um restauro parcial só é seguro depois de avaliar as dependências: substituir uma tabela ou uma base de dados pode afetar informação que entretanto mudou.
WooCommerce: recuperar sem apagar encomendas recentes
Imagine uma loja com uma cópia de segurança efetuada às 12h. Às 16h ocorre uma falha e, entretanto, foram registadas 20 encomendas. Restaurar integralmente a base de dados das 12h pode fazer desaparecer essas encomendas do website, mesmo que alguns pagamentos já tenham sido processados pelo respetivo prestador.
Numa situação destas, a recuperação não deve começar por substituir indiscriminadamente a base de dados. É necessário preservar, quando possível, o estado atual, identificar as alterações posteriores à cópia e confrontar os registos da loja com os sistemas de pagamentos, faturação e gestão de stock.
Há ainda uma particularidade técnica: o WooCommerce pode utilizar High-Performance Order Storage (HPOS), que guarda as encomendas em tabelas próprias da base de dados. A estratégia de cópia e restauro tem de contemplar as tabelas efetivamente utilizadas e as dependências das extensões instaladas.
Quando existem subscrições, integrações externas ou tarefas agendadas, também é necessário verificar operações pendentes e já executadas, para evitar omissões ou duplicações após a recuperação.
Atualizações, migrações e incidentes de segurança
Há momentos em que uma cópia atual e um procedimento de recuperação definido são especialmente importantes:
- Antes de atualizações relevantes:
- criar uma cópia recente e, quando o risco o justifica, testar as alterações num ambiente de testes (staging). Reverter uma atualização não significa necessariamente poder substituir toda a base de dados sem consequências.
- Antes de migrações:
- conservar uma cópia independente da origem e validar o novo ambiente — incluindo ficheiros, dados e funcionalidades — antes de desativar o anterior.
- Após um incidente de segurança:
- identificar a causa, corrigir a vulnerabilidade e verificar a integridade do ambiente recuperado. Restaurar uma cópia pode reintroduzir o problema se a falha de segurança continuar presente.
Backups também não substituem atualizações, controlo de acessos, monitorização ou outras medidas de segurança e manutenção.
Quem consegue executar a recuperação?
O plano deve identificar quem tem acesso às cópias, quem pode autorizar o restauro e quem sabe executá-lo. As credenciais e instruções devem estar protegidas e disponíveis às pessoas certas, sem depender exclusivamente de um único técnico ou fornecedor.
Se o processo depende do suporte do alojamento, essa dependência também deve ser considerada no tempo de recuperação previsto.
Lista de verificação: o seu WordPress está preparado?
Antes de considerar a estratégia adequada, confirme:
- As cópias incluem ficheiros, base de dados e os elementos específicos do projeto?
- A frequência respeita a perda de dados aceitável (RPO)?
- Existem várias versões e um prazo de retenção apropriado?
- Há pelo menos uma cópia externa, independente e protegida contra eliminação?
- As últimas execuções e eventuais erros são acompanhados?
- Já foi realizado um restauro de teste e verificadas as funções principais?
- O tempo de recuperação observado é compatível com o RTO?
- Os acessos, responsáveis e procedimentos estão definidos e documentados?
- Numa loja online, existe forma de conferir encomendas, pagamentos e stock após um restauro?
Se várias respostas forem «não sei», a prioridade é avaliar a capacidade real de recuperação antes de depender dessas cópias numa emergência.
Conclusão
Uma boa estratégia de backups WordPress não se mede apenas pela quantidade de cópias guardadas. Mede-se pela possibilidade de recuperar informação fiável, dentro de um prazo aceitável e sem criar novas perdas durante o restauro. Essa segurança operacional resulta de cópias adequadas, armazenamento independente, acompanhamento e testes.
