Como restaurar backup WordPress sem perder arquivos ou pedidos recentes

Restaurar backup WordPress pode salvar um site depois de uma atualização quebrada, conflito de plugin, mudança de tema, falha de hospedagem, migração mal executada ou invasão. Mas a restauração também pode apagar dados importantes se for feita sem planejamento.

O principal risco é voltar o site para um ponto antigo no tempo. Se o backup foi criado ontem às 2h da manhã, tudo que aconteceu depois desse horário pode estar em risco: pedidos WooCommerce, cadastros, envios de formulário, comentários, posts editados, uploads de mídia e configurações recentes.

Por isso, antes de clicar em “restaurar”, pare por alguns minutos e confirme o que precisa voltar. Em muitos casos, você não precisa restaurar o site inteiro. Pode ser mais seguro restaurar apenas arquivos, apenas o banco de dados, apenas um plugin, apenas um tema ou testar tudo antes em um ambiente separado.

Aviso importante: antes de restaurar qualquer backup, faça uma cópia do estado atual do site, mesmo que ele esteja quebrado. Essa cópia pode ser necessária para recuperar dados recentes, comparar arquivos ou desfazer uma restauração que não funcionou.

Se você ainda não tem uma rotina confiável, veja primeiro o guia sobre como fazer backup do WordPress com segurança.

Checklist rápido antes de restaurar backup WordPress

Se o site está fora do ar e você precisa agir rápido, siga este checklist:

1. Não restaure às cegas. Descubra a data e o horário do backup.
2. Faça backup do estado atual. Mesmo quebrado, o site atual pode ter pedidos, uploads, leads ou alterações recentes.
3. Identifique o que mudou depois do backup. Houve pedidos? Posts? Formulários? Cadastros? Uploads?
4. Separe o problema. O erro está em plugin, tema, arquivo, banco de dados, hospedagem ou atualização?
5. Use staging quando possível. Teste a restauração em uma cópia antes de aplicar na produção.
6. Evite restaurar banco antigo em loja ativa. Isso pode apagar pedidos, clientes, alterações de estoque e status de pagamento.
7. Valide depois. Confira páginas, painel, formulários, checkout, e-mails, links permanentes e logs antes de considerar o site recuperado.

Se você não sabe onde está o backup, não tem acesso à hospedagem ou administra uma loja com vendas recentes, acione o suporte da hospedagem ou um profissional antes de seguir.

Pré-requisitos para restaurar um backup com segurança

Antes de começar, confirme se você tem:

• acesso de administrador ao WordPress, se o painel ainda estiver disponível;
• acesso ao painel da hospedagem, plugin de backup ou serviço onde o backup está salvo;
• backup completo ou, pelo menos, clareza sobre o que está incluído nele;
• data e horário exatos do backup que será restaurado;
• cópia do estado atual do site;
• lista do que mudou desde o backup;
• acesso a FTP/SFTP ou gerenciador de arquivos, se a restauração envolver arquivos;
• acesso ao banco de dados ou suporte técnico, se a restauração envolver banco;
• ambiente de teste ou staging WordPress, principalmente em lojas, sites de membros e sites que recebem leads.

Se algum desses itens estiver faltando, o risco aumenta. Em site simples, talvez o processo ainda seja possível pelo painel da hospedagem. Em loja, portal de membros, curso online ou site crítico, é melhor não improvisar.

O que um backup completo de WordPress precisa ter

Um backup WordPress completo normalmente tem duas partes principais:

1. Arquivos do site.
2. Banco de dados.

As duas partes são importantes porque guardam informações diferentes.

Arquivos do site

Os arquivos ficam no servidor e podem incluir:

• arquivos do core do WordPress;
• plugins;
• temas;
• uploads de mídia;
• arquivos enviados manualmente;
• arquivos de configuração, como wp-config.php;
• regras de servidor, como .htaccess, quando aplicável;
• customizações feitas no tema, plugin ou pasta wp-content.

A pasta wp-content costuma ser uma das áreas mais importantes, porque reúne temas, plugins e uploads. Se você restaurar um backup sem os uploads, por exemplo, posts podem continuar existindo no banco, mas imagens e PDFs podem ficar ausentes.

Banco de dados

O banco de dados guarda grande parte do conteúdo e das configurações do WordPress. Ele pode incluir:

• posts e páginas;
• comentários;
• usuários;
• menus;
• configurações do site;
• configurações de plugins e tema;
• produtos, pedidos e clientes em WooCommerce, conforme a configuração da loja;
• dados de formulários, membros, cursos, assinaturas ou comunidade, dependendo dos plugins usados.

Baixar apenas a pasta do WordPress por FTP geralmente não copia o banco de dados. O banco costuma ficar em MySQL ou MariaDB, separado dos arquivos do WordPress.

