O backup que não restaura não é backup
Você gerou o backup do WordPress, baixou o arquivo, guardou num lugar seguro. Semana passada, o site quebrou. Você restaura a cópia e.. nada funciona: ou aparece um erro de conexão com o banco, ou as imagens somem, ou o site volta para um estado antigo, com posts que você publicou depois do backup. O problema não é o backup em si: é que ele estava incompleto ou desatualizado. Um backup que não restaura não serve para nada. Neste artigo, você vai ver exatamente o que precisa estar dentro da cópia para ela ser útil quando você mais precisar.
O que um backup do WordPress precisa conter
Um site WordPress é feito de duas partes: os arquivos (o código do WordPress, temas, plugins, imagens, uploads) e o banco de dados (onde ficam os posts, páginas, comentários, configurações). Um backup completo precisa incluir as duas coisas. Se faltar uma delas, a restauração falha ou o site fica incompleto.
Arquivos essenciais
Na pasta wp-content, você precisa copiar:
- uploads/: todas as imagens, PDFs, vídeos e outros arquivos enviados pela mídia. Sem isso, as imagens do site quebram.
- themes/: os temas instalados, incluindo o ativo. Se você usa um tema filho, ele também está aqui.
- plugins/: todos os plugins instalados, ativos ou não. Sem eles, funcionalidades somem.
- wp-config.php: na raiz, contém as credenciais do banco e chaves de segurança. Sem ele, o WordPress não conecta ao banco.
- .htaccess (se existir): regras de reescrita de URL, essenciais para permalinks e segurança.
Além disso, arquivos da raiz como index.php, wp-settings.php e outros do núcleo são necessários, mas se você reinstalar o WordPress depois, eles são recriados. O importante é não esquecer o wp-content e o wp-config.php.
Banco de dados
O banco de dados contém todo o conteúdo do site. Você precisa exportar um dump SQL completo, incluindo todas as tabelas (geralmente com prefixo wp_). Se o backup for feito por plugin, ele já faz isso. Se for manual, use phpMyAdmin ou WP-CLI. Um dump incompleto pode faltar tabelas importantes, como wp_posts ou wp_options, e o site quebra.
Uma experiência real com migração de um site WordPress para outro servidor
A migração de um site WordPress para um novo servidor parece, à primeira vista, um processo simples: transferir os arquivos, importar o banco de dados e apontar o domínio.
Na prática, principalmente quando o projeto foi desenvolvido inicialmente em um ambiente provisório, existem diversos detalhes que precisam ser revisados para que o site funcione corretamente no novo servidor.
Um exemplo real foi o projeto da Activa-ID, empresa de tecnologia especializada em soluções de identificação, RFID, IoT, rastreabilidade e automação.
O projeto começa em um ambiente provisório
Nos projetos que desenvolvemos, muitas vezes o site não é construído diretamente no servidor definitivo do cliente.
Criamos inicialmente um ambiente provisório para que a equipe responsável possa acompanhar o desenvolvimento, revisar as páginas e validar o projeto antes da publicação.
Essa etapa é importante porque permite que o cliente faça suas considerações sem interferir diretamente no site que está atualmente no ar.
Depois da aprovação, chega o momento de levar todo esse ambiente para o servidor definitivo.
Como fazemos a migração do WordPress?
Ao longo das nossas experiências, utilizamos principalmente duas formas de realizar esse processo.
A primeira é através de uma ferramenta de migração, como o All-in-One WP Migration, que facilita a transferência do WordPress para o novo ambiente.
A segunda é realizar o processo manualmente, transferindo os arquivos do WordPress e importando o banco de dados diretamente no novo servidor.
As duas abordagens funcionam. Porém, na nossa experiência, a migração manual tende a exigir mais atenção e ajustes após a transferência.
Por que a migração manual pode gerar mais problemas?
Quando transferimos arquivos e banco de dados manualmente, existem diversas configurações que podem não estar exatamente iguais entre o ambiente antigo e o novo servidor.
Depois da migração, podemos encontrar problemas relacionados a:
- URLs do ambiente provisório;
- banco de dados;
- permissões de arquivos;
- configuração do PHP;
.htaccess;- caminhos de arquivos;
- SSL;
- plugins;
- cache;
- links internos;
- configurações específicas do servidor.
Em alguns casos, o site abre normalmente, mas determinados recursos deixam de funcionar.
Em outros, podemos encontrar erros mais evidentes, como páginas que não carregam, imagens quebradas, redirecionamentos incorretos ou problemas no painel administrativo.
Por isso, uma migração não deve ser considerada concluída simplesmente porque o domínio abriu no novo servidor.
O que percebemos utilizando uma ferramenta de migração
Quando o ambiente permite, nossa preferência é utilizar uma ferramenta como o All-in-One WP Migration.
Na nossa experiência com diversos projetos, esse processo costuma reduzir bastante a quantidade de ajustes necessários depois da transferência.
Isso não significa que a ferramenta elimine todos os possíveis problemas. Cada servidor possui suas próprias configurações e limitações.
Mas ela simplifica uma parte importante do processo e torna a migração mais previsível.
E as URLs do ambiente provisório?
Existe ainda um ponto que sempre verificamos depois da migração: as URLs utilizadas durante o desenvolvimento.
Imagine que o projeto tenha sido desenvolvido em:
https://staging.exemplo.com
Depois da publicação, ele precisa funcionar em:
https://exemplo.com
Mesmo quando utilizamos uma ferramenta de migração, é necessário verificar se o domínio definitivo foi aplicado corretamente em todo o projeto.
Isso inclui verificar o banco de dados, links internos, imagens, arquivos, configurações do WordPress e outros recursos que possam ainda estar apontando para o endereço provisório.
A migração não termina quando o site abre
Essa é uma das principais experiências que acumulamos trabalhando com diferentes migrações de WordPress.
Migrar um site não é apenas copiar arquivos e banco de dados.
É necessário validar o ambiente inteiro depois da transferência.
No caso de projetos como o da Activa-ID, que possuem uma estrutura completa de páginas, soluções, produtos e conteúdos relacionados a RFID e IoT, essa validação se torna ainda mais importante.
Por isso, depois de cada migração, fazemos uma revisão do funcionamento do site e verificamos principalmente:
- se o domínio definitivo está sendo utilizado;
- se as URLs antigas foram substituídas corretamente;
- se imagens e arquivos estão carregando;
- se o painel do WordPress está funcionando;
- se formulários e integrações continuam operando;
- se SSL e redirecionamentos estão corretos;
- se cache e demais recursos do servidor estão funcionando;
- se não existem erros aparentes após a publicação.
A experiência mostra que uma boa migração de WordPress depende tanto da transferência quanto da validação realizada depois dela.
Como diagnosticar se o backup está completo
Antes de precisar restaurar, confira o conteúdo do backup:
- Abra o arquivo ZIP (ou a pasta) e veja se existe a pasta
wp-contentcom as subpastasuploads,themeseplugins. - Verifique o tamanho: se o site tem 2 GB de imagens e o backup tem 50 MB, algo está errado. O uploads costuma ser a maior parte.
- Confira o dump do banco: abra o arquivo.sql num editor e procure por
CREATE TABLE wp_posts. Se não achar, o dump está incompleto. - Teste a restauração num ambiente de staging (veja abaixo).
Como testar a restauração sem derrubar o site
O único jeito de saber se o backup funciona é restaurá-lo. Mas você não precisa fazer isso no site em produção. Crie um ambiente de staging (uma cópia do site em subdomínio ou subpasta, ou localmente) e restaure o backup ali.
Passo a passo para testar
- Crie um ambiente de staging: use um plugin como WP Staging, ou crie um subdomínio (ex.: staging.seusite.com) e instale o WordPress.
- Substitua os arquivos: envie os arquivos do backup para a pasta do staging (via FTP ou gerenciador de arquivos da hospedagem).
- Importe o banco de dados: crie um banco de dados novo no staging e importe o dump SQL via phpMyAdmin ou WP-CLI.
- Ajuste o wp-config.php: edite as credenciais do banco no staging (nome do banco, usuário, senha).
- Atualize as URLs: se o site original é
seusite.come o staging éstaging.seusite.com, você precisa atualizar as URLs no banco. Use WP-CLI:wp search-replace 'seusite.com' 'staging.seusite.com' --all-tables. Ou use um plugin como Better Search Replace. - Acesse o staging: veja se o site carrega, se as imagens aparecem, se os plugins funcionam. Teste o login.
Se tudo funcionar no staging, o backup está bom. Se não, você descobriu o problema antes de precisar do backup de verdade.
Quando NÃO usar essa solução
O teste de restauração em staging é sempre recomendado, mas há situações em que você não vai conseguir fazer: se o site está fora do ar e você não tem um ambiente de staging disponível, pode ser necessário restaurar direto na produção. Nesse caso, o backup é a única esperança. Porém, se o backup estiver incompleto, a restauração pode piorar a situação. Por isso, a prevenção é fundamental: mantenha backups frequentes e testados.
Erros comuns ao gerar backup do WordPress
- Esquecer o banco de dados: só copiar os arquivos não restaura o conteúdo.
- Backup incompleto por limite de execução: plugins de backup podem falhar em sites grandes se o PHP tiver tempo máximo baixo. Configure
max_execution_timeou use WP-CLI. - Não testar a restauração: o backup pode estar corrompido e você só descobre na hora do desespero.
- Guardar o backup no mesmo servidor: se o servidor queimar, você perde tudo. Armazene em local externo (Google Drive, Dropbox, S3).
Prevenção: como garantir que o backup do WordPress esteja sempre pronto
Automatize os backups e monitore. Configure backups diários (ou semanais, dependendo da frequência de atualizações) e mantenha versões anteriores. Teste a restauração periodicamente, pelo menos uma vez por mês. Além disso, verifique se o backup inclui tudo o que listamos. Se você administra vários sites, fazer isso manualmente é inviável. Um painel como o 100% WP centraliza backups de todos os seus sites, com verificação automática e restauração em poucos cliques: algo que se torna essencial quando você gerencia dez sites e não pode perder tempo conferindo cada um.
Quando chamar um profissional
Se você não se sente confortável com FTP, phpMyAdmin ou linha de comando, ou se o site é crítico e o backup é a única cópia, considere contratar um serviço especializado. Restaurar um backup pode ser estressante, e um erro pode derrubar o site definitivamente. Profissionais têm experiência e ferramentas para minimizar riscos.
Em resumo: um backup do WordPress só serve se contiver arquivos e banco de dados, e se for testado. Não espere o desastre para descobrir que sua cópia está incompleta. Teste agora, antes que você precise.
Fonte: Documentação oficial do WordPress
