Você abre o painel do plugin de backup e a última cópia é de três semanas atrás. Ou pior: o arquivo existe, tem 12 MB, e quando você tenta restaurar descobre que está corrompido. Se isso acontece em um site, é chato. Se acontece em oito sites que você administra, é um problema de operação. Este guia mostra a ordem de diagnóstico para quando o backup WordPress falha, começando pelo que dá resposta mais rápida e barata.
Os sintomas que indicam backup WordPress falha
Antes de mexer em qualquer configuração, identifique qual é o sintoma. Cada um aponta para uma causa diferente, e tratar o sintoma errado só consome tempo.
| Sintoma | Causa provável |
|---|---|
| Backup trava em 0% ou em um percentual fixo | Timeout do PHP ou do servidor web |
| Erro 500 ou página em branco ao iniciar o backup | Limite de memória do PHP |
| Arquivo gerado, mas com tamanho muito menor que o normal | Backup incompleto — o processo foi interrompido |
| Backup manual funciona, o agendado não | WP-Cron ou cron real do servidor |
| Falha só em pastas específicas (uploads, cache) | Permissões de arquivo ou pasta |
| Começou a falhar depois de instalar um plugin | Conflito entre plugins |
Na prática, você vai olhar o log antes de tocar em qualquer coisa. Se o plugin de backup não tem log, o log de erros do PHP tem. O artigo sobre logs de erro do WordPress mostra onde encontrá-lo no painel da hospedagem e via SSH.
Ordem de diagnóstico: do mais barato ao mais caro
A tentação é aumentar o memory_limit na primeira falha. Isso resolve parte dos casos e mascara o resto. Siga esta ordem.
1. Leia a mensagem exata do erro
“Allowed memory size exhausted” é memória. “Maximum execution time exceeded” é timeout. “Permission denied” é permissão. “Failed to connect” é rede ou servidor de destino. São quatro correções diferentes, e a mensagem já diz qual aplicar.
Se o erro não aparece em lugar nenhum, ative o WP_DEBUG_LOG no wp-config.php e rode o backup de novo. O erro vai para wp-content/debug.log.
2. Confirme se o backup é grande demais para o ambiente
Um site com 8 GB de uploads não vai gerar backup confiável em hospedagem compartilhada com 256 MB de memória. Não é configuração: é limite físico do plano. Nesse caso, a saída é backup incremental ou excluir a pasta de cache e de backups antigos do próprio pacote.
Antes disso, vale conferir o que realmente precisa entrar na cópia. Excluir diretórios de cache e logs costuma reduzir o tamanho pela metade. O que precisa estar na cópia está detalhado em backup do WordPress: o que precisa estar na cópia.
3. Verifique o WP-Cron e o cron do servidor
Aqui está o caso em que aumentar memória não resolve. O backup agendado depende do WP-Cron, que só dispara quando alguém visita o site. Em site com pouco tráfego, o agendamento atrasa horas ou não roda. Em site com cache de página agressivo, pode não rodar nunca.
Como testar: instale o plugin WP Crontrol (existe no repositório oficial) e veja se o evento do backup está atrasado. Se estiver, substitua o WP-Cron pelo cron real do servidor. No painel da hospedagem, crie uma tarefa chamando wp-cron.php a cada 15 minutos, e desative o WP_CRON no wp-config.php com define('DISABLE_WP_CRON', true);.
Esse passo é o mais ignorado e o que mais gera backup incompleto em produção.
4. Cheque permissões de arquivos e pastas
O plugin precisa ler todos os arquivos do site. Se uploads ou uma pasta de plugin estiver com dono errado (por exemplo, root em vez do usuário do domínio), a leitura falha e o backup sai incompleto sem erro visível.
Via SSH, o comando é find /caminho/do/site -type d -exec chmod 755 {} \; para pastas e find /caminho/do/site -type f -exec chmod 644 {} \; para arquivos. Sem SSH, use o gerenciador de arquivos do painel da hospedagem e confira se o proprietário das pastas é o usuário correto. Em hospedagem compartilhada, isso costuma ser ajustável pelo suporte.
5. Isole conflito de plugins
Se o backup manual funciona e o agendado falha, ou se a falha começou depois de uma instalação, o suspeito é conflito. Plugins de segurança que bloqueiam requisições internas, plugins de cache que atrasam o cron e plugins de firewall são os mais comuns.
Teste em um ambiente de staging, não no site em produção. Desative os suspeitos um a um e rode o backup. Se o problema sumir, você achou o culpado — e a decisão de trocar ou manter esse plugin é o tema de plugin abandonado no WordPress.
Como corrigir cada causa
- Memória: aumente memory_limit no wp-config.php com
define('WP_MEMORY_LIMIT', '512M');e peça o mesmo no php.ini da hospedagem. Se o plano não permitir, troque de abordagem: backup incremental ou exclusão de cache. - Timeout: aumente max_execution_time para 300 ou mais. Se o servidor não aceitar, divida o backup em partes (arquivos e banco separados).
- Cron: desative o WP-Cron e configure o cron real do servidor, como descrito acima.
- Permissões: corrija dono e modo das pastas. Depois rode o backup de novo e confira o tamanho do arquivo.
- Conflito: desative o plugin conflitante ou troque por alternativa. Se for plugin de segurança, ajuste a regra que bloqueia requisições internas.
Depois de corrigir, não confie no primeiro backup bem-sucedido. Rode três vezes seguidas e restaure um deles em staging. Backup que nunca foi restaurado não é backup: é esperança.
Quando aumentar memória não resolve
Este é o ponto que separa o diagnóstico raso do diagnóstico útil. Aumentar memória não resolve quando:
- O problema é o cron que não dispara (site com pouco tráfego ou cache agressivo).
- O backup excede o espaço em disco disponível na conta.
- O servidor de destino (S3, Google Drive, Dropbox) está com credencial expirada ou limite de API atingido.
- A hospedagem aplica limite de I/O ou de processos, e o backup é morto pelo próprio servidor sem mensagem no PHP.
- O banco de dados tem tabelas corrompidas, e o dump para no meio.
Nesses casos, o caminho é outro: trocar a estratégia de backup, não o limite. Backup em nuvem com versionamento costuma contornar limite de disco local, e a escolha do plugin certo para isso está em backup em nuvem WordPress: como escolher o plugin.
Erros comuns ao tentar corrigir backup WordPress falha
- Aumentar memory_limit sem ler o log. Resolve o sintoma errado e esconde a causa real.
- Rodar backup manual todo dia em vez de consertar o agendamento. Funciona até o dia em que você esquece.
- Testar correção em produção. Um backup mal configurado pode consumir todo o I/O do servidor e derrubar o site — o mesmo cenário do erro 500 no WordPress.
- Confiar no tamanho do arquivo como prova de integridade. Um backup incompleto pode ter tamanho normal se a falha ocorreu no banco.
- Nunca restaurar. Você só sabe que o backup funciona quando restaura.
Checklist para testar backups regularmente
Se você administra vários sites, transforme isso em rotina. Uma vez por mês, para cada site:
- Confirme que o último backup agendado rodou na data esperada.
- Compare o tamanho com o do mês anterior. Variação brusca indica problema.
- Restaure o backup em um ambiente de staging e verifique se o site abre, se o login funciona e se as imagens carregam.
- Confirme que o backup inclui banco e arquivos, não só um dos dois.
- Verifique se a cópia está fora do servidor de origem.
Esse checklist se encaixa bem na rotina de manutenção WordPress que você já segue para atualizações e segurança.
Prevenção: o que evita a próxima falha
Backup que falha raramente é azar. É ambiente mal dimensionado ou agendamento mal configurado. Três medidas resolvem a maior parte:
- Monitore o resultado do backup, não só a existência do arquivo. Alerta por e-mail quando falhar.
- Mantenha o plugin de backup atualizado e compatível com a versão do PHP do servidor. Plugin antigo em PHP novo é fonte constante de erro.
- Não acumule backups no mesmo disco do site. Isso consome espaço e ainda deixa você sem cópia se o servidor cair.
Quando o backup falha em um site, você resolve em uma tarde. Quando falha em dez, o problema deixa de ser técnico e vira operacional: você precisa saber, em um lugar só, quais sites tiveram backup concluído e quais falharam. É para esse cenário que o painel 100% WP existe — monitorar backup, atualização e segurança de vários sites sem abrir cada painel individualmente.
Se a falha persiste depois de passar por toda a ordem de diagnóstico, e você não tem acesso a SSH nem ao log do servidor, o caminho mais rápido é abrir chamado na hospedagem com o erro exato em mãos. Sem a mensagem, o suporte vai pedir para você repetir os mesmos passos que já tentou.