Por isso, ao recuperar backup WordPress, a pergunta certa não é apenas “tenho um zip?”. A pergunta é: “esse backup tem arquivos, banco de dados e foi criado em um momento consistente?”.

O que pode ser perdido ao restaurar um backup antigo

Toda restauração volta o site para algum ponto no tempo. Se o backup é de ontem às 2h da manhã, tudo que aconteceu depois pode estar em risco.

Veja exemplos comuns:

O que mudou depois do backup	Risco ao restaurar backup antigo
Pedido WooCommerce	Pedido pode desaparecer ou voltar com status antigo
Pagamento aprovado	Site pode perder o registro interno do pedido, mesmo que o pagamento exista no gateway
Alteração de estoque	Estoque pode voltar para quantidade anterior
Novo usuário	Cadastro pode sumir
Lead de formulário	Envio pode ser apagado, dependendo do plugin e do local de armazenamento
Post ou página editada	Conteúdo pode voltar para versão antiga
Upload de imagem/PDF	Arquivo pode sumir se não estiver no backup restaurado
Comentário novo	Comentário pode ser perdido
Configuração de plugin	Ajuste recente pode ser desfeito

Esse é o motivo para fazer uma cópia do estado atual antes de restaurar. Mesmo que a restauração apague algo, você ainda terá uma fonte para recuperar dados manualmente ou comparar diferenças.

Restauração completa, arquivos ou banco: qual escolher?

Nem todo problema exige restaurar o site inteiro. A melhor escolha depende do que quebrou, do que mudou depois do backup e do tipo de dado que você precisa preservar.

Quando restaurar o site inteiro

A restauração completa pode fazer sentido quando:

• o site foi migrado de forma errada;
• muitos arquivos e tabelas foram corrompidos;
• uma invasão alterou várias partes e há um backup limpo anterior;
• a hospedagem recomenda restaurar um snapshot completo;
• você está recuperando o site em outro servidor;
• o site não recebeu dados importantes depois do backup.

Mesmo nesses casos, teste em staging quando possível e salve o estado atual antes.

Quando restaurar apenas arquivos

Restaurar arquivos pode ser melhor quando:

• uma atualização de plugin ou tema quebrou o site;
• uma edição em arquivo PHP causou erro crítico;
• arquivos foram apagados ou substituídos por engano;
• o banco de dados parece intacto;
• você quer preservar posts, pedidos, usuários e configurações recentes.

Exemplo: se você atualizou um plugin e o site quebrou, talvez seja mais seguro voltar apenas a pasta daquele plugin ou a versão anterior do tema, em vez de restaurar todo o banco.

Quando restaurar apenas o banco de dados

Restaurar banco pode fazer sentido quando:

• configurações foram alteradas e não há como reverter pelo painel;
• conteúdo foi apagado em massa;
• tabelas foram corrompidas;
• uma importação sobrescreveu posts, produtos ou configurações;
• os arquivos do site continuam corretos.

Mas atenção: restaurar banco antigo é uma das ações com maior risco de apagar dados recentes. Em WooCommerce, membros, cursos, assinaturas e formulários, essa decisão precisa de cuidado extra.

Quando não restaurar e apenas corrigir a causa

Às vezes, restaurar backup não é o melhor caminho. Pode ser mais seguro corrigir a causa com uma ação mais limitada, como:

• desativar temporariamente um plugin problemático pelo painel, modo de recuperação ou suporte da hospedagem;
• trocar temporariamente para um tema padrão, se houver contexto e backup;
• limpar cache;
• corrigir permissão de arquivos com suporte técnico;
• voltar uma configuração no painel;
• remover ou ajustar uma regra errada de redirecionamento;
• pedir à hospedagem para verificar erro de servidor.

Não apague arquivos, tabelas ou plugins manualmente sem backup atual, entendimento do problema e possibilidade de desfazer a ação.

Se o problema começou logo após uma atualização, veja também o guia sobre atualizar WordPress com segurança, que inclui lógica de teste, validação e rollback.

Passo a passo seguro para restaurar backup WordPress

A sequência abaixo é uma referência geral. O caminho exato muda conforme hospedagem, plugin de backup, painel, tipo de servidor e acesso disponível.

1. Faça uma cópia do estado atual

Antes de mexer, gere um backup do site como ele está agora.

Isso vale mesmo se o site estiver quebrado, lento, infectado ou com erro visual. O estado atual pode conter dados que não existiam no backup antigo.

Nomeie esse backup de forma clara, por exemplo:

• “estado-atual-antes-da-restauracao”; ou
• “site-quebrado-antes-do-rollback”.

Não substitua o backup antigo por essa cópia. Guarde os dois.

2. Identifique data, horário e escopo do backup

Confira:

• quando o backup foi criado;
• se inclui arquivos;
• se inclui banco de dados;
• se inclui uploads;
• se inclui wp-content;
• se inclui tabelas de plugins críticos;
• se é backup da hospedagem, plugin, manual ou snapshot;
• se a ferramenta permite restaurar partes separadas.

Se você não consegue saber o que está dentro do backup, trate a restauração como risco alto.

3. Liste o que aconteceu depois do backup

Anote tudo que pode ter mudado desde a data do backup:

• pedidos;
• pagamentos;
• alterações de estoque;
• cadastros;
• leads;
• posts publicados;
• páginas editadas;
• uploads;
• comentários;
• atualizações de plugins;
• mudanças de tema;
• configurações de frete, pagamento, cache ou segurança.

Essa lista ajuda a decidir se você pode restaurar tudo ou se precisa preservar dados recentes.

4. Teste em staging quando possível

O ideal é restaurar primeiro em um ambiente de teste. Assim você confirma se o backup abre, se o painel funciona e se o problema foi resolvido sem afetar visitantes.

Em staging, valide:

• página inicial;
• páginas importantes;
• login no painel;
• plugins críticos;
• tema e layout;
• formulários;
• checkout, se houver WooCommerce;
• imagens e downloads;
• links permanentes;
• cache e redirecionamentos.

Staging reduz risco, mas não substitui backup. Se você ainda não usa esse fluxo, veja o guia sobre staging WordPress.

5. Coloque o site em janela de manutenção, se necessário

Em sites com tráfego, leads ou vendas, evite restaurar enquanto usuários estão interagindo com o site.

Considere uma janela de manutenção quando:

• há WooCommerce ativo;
• formulários recebem leads importantes;
• usuários fazem login;
• há membros, cursos ou assinaturas;
• a restauração envolve banco de dados;
• o processo pode demorar.

O objetivo é evitar que alguém faça um pedido, cadastro ou envio de formulário durante a restauração e esse dado se perca.

6. Restaure a menor parte necessária

Sempre que a ferramenta permitir, prefira a restauração mais específica que resolve o problema.

Exemplos:

• erro em plugin: restaurar apenas o plugin ou voltar a versão afetada;
• tema quebrado: restaurar tema, tema filho ou ajuste específico;
• imagens ausentes: restaurar uploads;
• conteúdo apagado: avaliar restauração seletiva do banco;
• site inteiro corrompido: considerar restauração completa.

Quanto menor o escopo da restauração, menor tende a ser o risco de apagar dados recentes. Mas isso depende da ferramenta, da hospedagem e do tipo de problema.

7. Limpe cache e revise o site

Depois da restauração, limpe caches que possam mostrar versões misturadas do site:

• cache do plugin;
• cache da hospedagem;
• cache de CDN, se existir;
• cache do navegador, para teste local.

Depois, navegue como visitante e como administrador. Não confie apenas na página inicial.

8. Documente o que foi restaurado

Registre:

• data e hora do backup restaurado;
• tipo de restauração feita;
• ferramenta usada;
• motivo da restauração;
• problemas encontrados;
• dados recentes que precisaram ser recuperados manualmente;
• validações realizadas depois.

Esse registro ajuda a evitar confusão se o problema voltar ou se outro profissional precisar assumir o caso.

Cuidados especiais em lojas WooCommerce

WooCommerce exige mais cuidado porque pedidos, clientes, estoque, cupons, status de pagamento, dados de entrega e integrações podem mudar a cada minuto.

Antes de restaurar backup em loja, responda:

• houve pedidos depois da data do backup?
• houve pagamentos aprovados no gateway?
• houve alterações de status de pedido?
• houve mudanças de estoque?
• houve novos clientes cadastrados?
• houve reembolsos, cupons ou notas fiscais?
• há integrações com ERP, marketplace, frete ou emissão fiscal?
• a loja usa HPOS ou armazenamento legado de pedidos?

A documentação do WooCommerce informa que o HPOS usa tabelas dedicadas para dados de pedidos, como pedidos, endereços e metadados. Antes do WooCommerce 8.2, o armazenamento padrão dependia das estruturas de _posts e _postmeta; em instalações mais novas, o HPOS tende a ser o padrão, mas lojas existentes podem ter configuração diferente. Na prática, isso significa que a estratégia de restauração precisa considerar a configuração real da loja.

Se houve pedidos depois do backup, restaurar o banco antigo pode apagar ou desorganizar informações da loja. Em muitos casos, o caminho mais seguro é:

1. fazer backup do estado atual;
2. pausar temporariamente novas compras, se necessário;
3. testar a restauração em staging;
4. exportar ou registrar pedidos recentes antes de qualquer rollback;
5. restaurar somente o que for necessário;
6. reconciliar pedidos, pagamentos e estoque depois.

