Como Fazer Backup de um Site WordPress

Um backup completo do WordPress é uma cópia de duas coisas capturadas em conjunto: seus arquivos e seu banco de dados MySQL. Se um deles for esquecido, a restauração falha. Este guia aborda a maneira confiável de fazer isso pela linha de comando — mysqldump, tar e um cron job que envia os arquivos para fora do servidor — para que você seja o dono do backup em vez de depender de um plugin. Ele também aborda de forma imparcial as opções de hospedagem e plugins, e mostra os comandos de restauração que comprovam que um backup realmente funciona.

O que um backup completo do WordPress inclui?

Um site WordPress é composto por dois sistemas separados, e um backup precisa capturar ambos. Os arquivos incluem o core do WordPress, tudo que está em wp-content — seus temas, plugins e a pasta uploads (geralmente a maior parte) — além do arquivo wp-config.php na raiz. No Apache, você também precisa salvar o .htaccess; no nginx ou Caddy não há .htaccess para salvar, pois os redirecionamentos ficam na configuração do servidor, fora da raiz web. O banco de dados é um banco MySQL que armazena seus posts, páginas, comentários, usuários, taxonomias e todas as configurações de plugins e temas.

O erro mais comum entre iniciantes é fazer backup dos arquivos via FTP e esquecer o banco de dados. Temas e o core podem ser baixados novamente; seu conteúdo, não. Se um “backup” contém apenas arquivos, o site restaurado carregará sem nenhum post e sem nenhuma configuração.

Quais são as três formas de fazer backup do WordPress?

Existem três abordagens práticas, e elas trocam conveniência por controle.

Backups do host são convenientes, mas não devem ser sua única cópia — os períodos de retenção são curtos e, se o servidor for comprometido ou falhar, os backups armazenados nele podem ser perdidos junto. Plugins como o UpdraftPlus gerenciam o agendamento e o upload para a nuvem pelo painel e são uma escolha razoável para usuários não técnicos. A abordagem via CLI é a que um desenvolvedor pode versionar, agendar e auditar.

Fazer backup do WordPress pela linha de comando

O backup pela linha de comando é feito em três etapas via SSH: fazer o dump do banco de dados, arquivar os arquivos e, em seguida, transferir ambos para fora do servidor. Conecte-se primeiro:

ssh user@example.com -p 2222

Em seguida, arquive os arquivos e faça o dump do banco de dados:

# Arquiva os arquivos do site a partir do diretório acima da raiz web
tar -zcf files.tar.gz public_html

# Faz o dump do banco de dados com um snapshot consistente
mysqldump --single-transaction -u DB_USER -p DB_NAME > db.sql

A flag --single-transaction é o que torna o dump confiável em um site em produção. Apenas tabelas InnoDB são exportadas em um estado consistente; tabelas MyISAM ou MEMORY podem ainda sofrer alterações durante o dump. Como o WordPress utiliza InnoDB por padrão, --single-transaction é uma opção muito melhor do que --lock-tables, pois não precisa bloquear as tabelas — seu site permanece no ar durante a execução. Use mysqldump, não mysqlpump — este último foi removido no MySQL 8.4, portanto scripts que o utilizam simplesmente falharão em servidores atuais.

Transfira ambos os arquivos com scp:

scp -P 2222 user@example.com:~/files.tar.gz .
scp -P 2222 user@example.com:~/db.sql .

Um detalhe que os tutoriais costumam ignorar: scp usa -P maiúsculo para a porta, enquanto ssh e mysqldump usam -p minúsculo (porta e senha, respectivamente). Confundi-los é um erro clássico que faz o comando falhar.

Se você tiver o WP-CLI, wp db export é mais prático: ele executa o utilitário mysqldump usando as credenciais DB_HOST, DB_NAME, DB_USER e DB_PASSWORD definidas no wp-config.php, e aceita qualquer flag válida do mysqldump.

wp db export --single-transaction db.sql

Em hosts gerenciados e com cPanel, um mysqldump simples pode falhar com um erro de privilégio PROCESS ao exportar tablespaces. O WP-CLI já lida com isso: wp db export adiciona --no-tablespaces ao mysqldump por padrão. Ao usar mysqldump diretamente em um host gerenciado, adicione --no-tablespaces manualmente.

Automatizar backups do WordPress com cron e rclone

Automatize todo o processo com um shell script curto em um agendamento cron que faz o dump do banco de dados, compacta o wp-content com tar e envia o arquivo para fora do servidor. O rclone — “rsync para armazenamento em nuvem” — suporta S3, Backblaze B2, Google Drive, entre outros.

#!/usr/bin/env bash
set -euo pipefail

SITE_DIR="/var/www/example.com"
DEST="b2remote:example-backups"     # um remote configurado no rclone
STAMP="$(date +%F)"
WORK="$(mktemp -d)"

cd "$SITE_DIR"

# Banco de dados — o WP-CLI lê as credenciais do wp-config.php
wp db export --single-transaction "$WORK/db-$STAMP.sql"

# Arquivos — temas, plugins, uploads e configuração
tar -zcf "$WORK/wp-content-$STAMP.tar.gz" wp-content wp-config.php

# Envia para fora do servidor
rclone copy "$WORK" "$DEST/$STAMP"

rm -rf "$WORK"

Agende com uma linha no crontab que executa diariamente às 03:15 e registra a saída em log:

15 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1

Essa é a vantagem de ter controle total sobre seus backups: sem painel, sem plugin, sem etapa manual. Se o WP-CLI não estiver instalado, substitua a linha de exportação por mysqldump --single-transaction --no-tablespaces -u DB_USER -pPASS DB_NAME > "$WORK/db-$STAMP.sql".

Armazenar backups seguindo a regra 3-2-1

Siga a regra 3-2-1: mantenha pelo menos três cópias do seu site, em dois tipos diferentes de mídia, com uma cópia off-site. Nunca deixe o único backup no mesmo servidor do site — um ataque ou falha de disco elimina ambos de uma vez. É exatamente por isso que o script de automação acima envia os dados para um armazenamento de objetos em vez de deixar o arquivo na raiz web. Como o arquivo contém uma cópia completa do seu site, incluindo segredos presentes no wp-config.php, proteja o destino com credenciais fortes e autenticação de dois fatores na conta de armazenamento.

Testar a restauração e os erros a evitar

Um backup não testado não é um backup. Periodicamente, restaure seu arquivo .sql e o arquivo compactado em um ambiente de staging ou local para comprovar que a cópia realmente reconstrói o site:

tar -xzf wp-content-2026-07-06.tar.gz
wp db import db-2026-07-06.sql          # ou, sem o WP-CLI:
mysql -u DB_USER -p DB_NAME < db-2026-07-06.sql

Três falhas são responsáveis pela maioria dos sites perdidos: fazer backup dos arquivos sem o banco de dados, manter o backup no mesmo servidor do site e confiar apenas nos backups automáticos do host. Cada uma delas pode ser evitada com o fluxo de trabalho descrito acima.

O padrão confiável é simples e direto: um cron job que faz o dump consistente do banco de dados, compacta os arquivos, envia ambos para fora do servidor e uma restauração que você realmente testa. Escreva o script uma vez, aponte-o para um armazenamento de objetos, adicione a linha no crontab e faça um teste de restauração esta semana — esse é um backup que você controla, não um que você torce para estar funcionando.

Perguntas Frequentes

Qual é a diferença entre wp db export e executar o mysqldump diretamente?

wp db export é um wrapper simples sobre o mysqldump. Ele executa o utilitário mysqldump usando as credenciais DB_HOST, DB_NAME, DB_USER e DB_PASSWORD já armazenadas no wp-config.php, dispensando a necessidade de informar ou passar os detalhes de conexão manualmente, e aceita qualquer flag válida do mysqldump. Ele também adiciona --no-tablespaces por padrão, evitando o erro de privilégio PROCESS comum em hosts gerenciados. O mysqldump direto gera o mesmo dump, mas exige que você forneça as credenciais e flags manualmente.

Por que o mysqldump gera um erro de privilégio PROCESS em hosts gerenciados e como corrigir?

Em hosts gerenciados e com cPanel, o mysqldump tenta exportar informações de tablespace, o que requer o privilégio PROCESS que usuários de banco de dados compartilhados geralmente não possuem, gerando o erro 'Access denied; you need the PROCESS privilege'. Adicione a flag --no-tablespaces para ignorar essa etapa e o dump será concluído normalmente. O wp db export do WP-CLI adiciona --no-tablespaces automaticamente. Na maioria dos casos, a exportação é concluída com sucesso mesmo com o erro, portanto verifique o dump confirmando que suas tabelas estão presentes.

Posso ignorar o backup dos arquivos já que o core e os plugins do WordPress podem ser baixados novamente?

Você pode reduzir o que arquiva, mas nunca ignore os arquivos completamente. O core, os temas e os plugins do WordPress podem ser baixados novamente de suas fontes, então algumas ferramentas de backup armazenam apenas o banco de dados mais a pasta uploads. No entanto, a pasta uploads contém todas as mídias que não podem ser baixadas novamente, o wp-config.php contém suas credenciais de banco de dados e chaves de segurança, e quaisquer arquivos personalizados ou modificados são insubstituíveis. Fazer backup de wp-content e wp-config.php captura as partes que são genuinamente exclusivas do seu site.

Como restaurar um site WordPress a partir de um backup mysqldump e tar?

Extraia o arquivo compactado no diretório do site com tar -xzf archive.tar.gz e, em seguida, importe o banco de dados. Com o WP-CLI, execute wp db import db.sql, que lê as credenciais do wp-config.php. Sem o WP-CLI, execute mysql -u DB_USER -p DB_NAME < db.sql em um banco de dados existente. Restaure ambas as partes juntas e, se o domínio tiver mudado, execute um search-replace no banco de dados para atualizar as URLs armazenadas. Sempre teste a restauração em um ambiente de staging ou local antes de confiar nela em produção.

O mysqldump ainda é seguro de usar ou devo migrar para o mysqlpump?

Use mysqldump, não mysqlpump. O utilitário mysqlpump foi descontinuado no MySQL 8.0.34 e removido completamente no MySQL 8.4, portanto scripts que o utilizam falham em servidores atuais. O mysqldump permanece suportado e atualizado; o MySQL recomenda o mysqldump ou os utilitários de dump do MySQL Shell como substitutos. Para um snapshot consistente de um site InnoDB em produção, execute o mysqldump com a flag --single-transaction, que evita o bloqueio de tabelas durante o dump.