# Restauração de backup no WordPress: Teste em 5 passos A restauração de backup só vale se for testada antes do desastre, num ambiente isolado. Segundo a documentação do WordPress (2024), o comando wp db import recria o banco a partir de um arquivo .sql. O ponto crítico é o banco, não os arquivos. Teste o restore completo a cada 90 dias. Testar a restauração de backup é simular o desastre antes que ele aconteça: você pega o arquivo gerado pelo plugin e o devolve a um WordPress de teste para confirmar que ele realmente volta a funcionar. A maioria dos sites tem backup, mas quase ninguém valida se aquele arquivo restaura. No painel de gestão de sites WordPress da FULL, a gente vê no suporte que o problema raro é a ausência de backup, e sim o backup corrompido que ninguém abriu. Este tutorial mostra como montar o teste, restaurar banco e arquivos e validar o resultado em cinco passos diretos. --- ## Por que testar a restauração de backup importa A restauração de backup não testada tende a falhar justamente no banco de dados, a parte mais frágil do arquivo, em boa parte dos desastres reais de WordPress. O backup existe, mas ninguém abriu para conferir. Esse é o ponto cego mais caro da gestão de sites, e ele só aparece no pior momento. Um dump truncado por timeout de PHP em sites grandes passa despercebido: o arquivo .zip existe, tem tamanho plausível e parece íntegro, mas a tabela de posts terminou pela metade. Só na hora do desastre é que o erro aparece. A gente vê isso em boa parte dos tickets de recuperação da FULL, onde o cliente tinha rotina de backup ativa e mesmo assim perdeu conteúdo. Validar antes muda o jogo. Um backup que você já restaurou uma vez é um backup que você sabe que funciona. Ferramentas como UpdraftPlus, WP STAGING e WP-CLI tornam esse teste rápido. Quando o gargalo é o tamanho do banco, ajustar o limite de execução do PHP resolve a maioria dos dumps truncados. --- ## Pré-requisitos: O ambiente de teste para a restauração de backup Toda restauração de backup precisa de 1 ambiente isolado antes do primeiro clique: um subdomínio, um WordPress local ou um staging gerado pelo painel. Restaurar por cima do site no ar é a causa número um de desastre dentro do processo que deveria salvar você. A tabela abaixo resume o que cada um dos três ambientes entrega e quando usar cada um, com base no que mais reduz risco em produção.
Ambientes para testar a restauração de backup do WordPress
Ambiente Quando usar Risco para a produção
Staging do painel Teste rápido com 1 clique, mesma stack do servidor. Nenhum: clone isolado.
WordPress local Teste offline em PHP 8.2, sem custo de hospedagem. Nenhum: roda na sua máquina.
Subdomínio descartável Validar restore de site grande com domínio real. Baixo, se o prefixo do banco for diferente.
O ambiente de staging é o caminho mais seguro porque replica a versão do PHP e do MySQL da produção. WP STAGING e WP Migrate criam esse clone sem tocar no banco original. --- ## Como testar a restauração de backup em 5 passos O teste completo de restauração de backup leva de 20 a 40 minutos num site médio e segue 5 etapas em ordem fixa: ambiente, arquivos, banco, ajuste de URL e validação. Pular a ordem é o erro mais comum, porque restaurar o banco antes da pasta uploads gera posts apontando para imagens 404. Os cinco passos abaixo seguem a sequência testada na base da FULL e funcionam tanto pelo UpdraftPlus quanto pela linha de comando com WP-CLI. ### Passo 1: Crie o ambiente de teste isolado Gere um clone do site num staging ou num WordPress local antes de tocar no backup. No painel da FULL ou em plugins como WP STAGING, isso é um clique. Confirme que o clone tem prefixo de tabela diferente da produção: esse detalhe evita que uma restauração de backup mal configurada escreva por cima do banco real. ### Passo 2: Restaure os arquivos (uploads, temas, plugins) Suba primeiro a parte estática. No UpdraftPlus, a tela "Existing Backups" lista cada conjunto e o botão Restore abre os componentes Plugins, Themes, Uploads e Others. Marque esses quatro e deixe o banco para depois. A pasta uploads é a que costuma estourar limite de upload do PHP, então restaure-a por FTP se o arquivo for grande. ### Passo 3: Restaure o banco de dados Agora restaure o componente Database. Pelo UpdraftPlus, marque a caixa Database no mesmo fluxo de Restore. Pela linha de comando, o comando wp db import dump.sql recria as tabelas a partir do arquivo .sql. Esse é o passo onde o backup do banco de dados prova se está íntegro ou truncado. ### Passo 4: Ajuste urls e prefixos Troque as URLs antigas pelas do ambiente de teste com wp search-replace no WP-CLI ou no plugin Better Search Replace. Um banco restaurado mantém a URL de produção gravada em centenas de linhas. Sem o ajuste, o clone redireciona para o site no ar e a sua restauração de backup parece quebrada quando só faltou trocar o domínio. ### Passo 5: Valide o resultado Abra o site de teste e percorra o checklist: home, um post com imagem, o login do wp-admin e um formulário. Se tudo carrega, a restauração de backup está comprovada. Anote a data: esse é o registro que transforma "tenho backup" em "sei que meu backup funciona". --- ## Restauração de backup pela linha de comando com WP-CLI A restauração de backup via WP-CLI é a mais confiável para bancos acima de 500 MB porque ignora o timeout do navegador e do PHP-FPM, onde a tela do plugin tende a falhar com erro 504 antes de terminar o import. O terminal não tem esse limite e roda o restore inteiro sem interrupção. Segundo a documentação oficial do WordPress, que mantém a referência canônica do WP-CLI, o comando wp db import lê o arquivo .sql direto no MySQL. O fluxo é curto: wp db import backup.sql restaura o banco, e wp search-replace 'url-antiga' 'url-nova' corrige os domínios em uma passada. O WP-CLI roda por SSH e serve tanto para o teste quanto para a recuperação real. Em um ticket recente de site invadido, restaurar por linha de comando cortou pela metade o tempo de uma restauração a partir de backup de site hackeado que travava pela interface. --- ## Erros comuns na restauração de backup do WordPress A restauração de backup falha quase sempre por 3 motivos previsíveis, e todos aparecem só quando você de fato testa o restore num clone. O primeiro é o banco truncado por timeout; o segundo é o descompasso de prefixo de tabela; o terceiro é o esquecimento da pasta uploads. Vale destrinchar cada um, porque a correção muda conforme a causa. O banco truncado deixa o conteúdo no ar mas sem imagem alguma quando some a pasta uploads. UpdraftPlus restaurando o componente Database por cima de um WordPress com prefixo de tabela diferente, sem ambiente de teste, resulta em wp-config apontando para tabelas que não existem e o site cai em tela branca. Já restaurar só o banco sem subir a pasta uploads gera posts apontando para imagens 404 em massa. Testar a restauração de backup num clone expõe esses três erros enquanto ainda são inofensivos. --- ## A restauração de backup faz parte da gestão do site, não da emergência Tratar a restauração de backup como tarefa de rotina, e não de pânico, é o que separa quem recupera o site em 1 hora de quem perde dias inteiros. Agrupar backup, teste de restore, atualizações e monitoramento num único painel transforma a recuperação num botão. É aqui que o bundle da FULL entra: o plano Pro custa R$849,90 por mês para até 10 sites, o que dá cerca de R$85 por site, com UpdraftPlus e os outros 16 plugins premium inclusos. Em vez de licenciar cada ferramenta de backup, staging e segurança avulsa, você concentra tudo e ainda padroniza o processo de restore em toda a carteira. Veja os planos da FULL para comparar o custo por site. Para uma rotina saudável, combine este teste com uma frequência de backup adequada ao seu volume de publicação. Backup diário sem teste de restore vale menos que backup semanal validado. --- --- ## Decisão rápida: Qual método de restauração usar Escolher o método de restauração leva menos de 1 minuto e depende de dois fatores: o tamanho do banco e o seu acesso ao servidor. Bancos acima de 500 MB pedem WP-CLI; sem acesso SSH, o UpdraftPlus em staging resolve. A árvore abaixo cobre quatro cenários comuns, do teste de rotina ao site invadido, com a recomendação direta para cada um. ---