Para atualizações de loja, veja também o checklist de atualizar WooCommerce com segurança.

E se o site foi hackeado?

Quando o motivo da restauração é invasão, o cuidado muda. Restaurar um backup limpo pode ajudar, mas não resolve tudo se a vulnerabilidade continuar ativa.

Antes de restaurar:

• faça backup do estado atual para análise;
• identifique quando a invasão começou;
• procure um backup anterior ao comprometimento;
• troque senhas de administradores, hospedagem, FTP/SFTP e banco, conforme necessário;
• atualize WordPress, plugins e temas depois da recuperação;
• remova usuários administradores desconhecidos pelo painel ou com suporte técnico, evitando exclusões manuais sem backup;
• revise arquivos suspeitos;
• consulte a hospedagem se houver malware no servidor.

Se você suspeita de invasão, use como complemento o guia sobre WordPress hackeado: como limpar e recuperar seu site.

Como validar depois de restaurar o site

Depois da restauração, confira pelo menos os pontos abaixo.

Site e painel

• O site carrega sem erro?
• O painel /wp-admin abre?
• É possível fazer login?
• A página inicial está correta?
• Páginas importantes carregam?
• O layout está normal no desktop e mobile?
• Imagens aparecem?
• Downloads e PDFs funcionam?

Conteúdo e dados

• Posts recentes continuam lá?
• Páginas editadas recentemente estão corretas?
• Menus e widgets foram preservados?
• Usuários recentes aparecem?
• Comentários recentes continuam disponíveis?
• Uploads recentes estão presentes?

Formulários e integrações

• Formulário de contato envia corretamente?
• Leads aparecem onde deveriam?
• E-mails transacionais chegam?
• Integrações com CRM, automação ou newsletter continuam funcionando?

WooCommerce, se houver loja

• Produtos aparecem corretamente?
• Estoque está coerente?
• Carrinho funciona?
• Checkout carrega?
• Frete calcula?
• Gateway de pagamento aparece?
• Pedido de teste pode ser criado em ambiente seguro?
• E-mails de pedido funcionam?
• Pedidos recentes foram preservados ou reconciliados?

SEO e rastreamento

• URLs importantes continuam respondendo?
• Links permanentes funcionam?
• Redirecionamentos importantes continuam ativos?
• Sitemap continua acessível?
• Robots.txt não foi alterado indevidamente?
• Tags de analytics, pixels e Search Console continuam presentes?

Quando não fazer a restauração sozinho

Procure suporte técnico quando:

• o backup não é claramente completo;
• você não sabe se vai restaurar arquivos, banco ou os dois;
• há WooCommerce com pedidos recentes;
• há membros, cursos, assinaturas ou comunidade;
• o site foi invadido;
• o banco de dados está corrompido;
• a hospedagem usa painel próprio e você não conhece o processo;
• a restauração envolve comandos de banco de dados;
• não existe staging e o site é crítico;
• você não sabe como desfazer a restauração.

Nesses casos, improvisar pode causar perda real de dados. O melhor caminho é acionar a hospedagem, o desenvolvedor responsável ou um profissional com experiência em WordPress.

Como evitar esse problema na próxima vez

Depois que o site voltar, aproveite para melhorar a rotina:

• mantenha backup automático;
• salve cópias fora do servidor principal;
• teste restaurações periodicamente;
• faça backup manual antes de mudanças sensíveis;
• use staging para atualizações importantes;
• evite atualizar muitos plugins de uma vez;
• documente plugins críticos e integrações;
• defina uma janela de manutenção para lojas;
• saiba onde fica o botão de restauração antes da emergência.

Restaurar backup não deveria ser um salto no escuro. Com processo, teste e cópia do estado atual, você reduz muito o risco de transformar uma falha corrigível em perda de dados.

Checklist final para restaurar backup WordPress

Antes de restaurar:

• [ ] Tenho backup do estado atual.
• [ ] Sei a data e hora do backup antigo.
• [ ] Sei se o backup inclui arquivos, banco e uploads.
• [ ] Listei dados criados depois do backup.
• [ ] Avaliei se o site tem WooCommerce, membros, cursos ou leads críticos.
• [ ] Testei em staging, se possível.
• [ ] Escolhi a menor restauração necessária.
• [ ] Tenho acesso à hospedagem ou suporte técnico.

Depois de restaurar:

• [ ] Site abre normalmente.
• [ ] Painel WordPress funciona.
• [ ] Páginas importantes carregam.
• [ ] Imagens e uploads aparecem.
• [ ] Formulários funcionam.
• [ ] Checkout funciona, se houver WooCommerce.
• [ ] Pedidos recentes foram preservados ou reconciliados.
• [ ] Cache foi limpo.
• [ ] Links permanentes e redirecionamentos foram revisados.
• [ ] O ocorrido foi documentado.