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

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

Erros relacionados

- [Como corrigir backup que falha no UpdraftPlus](https://full.services/wp-fixer/corrigir-backup-falho-updraftplus/)
- [Como corrigir a falha de backup do banco no WP-Optimize](https://full.services/wp-fixer/corrigir-falha-backup-banco-wp-optimize/)
- [Como corrigir o erro de permissão ao limpar o banco no WP-Optimize](https://full.services/wp-fixer/corrigir-permissao-limpeza-banco-wp-optimize/)

## 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

1. 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.
2. 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
```

3. 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
```

4. 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
```

5. 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
```

6. 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.

## Código

```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.

**Fonte:** [WP Rocket — Database Optimizations](https://docs.wp-rocket.me/article/1672-database-optimizations)