Database Optimization WP Rocket: recuperar o site

Tipo Performance & Velocidade

Nome do erro Otimização de banco do WP Rocket corrompeu o site EN: WP Rocket database optimization broke the site

Severidade Crítico

Descrição Database Optimization do WP Rocket é a limpeza de banco que apaga revisões, rascunhos, comentários de spam e transientes de forma permanente. A própria documentação avisa que, depois de executada, não há como desfazer, então conteúdo apagado por engano ou tabelas que quebraram só voltam com a restauração de um backup.

O que é o Database Optimization do WP Rocket que corrompeu o site?

O Database Optimization é o recurso do WP Rocket, na aba Banco de dados das configurações, que remove dados acumulados do WordPress para reduzir o tamanho das tabelas: revisões de posts, rascunhos automáticos, posts e comentários na lixeira, comentários de spam e transientes. O problema entra em cena porque cada uma dessas opções faz um DELETE direto no banco, sem etapa de confirmação granular e sem backup automático. A documentação oficial é explícita: faça backup do banco antes de rodar a limpeza, porque uma vez executada não existe forma de desfazer. Quando alguém marca todas as opções e executa, ou deixa a limpeza agendada rodando sozinha, revisões que eram a única cópia de um texto, rascunhos que ainda seriam publicados ou registros que outros plugins guardavam em tabelas próprias podem sumir. Se o banco não tinha um backup recente, a recuperação não é uma configuração do WP Rocket: é restaurar a tabela ou o banco inteiro a partir de uma cópia anterior.

Como identificar

Posts, páginas ou rascunhos que existiam sumiram do painel logo após você clicar em Otimizar na aba Banco de dados do WP Rocket.
O histórico de revisões de um post ficou vazio e você perdeu uma versão de texto que só existia como revisão.
O site exibe Erro ao estabelecer conexão com o banco de dados ou uma tabela retorna Table is marked as crashed depois da otimização.
Dados de plugins que gravam em tabelas próprias (formulários, pedidos, logs) desapareceram após a limpeza agendada rodar sozinha durante a madrugada.

Antes de começar: Importar um backup substitui o banco inteiro pelo conteúdo do arquivo. Sempre exporte o estado atual antes de restaurar, para ter um ponto de retorno caso a importação falhe no meio.

Como prevenir

Faça um backup completo do banco imediatamente antes de qualquer limpeza, como a própria documentação do WP Rocket recomenda
Deixe a limpeza Agendada desligada ou só ligue depois de confirmar que existe uma rotina de backup automático diária e testada
Marque uma opção por vez na otimização e verifique o site entre cada execução, em vez de marcar todas e rodar de uma só vez
Limite revisões pelo wp-config em vez de apagá-las em massa, mantendo um histórico controlado sem precisar de limpeza destrutiva

Causa

A opção Revisões foi marcada e apagou revisões que eram a única cópia de um texto, já que o WP Rocket remove todas as linhas de tipo revision sem confirmar quais ainda interessam.
A limpeza foi deixada Agendada (diária, semanal ou mensal) e rodou sozinha via WP-Cron sem ninguém acompanhar, apagando rascunhos e revisões criados entre uma execução e outra.
A opção Otimizar tabelas rodou um OPTIMIZE TABLE que, em uma tabela já com cabeçalho corrompido, deixou a tabela marcada como crashed em vez de compactá-la.
Não havia backup recente do banco quando a limpeza foi executada, contrariando o aviso da própria documentação do WP Rocket de fazer backup antes de qualquer cleanup.
Um plugin de terceiros guardava informação útil em entradas que o WordPress trata como rascunho automático ou transiente, e a limpeza de Auto Drafts ou Transientes apagou esses registros junto.

Como resolver

