Backups WordPress que restauram de facto

A configuração habitual de backups em WordPress falha no momento em que é preciso. Um plugin grava um ficheiro zip em wp-content, na mesma conta de alojamento do site. Quando um atacante, um ransomware ou a suspensão da conta deitam o site abaixo, essa cópia vai com ele.

Um backup só vale alguma coisa se for possível restaurar a partir dele. Este guia explica o que incluir, onde guardar as cópias, com que frequência as fazer, como testar um restauro e como escolher um ponto de restauro limpo depois de um ataque.

O que um backup WordPress deve incluir: ficheiros e base de dados

Um site WordPress tem duas metades, e são precisas ambas. A base de dados contém artigos, páginas, utilizadores e hashes de palavras-passe, definições, encomendas do WooCommerce e entradas de formulários. Imagine um plugin de formulário de contacto que guarda as entradas na base de dados: com um backup só de ficheiros perdem-se todos os pedidos de contacto; com um backup só da base de dados recuperam-se as entradas, mas sem o plugin que as lê.

Os ficheiros necessários são wp-content (uploads, plugins, temas), wp-config.php e .htaccess ou a configuração do servidor. O núcleo do WordPress pode ser descarregado de novo, mas só se souber que versão usava.

A partir da raiz do WordPress, com o WP-CLI:

# Exportação da base de dados, gravada fora da raiz web
mkdir -p ~/backups
wp db export ~/backups/db-$(date +%F).sql

# Ficheiros: wp-content, wp-config.php e .htaccess (sem caches nem pastas de backups antigos)
tar --exclude='wp-content/cache' \
    --exclude='wp-content/backups' \
    -czf ~/backups/files-$(date +%F).tar.gz \
    wp-content wp-config.php .htaccess

# Registar as versões para reinstalar o núcleo, os plugins e os temas a partir de fontes oficiais
wp core version > ~/backups/versions-$(date +%F).txt
wp plugin list --fields=name,version,status >> ~/backups/versions-$(date +%F).txt
wp theme list --fields=name,version,status >> ~/backups/versions-$(date +%F).txt

Substitua wp-content/backups pela pasta que o seu plugin de backups utiliza. Em nginx não existe .htaccess: retire-o do comando e guarde antes a configuração do servidor. Backups dentro de backups fazem crescer cada arquivo. Os comandos db do WP-CLI estão documentados em WordPress.org.

A regra 3-2-1 e porque um backup na conta de alojamento não conta

A regra é: três cópias dos dados, em dois tipos de armazenamento diferentes, com uma cópia externa. O site ativo conta como uma cópia. Um backup na mesma conta de alojamento é a segunda, mas partilha o mesmo acesso, o mesmo servidor e o mesmo fornecedor do site.

Quem consegue escrever no seu site consegue, em regra, apagar essa cópia. O ransomware que cifra a raiz web cifra também o zip ao lado. Uma conta suspensa ou uma falha do servidor levam as duas coisas de uma vez. Os snapshots do alojamento são úteis e rápidos de restaurar, mas continuam a ser uma única cópia que não controla.

A terceira cópia é a que conta. Deve ir para armazenamento noutro fornecedor, com credenciais separadas que não estejam no servidor web de forma a permitir apagar. Duas definições fazem uma grande diferença:

• Versionamento ou imutabilidade. Muitos serviços de armazenamento de objetos oferecem versionamento, bloqueio de objetos (object lock) ou um bloqueio de retenção do lado do fornecedor. O versionamento mantém cópias anteriores, mas quem tiver permissão para apagar ainda as pode remover. Um bloqueio no modo mais estrito (compliance) impede que qualquer pessoa, incluindo o próprio, apague ou substitua um backup até ao fim do prazo.
• Credenciais só de escrita para a tarefa de backup. Se a chave no servidor só consegue enviar ficheiros e o versionamento ou um bloqueio preserva as cópias antigas, um atacante que a roube não consegue apagar nem substituir o seu histórico.

