# Backup do banco de dados WordPress em 5 passos seguros 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.

Backup do banco de dados WordPress: método por cenário
Método Quando usar Limite conhecido
phpMyAdminBackup manual pontual antes de um updateTrava acima de 200 MB por timeout do PHP
WP-CLI (mysqldump)Bancos grandes e lojas WooCommerceExige acesso SSH ao servidor
UpdraftPlusAgendamento automático com destino em nuvemBackup infla se transients não forem limpos
DuplicatorMigração de banco e arquivos juntosPacote exposto se ficar em pasta pública
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. ---

Perguntas frequentes sobre backup do banco de dados

Por que restaurar só o banco de dados quebra o site às vezes?

Porque o banco de dados guarda a URL do site nas linhas siteurl e home da tabela wp_options. Se você restaura uma cópia de produção num domínio diferente sem ajustar esses dois valores, o WordPress entra em loop de redirecionamento. O outro motivo é prefixo de tabela: se o backup usa wp_abc_ e o wp-config.php espera wp_, o site não encontra as tabelas.

É possível fazer backup do banco de dados sem instalar plugin?

Sim, e é o método mais leve. Pelo phpMyAdmin você exporta o banco em formato .sql direto do painel de hospedagem, sem plugin algum. Para bancos acima de 200 MB, o caminho sem plugin é o WP-CLI com o comando wp db export, que não esbarra no limite de memória do PHP. Ambos geram um arquivo que você guarda fora do servidor.

Qual a diferença entre backup do banco de dados e backup completo?

O backup do banco de dados copia só o MySQL: posts, usuários, configurações e pedidos. O backup completo inclui também os arquivos: tema, plugins, uploads e o wp-config.php. Para reverter um update de conteúdo, o banco basta. Para recuperar de uma invasão que alterou arquivos PHP, você precisa dos dois. Restaurar só o banco num site com arquivos corrompidos não resolve.

Com que frequência devo agendar o backup do banco de dados?

Depende da frequência de mudança. Um blog que publica semanalmente fica bem com backup diário do banco. Uma loja WooCommerce que recebe pedidos a cada hora precisa de backup do banco a cada 4 ou 6 horas, senão um problema às 18h apaga uma tarde inteira de vendas. A regra prática: a janela entre backups não pode ser maior que o prejuízo aceitável de dados perdidos.

O que fazer se o backup do banco de dados restaurar pela metade?

Pare e cheque o arquivo de origem antes de tentar de novo. Um backup que restaura parcialmente quase sempre veio truncado: o export pelo phpMyAdmin estourou o timeout do PHP e o arquivo .sql termina no meio de um INSERT INTO. Abra o arquivo num editor e confirme se a última linha fecha o dump. Se truncou, refaça o export por WP-CLI, que não tem esse limite de tempo.

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