Pare a limpeza agendada antes de qualquer coisa: abra as configurações do WP Rocket, vá na aba de banco de dados e desative o agendamento da limpeza automática. Isso impede que uma nova execução apague ainda mais dados enquanto você recupera o que já foi perdido.
Confirme o que foi apagado e localize um backup anterior: verifique no painel quais conteúdos sumiram e procure a cópia de banco mais recente anterior à limpeza, no seu plugin de backup ou no painel da hospedagem. Como a otimização é irreversível, o backup é a única origem real dos dados perdidos.
```
wp db check
```
Faça um backup do estado atual antes de restaurar: exporte o banco como está agora, mesmo quebrado, para ter um ponto de retorno caso a restauração falhe no meio. Restaurar por cima sem essa cópia transforma um problema recuperável em perda definitiva.
```
wp db export estado-atual-antes-de-restaurar.sql
```
Restaure o banco a partir do backup anterior à otimização: importe o arquivo de backup por cima do banco atual usando o WP-CLI ou o phpMyAdmin da hospedagem. Os posts, revisões e registros voltam exatamente como estavam no momento daquela cópia.
```
wp db import backup-antes-da-otimização.sql
```
Se foi só uma tabela que ficou corrompida, repare em vez de restaurar tudo: quando o erro é uma única tabela marcada como crashed e não dados apagados, rode o reparo nativo do MySQL antes de recorrer ao backup completo. Isso evita perder alterações feitas em outras tabelas depois do backup.
```
wp db repair
mysqlcheck -r -u USUÁRIO -p NOME_DO_BANCO
```
Valide o site e refaça a otimização com segurança: confira se o conteúdo voltou, limpe o cache do WP Rocket e só então rode a otimização de novo, desta vez com um backup feito segundos antes e marcando apenas as opções que você entende. Nunca deixe Revisões agendada sem uma rotina de backup confiável.

BASH

# Recuperacao do banco apos a otimizacao do WP Rocket (via WP-CLI, na raiz do site)

# 1. Salve o estado atual ANTES de restaurar (ponto de retorno se a importacao falhar)
wp db export estado-atual-antes-de-restaurar.sql --add-drop-table

# 2. Restaure o banco a partir do backup anterior a otimizacao
wp db import backup-antes-da-otimizacao.sql

# 3. Se foi apenas UMA tabela marcada como crashed, repare em vez de restaurar tudo
wp db repair
mysqlcheck --repair --user=USUARIO --password NOME_DO_BANCO wp_posts

# 4. Valide a integridade e limpe o cache antes de voltar ao ar
wp db check
wp rocket clean --confirm

Perguntas frequentes

É possível desfazer a otimização de banco do WP Rocket?

Não. A documentação oficial do WP Rocket afirma que, uma vez executada a otimização, não há como desfazer. Os dados apagados (revisões, rascunhos, comentários) só voltam restaurando o banco a partir de um backup feito antes da limpeza.

O WP Rocket faz backup automático antes de otimizar o banco?

Não. O WP Rocket apenas avisa para você fazer o backup do banco antes de rodar a limpeza, mas não cria essa cópia sozinho. Por isso a recuperação depende de você já ter um backup recente do banco em outro lugar.

Perdi revisões de um post, como recupero o texto?

Se a revisão era a única cópia daquele texto, ela só volta restaurando o banco de um backup anterior à otimização. Sem backup, o conteúdo da revisão apagada não pode ser recuperado, porque a limpeza removeu a linha definitivamente da tabela de posts.

A otimização de tabelas do WP Rocket pode corromper o banco?

O OPTIMIZE TABLE em si é uma operação padrão do MySQL, mas se ele roda sobre uma tabela que já estava com o cabeçalho danificado, a tabela pode terminar marcada como crashed. Nesse caso o reparo nativo do MySQL costuma resolver sem precisar restaurar todo o banco.

Por que dados sumiram se eu nem cliquei em otimizar?

Quase sempre porque a limpeza estava Agendada para rodar automaticamente, diária, semanal ou mensal, via WP-Cron. Ela executou sozinha em segundo plano e apagou rascunhos, revisões e transientes criados entre uma execução e outra.