Com que frequência fazer backups e durante quanto tempo guardar cópias

A frequência depende da rapidez com que os dados mudam. Um site institucional editado uma vez por mês fica bem servido com backups semanais. Uma loja que recebe encomendas todos os dias precisa de backups da base de dados pelo menos diários, e muitas vezes mais frequentes. Os ficheiros costumam mudar menos do que a base de dados, pelo que podem seguir um calendário próprio.

O prazo de conservação é um compromisso. As intrusões são frequentemente descobertas semanas depois de começarem. Se guardar apenas sete dias de cópias, todas podem já conter a porta dos fundos. Por outro lado, os backups antigos mantêm dados pessoais vivos, incluindo contas que os utilizadores pediram para eliminar.

Defina um prazo de conservação fixo e uma rotação, por exemplo cópias diárias durante algumas semanas e cópias mensais durante um período limitado. Registe o prazo por escrito. Esse calendário documentado ajuda também nos pedidos de apagamento: os dados desaparecem dos backups quando as cópias expiram e, até lá, garante-se que não são restaurados nem utilizados. Reescrever arquivos a cada pedido raramente é viável; consulte as orientações da sua autoridade de controlo sobre backups.

Os backups são dados pessoais: cifragem, acessos e contratos

Um backup WordPress contém contas de utilizadores, hashes de palavras-passe, dados de clientes e de encomendas e entradas de formulários. Perdê-lo é tão grave como perder a base de dados em produção.

• Cifre em trânsito e em repouso. A cifragem é uma das medidas referidas no RGPD, artigo 32.º, n.º 1, alínea a). Guarde a chave num local diferente do armazenamento que ela protege.
• Limite o acesso. Só quem restaura sites deve poder descarregar backups. Remova ligações de transferência partilhadas antigas e contas de utilizador caducadas no armazenamento.
• Celebre contratos. Um fornecedor de armazenamento de backups, ou uma agência que guarde cópias, é um subcontratante nos termos do artigo 28.º e precisa de um contrato de subcontratação de dados.

Um backup não cifrado que seja perdido ou fique acessível publicamente pode constituir, só por si, uma violação de dados pessoais. Se isso acontecer, consulte o guia da notificação em 72 horas.

Faça um teste de restauro antes de precisar dele

Restaure para um site de teste (staging) ou para uma cópia local, nunca por cima do site em produção. Use a cópia externa e não a local, que é mais cómoda, porque a externa é a que terá depois de um incidente real.

# Numa raiz web vazia no staging; WP_VERSION vem do seu ficheiro de versões
wp core download --version="$WP_VERSION" --skip-content
tar -xzf files-2026-10-23.tar.gz
# Edite o wp-config.php: credenciais da base de dados de staging, e depois:
wp db import db-2026-10-23.sql
wp search-replace 'https://www.example.com' 'https://staging.example.com' --skip-columns=guid
wp option update blog_public 0

blog_public 0 limita-se a pedir aos motores de pesquisa que fiquem de fora. Proteja também o staging com autenticação HTTP. Impeça-o de enviar e-mails a clientes reais ou de chamar webhooks de pagamento e considere usar define( 'DISABLE_WP_CRON', true ); durante o teste.

Depois, verifique:

• O início de sessão de administrador funciona
• O envio de um formulário é concluído
• A encomenda ou o artigo mais recente está presente
• As imagens e as transferências carregam
• A lista de plugins e as versões coincidem com o seu registo
• O tempo total, do início até ao site a funcionar, ficou anotado

Esse tempo é o seu tempo de recuperação real, que costuma ser mais longo do que se pensa. Registe a data, o backup utilizado, o resultado e os problemas encontrados. Um backup que nunca foi restaurado não prova nada, nem a si, nem a quem lhe perguntar como cumpre o artigo 32.º, n.º 1, alíneas c) e d), ou o princípio da responsabilidade do artigo 5.º, n.º 2.

Restauro após um ataque: encontrar o último ponto limpo