Perguntas frequentes sobre restauração de backup

Por que um backup que nunca foi testado pode falhar na hora da restauração?

Porque o erro mais comum é o banco truncado, e ele só aparece no restore. Um dump .sql interrompido por timeout de PHP em sites grandes gera um arquivo de tamanho plausível, mas com a tabela de posts incompleta. O .zip parece íntegro até a hora de restaurar. Testar a restauração de backup num clone a cada 90 dias expõe esse problema enquanto ele ainda é inofensivo, não no meio de um desastre.

É possível testar a restauração de backup sem afetar o site em produção?

Sim, e essa é a única forma segura. Crie um ambiente de staging, um WordPress local ou um subdomínio descartável com prefixo de tabela diferente da produção. Plugins como WP STAGING e WP Migrate clonam o site em um clique, sem tocar no banco original. A restauração de backup roda nesse clone isolado, então mesmo um restore mal configurado não escreve nada por cima do site no ar.

Qual a diferença entre restaurar só o banco e restaurar o site inteiro?

Restaurar só o banco devolve posts, páginas e configurações, mas deixa de fora a pasta uploads, os temas e os plugins. O resultado é um site com conteúdo, porém com imagens 404. A restauração completa sobe os componentes Plugins, Themes, Uploads, Others e Database na ordem certa. Para um teste real, restaure tudo: o banco íntegro sem os arquivos correspondentes não prova que a recuperação funciona.

Com que frequência devo testar a restauração de backup do WordPress?

A cada 90 dias para a maioria dos sites, e mensal para lojas WooCommerce ou sites que publicam todo dia. A regra é simples: quanto mais o conteúdo muda, mais cedo um backup quebrado custa caro. Um teste trimestral de restauração de backup leva cerca de 30 minutos em staging e é o que transforma "tenho backup" em "sei que meu backup volta o site ao ar".

O que validar depois de concluir a restauração de backup?

Percorra cinco pontos: a home carrega, um post com imagem aparece completo, o login do wp-admin funciona, um formulário envia e a contagem de posts bate com a do site original. Se algum falha, em geral é URL não ajustada ou a pasta uploads ausente. Use wp search-replace para corrigir domínios. Essa validação fecha o ciclo da restauração de backup e gera o registro com data que comprova o teste.

--- ## Próximos passos para uma rotina de restore confiável Testar a restauração de backup deixa de ser um item teórico de checklist e vira um hábito quando você reserva 30 minutos por trimestre para o exercício. Comece pelo ambiente isolado, restaure arquivos antes do banco, ajuste as URLs e valide o resultado com o checklist de cinco pontos. Esse ciclo curto é o que garante que o backup vai cumprir a promessa no dia em que o site cair. Para aprofundar cada etapa, veja o tutorial de como testar backups de sites do WordPress e o passo a passo de restaurar o WordPress a partir do backup. Para continuar aprendendo gestão de sites, o FULL Academy reúne tutoriais, guias e reviews em um só lugar.

Legenda: a seleção de componentes confirma que o teste de restauração cobre arquivos e banco, não só o banco.