O backup do banco de dados WordPress protege posts, usuários e pedidos: faça por phpMyAdmin, WP-CLI ou UpdraftPlus. Segundo o NVD (NIST) (2024), plugins de backup somam dezenas de CVEs, com falhas de CVSS 9.8. Um export truncado restaura pela metade sem aviso acima de 200 MB. Valide cada cópia.

O backup do banco de dados WordPress é a cópia da estrutura MySQL que guarda posts, comentários, usuários, configurações e pedidos do WooCommerce. Sem ele, um update mal sucedido ou uma invasão apaga conteúdo que nenhum arquivo PHP recupera. Este tutorial mostra cinco caminhos testados para exportar e restaurar o banco com segurança, do phpMyAdmin manual ao agendamento automático. Cobre os erros que truncam o export, os CVEs reais dos plugins de backup e como a FULL trata isso no guias de segurança WordPress da FULL. A meta é simples: nunca descobrir que o backup estava corrompido no dia em que você precisa dele.

Primeiros passos: Visão geral do backup do banco de dados

Existem três métodos para o backup do banco de dados, e a escolha depende de acesso e volume. Na maioria dos tickets de restauração que chegam à FULL (base de 150 mil sites), o problema não foi a falta de backup, mas um backup nunca validado. A tabela abaixo separa o método por cenário antes de você abrir qualquer ferramenta.

Legenda: a aba Exportar do phpMyAdmin gera o arquivo .sql que contém todo o banco de dados do site.

A regra que vale para os três: o backup do banco de dados só existe depois que você restaura uma cópia num ambiente de teste e o site abre.

Como fazer backup do banco de dados pelo phpMyAdmin em 4 etapas

O phpMyAdmin exporta o banco de dados em formato .sql sem instalar nada, e funciona bem até cerca de 200 MB. Acima disso, o limite de max_execution_time do PHP corta o processo no meio e gera um arquivo truncado que restaura pela metade, sem mensagem de erro. Para sites pequenos e médios, ainda é o caminho mais direto. Os passos abaixo cobrem o export limpo e seguro.

Passo 1: Acesse o phpMyAdmin pelo painel

Entre no painel de hospedagem (cPanel, Plesk ou similar) e abra o phpMyAdmin. No menu lateral, clique no nome do banco de dados do seu site. Você confere qual banco é pelo arquivo wp-config.php, na constante DB_NAME. Selecionar o banco errado é a falha número um em ambientes com múltiplos sites no mesmo servidor.

Passo 2: Escolha o método de exportação personalizado

Na aba Exportar, troque o método de Rápido para Personalizado. Isso libera a escolha do formato SQL e a opção de adicionar DROP TABLE, que evita conflito de tabela duplicada na hora de restaurar. Marque todas as tabelas com o prefixo do seu site, geralmente wp_, mas confira porque muitos sites usam prefixo customizado por segurança.

Passo 3: Compacte e baixe o arquivo SQL

Selecione a compressão gzip antes de exportar. Um banco de dados de 80 MB cai para algo perto de 12 MB compactado, o que reduz o risco de timeout no download. Clique em Exportar e guarde o arquivo .sql.gz fora do servidor, de preferência num destino que você controle e não no mesmo disco do site.

Passo 4: Confira a integridade do arquivo

Abra o arquivo com um editor de texto e verifique se a última linha contém um comentário de fechamento do dump. Se o arquivo termina no meio de um INSERT INTO, o export truncou e a cópia é inútil. Esse teste de 30 segundos evita a situação mais comum nos tickets da FULL: o backup que parecia pronto e falhou na restauração.

WP-CLI: O backup do banco de dados que não trava em sites grandes

O WP-CLI resolve o backup do banco de dados onde o phpMyAdmin falha por memória. Em lojas WooCommerce com mais de 50 mil pedidos, o export pelo navegador estoura o memory_limit do PHP antes de terminar, e o WP-CLI não tem esse teto. É o método mais recomendado nos chamados de e-commerce da FULL.

O comando wp db export --single-transaction trava a leitura sem bloquear a escrita, então a loja segue vendendo durante o backup.

A linha de comando é direta: wp db export backup-banco.sql --single-transaction. A flag garante consistência transacional no MySQL 8.0 e no MariaDB, evitando o backup que captura metade de um pedido em andamento. Para agendar, combine o WP-CLI com um cron do sistema rodando de madrugada, quando o tráfego é menor. Esse é o mesmo princípio que usamos para otimizar o banco de dados antes do backup, reduzindo o tamanho do dump.

UpdraftPlus e Duplicator: Automatizando o backup do banco de dados

O UpdraftPlus automatiza o backup do banco de dados com agendamento e envio para nuvem em poucos cliques, e é o plugin mais usado na base FULL para essa tarefa. Ele separa o backup do banco do backup de arquivos, o que reduz o pacote quando você só precisa da cópia do MySQL. O cuidado técnico está na tabela wp_options: sem limpar transients expirados antes, o backup infla e estoura a cota do destino. Veja o guia de configuração do UpdraftPlus para o agendamento correto. O Duplicator, por sua vez, empacota banco e arquivos juntos para migração entre servidores, mas expõe o pacote se ele ficar numa pasta pública sem .htaccess.

