Como restaurar um site WordPress a partir de um backup (sem perder pedidos)

Uma restauração deveria ser a parte tranquila de um dia ruim. Na prática, muitas vezes piora as coisas: o backup errado, pedidos perdidos, um site que volta com a mesma brecha por onde foi invadido. Este guia dá a você uma rotina para restaurar um site WordPress de cliente a partir de um backup, escolher o backup certo, manter os dados de que precisa e verificar o resultado antes do cliente.

1. Decida o que você realmente precisa restaurar

Nem todo problema exige uma restauração completa. Pergunte primeiro o que quebrou e o que mudou desde o último backup bom.

• Uma atualização de plugin ou tema quebrou o site: muitas vezes basta colocar de volta só aquela pasta do plugin ou tema. O banco de dados pode ficar como está.
• Conteúdo foi apagado ou sobrescrito: talvez você só precise do banco de dados, ou até de um único post a partir de uma revisão.
• O site foi invadido ou faltam arquivos: você precisa dos arquivos e normalmente também do banco de dados, de antes de o problema começar.

Depois, liste o que aconteceu no site desde o backup: novos pedidos, envios de formulários, comentários, contas de usuário, edições do cliente. Uma restauração completa joga tudo isso fora.

2. Escolha o backup certo

O backup mais recente nem sempre é o certo. Você quer o último backup de antes do problema.

• Compare a data e a hora com o momento em que o problema começou (um log de atualizações, o primeiro erro, a primeira mensagem do cliente).
• Num site invadido, volte para antes do período de infecção, não para ontem. Um backup de um site infectado restaura a infecção.
• Confirme que o backup está completo: tanto os arquivos (pelo menos wp-content) quanto o banco de dados, e que o arquivo realmente abre.

3. Faça backup do site quebrado primeiro

Antes de mudar qualquer coisa, faça um backup do site como ele está agora. Leva alguns minutos e dá a você um caminho de volta se a restauração der errado, além dos pedidos e envios que talvez precise copiar depois. Com WP-CLI:

wp db export before-restore.sql

Baixe também wp-content, ou peça à sua hospedagem um snapshot.

4. Restaure numa cópia primeiro, se puder

Se você tem uma cópia de staging ou pode criar uma, restaure lá primeiro. Você vê o resultado sem o cliente olhando e descobre se o backup presta. Para um site institucional pequeno que já está fora do ar, restaurar direto no ar é aceitável. Para uma loja, teste numa cópia.

5. Faça a restauração

Use a ferramenta de onde veio o backup. Os três caminhos comuns:

• Plugin de backup: use a função de restauração e escolha arquivos, banco de dados ou os dois.
• Painel da hospedagem: muitas hospedagens restauram arquivos e banco de dados a partir dos próprios snapshots. Veja se restauram a conta inteira ou um único site.
• À mão: envie os arquivos por SFTP e importe o banco de dados.

Para o caminho manual com WP-CLI:

wp db import backup.sql
wp search-replace 'https://old-domain.test' 'https://www.client-site.com' --skip-columns=guid
wp rewrite flush
wp cache flush

Você só precisa do search-replace quando o backup vem de outro domínio ou de uma URL de staging. Rode primeiro com --dry-run .

6. Restaurações parciais sem perder pedidos

Numa loja WooCommerce, restaurar o banco de dados significa perder cada pedido, cliente e mudança de estoque desde o backup. Prefira a menor restauração que resolve o problema:

• Uma atualização quebrada: coloque de volta só a versão antiga daquela pasta do plugin ou tema.
• Um banco de dados quebrado numa loja: antes de importar, exporte os pedidos feitos desde o backup e lance-os de novo ou peça ao seu desenvolvedor para mesclá-los.
• Conteúdo faltando: veja as revisões e a lixeira antes de mexer num backup.

7. Verifique o site antes de avisar o cliente

Uma página inicial que carrega não é um site funcionando. Siga esta lista:

1. A página inicial e as três páginas mais importantes, no desktop e num celular.
2. Envie uma mensagem de teste pelo formulário de contato e confira se ela chega.
3. Numa loja: adicione ao carrinho e passe pelo checkout com um meio de pagamento de teste.
4. Entre no wp-admin e confira se os plugins esperados estão ativos.
5. Limpe todos os caches: o plugin de cache, o cache do servidor e a CDN.

8. Depois de uma invasão: feche a brecha antes de reabrir

Uma restauração depois de uma invasão coloca de volta a versão antiga e vulnerável. Antes de o site voltar a ser público:

• Atualize o plugin, o tema ou a versão do WordPress usada para entrar.
• Troque todas as senhas de administrador e a senha do banco de dados, e remova contas de administrador que você não reconhece.
• Renove as chaves de segurança no wp-config.php (wp config shuffle-salts), o que desconecta todo mundo.
• Fique de olho no site por alguns dias: novos administradores, arquivos alterados, redirecionamentos estranhos.

9. Torne as restaurações entediantes

A maioria das restaurações falha porque ninguém nunca tinha tentado uma. Restaure um site a partir do backup todo mês, numa cópia, e anote quanto tempo levou. Combine antes com os clientes o que uma restauração significa para pedidos e envios de formulários feitos no meio-tempo, para que a conversa não seja nova no dia.

Como a Verploy lida com backups e restaurações

Cada atualização é verificada, e as arriscadas são testadas primeiro numa cópia, incluindo os formulários e o checkout, então menos atualizações precisam de restauração. Os backups noturnos vêm com um teste de restauração e, se um site quebrar depois de ir ao ar, a Verploy reverte. Saiba mais sobre backups do WordPress para agências.