Não restaure às cegas o backup mais recente. Provavelmente contém a porta dos fundos. O mais antigo pode estar limpo, mas faltar-lhe semanas de encomendas. Antes de alterar o que quer que seja, guarde uma cópia do estado infetado para poder investigar mais tarde.

A seguir, estime quando começou a intrusão. Consulte os registos do servidor e de acessos, as datas de modificação dos ficheiros, os administradores que não reconhece e os ficheiros que diferem de um backup mais antigo. Depois escolha um backup anterior a essa data. Uma linha de base de integridade de ficheiros ajuda nisto. O plugin Security Audit & Compliance regista uma e assinala ficheiros alterados e indicadores de comprometimento, o que ajuda a delimitar quando as alterações ocorreram. Não faz nem restaura backups.

Uma abordagem mais limpa do que um restauro completo:

1. Reinstale o núcleo, os plugins e os temas a partir de fontes oficiais, em versões conhecidas.
2. Do ponto limpo, aproveite apenas os uploads e a base de dados. Procure ficheiros PHP nos uploads (como encontrar web shells nos uploads).
3. Verifique na base de dados se há administradores injetados (wp user list --role=administrator) e conteúdo de spam.
4. Volte a introduzir ou migre as encomendas e os dados criados desde esse ponto.

Um restauro não fecha a brecha. Antes de o site voltar ao ar, atualize ou remova o componente vulnerável e renove todas as palavras-passe, chaves e salts. Caso contrário, será atacado de novo pelo mesmo caminho. O procedimento completo está no nosso plano de remoção de malware, e a verificação dos checksums do núcleo confirma que o núcleo está limpo.

O que o RGPD e a NIS2 esperam dos seus backups

O RGPD, no artigo 5.º, n.º 1, alínea f), exige segurança adequada, incluindo integridade e confidencialidade. O artigo 32.º, n.º 1, alínea c), pede a capacidade de restabelecer a disponibilidade e o acesso aos dados pessoais de forma atempada no caso de um incidente, e a alínea d) pede testes regulares das medidas. Perder dados de clientes sem forma de os restaurar pode configurar uma violação da disponibilidade.

Para as entidades abrangidas pela legislação nacional, a Diretiva NIS2, no artigo 21.º, n.º 2, alínea c), refere a continuidade das atividades, incluindo a gestão de backups e a recuperação de desastres. Mesmo que a NIS2 não se aplique à sua empresa, os seus clientes abrangidos podem pedir-lhe, enquanto fornecedor ou agência, provas disso. O nosso resumo sobre o artigo 32.º do RGPD cobre o quadro mais geral.

Mantenha um registo de backups de uma página: o que é guardado, onde, com que frequência, o prazo de conservação, a cifragem, quem tem acesso e a data e o resultado do último teste de restauro. O seu próximo passo é agendar esta semana o primeiro teste de restauro, usando a cópia externa.

FAQ

O backup diário do meu alojamento chega?

Em regra, não sozinho. É uma só cópia, guardada no mesmo fornecedor e muitas vezes conservada por pouco tempo. Verifique durante quanto tempo é mantida e acrescente uma cópia externa que controle.

Devo fazer backup do núcleo do WordPress?

Não é necessário, se registar as versões do núcleo, dos plugins e dos temas. Reinstalar a partir de WordPress.org dá-lhe ainda ficheiros de núcleo comprovadamente íntegros.

Como tratar um pedido de apagamento quando os dados da pessoa estão em backups?

Apague os dados do site em produção e apoie-se no prazo de conservação documentado para os backups. Se alguma vez restaurar, garanta que os dados da pessoa não voltam ao site em produção.

Com que frequência devo testar um restauro?

Regularmente, e sempre após grandes alterações ao alojamento, ao site ou à ferramenta de backups. Escolha um intervalo que consiga mesmo cumprir e registe cada teste.

Este artigo é uma informação geral e não constitui aconselhamento jurídico.