Restaurar o backup vai apagar o conteúdo que criei depois da limpeza?

Sim, importar um backup substitui o banco inteiro pelo estado daquela cópia, então alterações feitas depois se perdem. Por isso o passo certo é exportar o estado atual antes de restaurar, para conseguir mesclar manualmente o que for necessário.

Como evito esse problema sem deixar de usar a otimização?

Mantenha um backup automático diário e testado, deixe a limpeza agendada desligada e marque uma opção por vez, verificando o site entre cada execução. Para revisões, prefira limitar a quantidade pelo wp-config em vez de apagar tudo de uma vez.

Atenção

Como corrigir o CDN Rewrite que não altera URLs no Perfmatters no WordPress

O Perfmatters CDN Rewrite não funciona quando a opção Enable CDN Rewrite esta desligada, a CDN URL esta preenchida errada, ou os assets ficam fora das Included Directories, fazendo o HTML continuar servindo arquivos do domínio original em vez do CDN.

Grave

Como corrigir o cache que quebra páginas de quiz entre Tutor LMS e WP Rocket

Quando o cache quiz do Tutor LMS com WP Rocket quebra, o Delay JavaScript Execution segurou o tutor.js até a interacao do aluno, ou o Combine JavaScript trocou a ordem de carga. Excluir os assets do quiz dessas otimizacoes restaura o timer e o envio AJAX das respostas.

Grave

Como corrigir o conflito de cache entre WP Rocket, LiteSpeed e Perfmatters

O conflito acontece quando WP Rocket e o plugin LiteSpeed Cache geram cache de página ao mesmo tempo e o Perfmatters repete otimizacoes (como Remove Unused CSS) que o WP Rocket já faz. O resultado e layout quebrado, JavaScript que para de funcionar e o ganho de PageSpeed que some.

Grave

Como corrigir o conflito de nonce expirado entre WP Rocket e reCAPTCHA

O nonce do reCAPTCHA expira com o WP Rocket quando a página do formulário é entregue do cache com um token de segurança gerado horas antes. O visitante envia esse nonce já vencido, o reCAPTCHA ou o formulário rejeita a verificação e a submissão falha, mesmo o usuário sendo humano.

Atenção

Como corrigir o cache mobile que não é gerado no WP-Optimize

O cache mobile do WP-Optimize não é gerado quando a opção Generate separate files for mobile devices está desligada, quando o site não usa tema ou plugin de detecção mobile, ou quando o cache desktop já foi salvo antes do primeiro acesso mobile e passa a ser servido a todos os dispositivos.

Atenção

Como corrigir o aviso de cache do navegador no WordPress

O aviso de browser caching no WordPress aparece quando os arquivos estáticos do site são servidos sem cabeçalho de validade (expires), forcando o navegador a baixar tudo de novo a cada visita. A correção e definir expires headers no servidor.

Setores

Extensões

Integrações

Como recuperar o site após a otimização de banco do WP Rocket

O que é o Database Optimization do WP Rocket que corrompeu o site?

Como identificar

Como prevenir

Causa

Como resolver

Perguntas frequentes

Itens relacionados

Como corrigir o CDN Rewrite que não altera URLs no Perfmatters no WordPress

Como corrigir o cache que quebra páginas de quiz entre Tutor LMS e WP Rocket

Como corrigir o conflito de cache entre WP Rocket, LiteSpeed e Perfmatters

Como corrigir o conflito de nonce expirado entre WP Rocket e reCAPTCHA

Como corrigir o cache mobile que não é gerado no WP-Optimize

Como corrigir o aviso de cache do navegador no WordPress

Setores

Extensões

Integrações

Extensões

Hero Sections

Seções de CTA

Login

Blog

Cabeçalhos

Seções de FAQ

Cadastro

Blog individual

Rodapés

Seções de contato

Seções de preços

Faixas

Portfólio

Seções de equipe

Números

Logotipos