> Nota de especialista: em VPS abaixo de 2GB de RAM rodando UpdraftPlus com backup completo agendado no mesmo horário do cron de e-mail, o pico de CPU tende a derrubar o serviço de MySQL por alguns segundos. A configuração estável é agendar o backup do banco às 3h e o de arquivos às 4h, nunca simultâneos.

Segurança dos plugins de backup: Cves reais e o que eles ensinam

Os plugins de backup do banco de dados já tiveram falhas críticas de CVSS 9.8, e conhecer o histórico evita repetir o erro de não atualizar. A FULL é a única empresa brasileira credenciada como CVE Numbering Authority (CNA) sob a CISA desde maio de 2022, autorizada a atribuir IDs CVE oficiais.

Quem escreve aqui sobre vulnerabilidade literalmente cataloga CVE. Por isso a distinção importa: risco atual é falha sem patch hoje, não o total histórico de um plugin auditado.

O Duplicator carrega o caso mais grave do histórico. A CVE-2018-17207, com CVSS 9.8 (crítica), permitia injeção de código em versões anteriores à 1.2.42 e foi corrigida no patch dessa versão. Já a CVE-2018-25095, também CVSS 9.8, afetava versões abaixo da 1.3.0. Hoje, segundo o perfil público do WPVulnerability, o Duplicator está sem CVE em aberto, o que indica manutenção ativa.

O UpdraftPlus registra a CVE-2024-10957, CVSS 8.8 (alta), corrigida na versão 1.24.12. Nenhuma dessas falhas é risco atual: as 26 CVEs históricas do UpdraftPlus estão corrigidas, sinal positivo de auditoria contínua. A lição é direta: plugin de backup desatualizado vira porta de entrada.

Restauração: O lado do backup do banco de dados que ninguém testa

Restaurar o banco de dados quebra o site se o prefixo de tabela ou a URL no wp_options não baterem, e esse é o gap que poucos tutoriais cobrem. O backup guarda a URL do site em duas linhas: siteurl e home.

Restaurar uma cópia de produção num domínio de teste sem ajustar esses valores gera o clássico loop de redirecionamento, ou o erro de conexão com o banco de dados quando as credenciais mudam.

A restauração segura tem ordem: primeiro importe o .sql num banco vazio, depois ajuste siteurl e home, e só então aponte o wp-config.php para o banco novo. Se o backup veio com prefixo wp_abc_ e o wp-config.php espera wp_, o WordPress não acha as tabelas e mostra a tela de instalação como se fosse um site novo. O passo a passo completo está em como restaurar o WordPress a partir do backup, e vale testar a rotina em um ambiente isolado antes de precisar dela de verdade.

Backup gerenciado: Quando faz sentido tirar isso das suas mãos

Manter rotina de backup do banco de dados em vários sites consome tempo que escala mal, e é aí que o backup gerenciado entra. No suporte da FULL, a gente vê que o ponto de virada fica entre 5 e 10 sites: acima disso, agendar e validar manualmente vira meio período de trabalho.

O plano PRO da FULL custa R$849 e inclui backup gerenciado no bundle com mais 16 plugins, o que dá cerca de R$85 por site quando você divide entre 10 instalações.

O argumento de R$85 por site pesa porque a licença avulsa de um único plugin premium de backup já passa disso por ano. Veja os planos da FULL se a operação passou do ponto em que o backup manual compensa. Importante: a FULL gerencia e protege os sites, não é o serviço de hospedagem. O backup gerenciado roda sobre a sua hospedagem atual, como camada de proteção.

Decisão rápida: Qual método de backup usar

A escolha do método de backup do banco de dados se resume a quatro variáveis: tamanho do banco, frequência de mudança, número de sites e seu acesso ao servidor. A árvore abaixo cruza esses fatores em decisões diretas, cada uma testada nos cenários que mais aparecem no suporte da FULL ao longo de 2026. Use a primeira condição que descrever seu caso.

• Se você faz backup pontual antes de um update num site pequeno → use o phpMyAdmin com compressão gzip.
• Se o banco passa de 200 MB ou é loja WooCommerce → use WP-CLI com a flag –single-transaction.
• Se você precisa de agendamento automático e destino em nuvem → evite export manual, configure o UpdraftPlus.
• Se você gerencia mais de 5 sites → considere backup gerenciado no bundle FULL.

Perguntas frequentes sobre backup do banco de dados

Próximos passos para proteger seus dados

Backup do banco de dados WordPress não é tarefa de uma vez, é rotina com validação. O método certo depende do tamanho do banco e do seu acesso ao servidor: phpMyAdmin para o pontual, WP-CLI para o grande, UpdraftPlus para o automático. O ponto que separa quem tem backup de quem só acha que tem é a restauração testada num ambiente isolado, antes da emergência. Combine isso com a rotina de backup automático do WordPress e mantenha os plugins de backup sempre atualizados, já que eles mesmos são alvo de CVE. Para aprofundar, o FULL Academy reúne os tutoriais de segurança num só lugar, e o FULL Scan verifica de graça se algum plugin do seu site está vulnerável.