Backup WordPress por plugin e backup via script com checagem de integridade diferem no ponto em que rodam e no que garantem: o plugin executa dentro do PHP e não valida o arquivo gerado, enquanto o script no Debian 13 usa mysqldump, tar e sha256sum fora do PHP e comprova que a cópia é restaurável. Para montar a rotina com verificação automática, siga estes passos:
- Instale mariadb-client, gzip e mailutils no Debian 13.
- Crie um script que gere o dump SQL e o tar.gz do wp-content.
- Gere hashes SHA-256 e teste a compressão com gzip -t.
- Faça o script sair com erro e enviar alerta se algo falhar.
- Agende no cron do sistema e envie a cópia para destino remoto.
- Teste a restauração em ambiente separado pelo menos uma vez.
Pré-requisitos
- Servidor com Debian 13 e acesso root ou sudo via SSH (veja Acessando servidores VPS Linux da AviraHost).
- WordPress instalado em /var/www/seudominio.com.br com PHP 8.4 e MariaDB 11.8 (ou MySQL 8.4).
- Credenciais do banco em wp-config.php e espaço em disco livre equivalente ao dobro do tamanho do site.
- Pacotes: mariadb-client, tar, gzip, coreutils (sha256sum), mailutils ou rclone para o destino remoto.
- Um diretório fora da raiz web para os backups, por exemplo /var/backups/wordpress.
Comparativo: backup WordPress com checagem de integridade — plugin vs script
O backup automático do WordPress por plugin é a escolha padrão de quem não tem acesso ao shell, mas tem limitações estruturais que ficam evidentes em sites com muitos uploads. Abaixo, o que muda entre as duas abordagens no Debian 13:
- Onde executa: plugin roda dentro do PHP-FPM, sujeito a max_execution_time e memory_limit; script roda como processo do sistema, sem esses limites.
- Agendamento: plugin depende do WP-Cron, que só dispara quando alguém visita o site; script usa o cron do Debian, que dispara no horário exato.
- Validação do arquivo: plugin normalmente só confirma que o arquivo existe; script pode rodar sha256sum -c, gzip -t e um teste de importação do SQL.
- Arquivos truncados: plugin pode gerar zip incompleto quando o PHP é encerrado por timeout; script detecta via gzip -t e descarta a cópia.
- Destino remoto: plugin costuma exigir versão paga; script envia com rclone ou rsync por SSH sem custo adicional.
- Carga no site: plugin compete com visitantes pelos mesmos workers PHP; script pode ser agendado com nice e ionice.
Na prática, ao executar um backup por plugin em um site com 8 GB de mídia, você verá o job “concluído” no painel e só descobre o zip truncado na hora de restaurar. O script com checagem falha imediatamente e avisa. Se sua hospedagem for compartilhada sem SSH, o plugin ainda é a opção viável; em VPS ou dedicado com Debian 13, o script é superior em confiabilidade.
Script de backup do WordPress com mysqldump e tar no Debian 13
A rotina de backup via linha de comando começa instalando as dependências e criando o script. Instale os pacotes:
sudo apt update && sudo apt install -y mariadb-client gzip mailutils
sudo mkdir -p /var/backups/wordpress && sudo chmod 700 /var/backups/wordpressCrie o arquivo /usr/local/bin/wp-backup.sh com o conteúdo abaixo, ajustando o caminho do site e as credenciais lidas do wp-config.php:
#!/bin/bash
set -euo pipefail
SITE=/var/www/seudominio.com.br
DEST=/var/backups/wordpress
DATA=$(date +%Y%m%d-%H%M)
DBNAME=$(grep DB_NAME "$SITE/wp-config.php" | cut -d "'" -f4)
DBUSER=$(grep DB_USER "$SITE/wp-config.php" | cut -d "'" -f4)
DBPASS=$(grep DB_PASSWORD "$SITE/wp-config.php" | cut -d "'" -f4)
[email protected]
cd "$DEST"
mysqldump --single-transaction --quick --routines \
-u"$DBUSER" -p"$DBPASS" "$DBNAME" | gzip -9 > "db-$DATA.sql.gz"
tar -czf "files-$DATA.tar.gz" -C "$SITE" wp-content wp-config.php .htaccess
sha256sum "db-$DATA.sql.gz" "files-$DATA.tar.gz" > "backup-$DATA.sha256"
echo "Backup $DATA criado"Dê permissão de execução e rode manualmente para validar:
sudo chmod 700 /usr/local/bin/wp-backup.sh
sudo /usr/local/bin/wp-backup.sh
ls -lh /var/backups/wordpressBackup 20260312-0300 criado
-rw-r--r-- 1 root root 42M mar 12 03:00 db-20260312-0300.sql.gz
-rw-r--r-- 1 root root 1,8G mar 12 03:00 files-20260312-0300.tar.gz
-rw-r--r-- 1 root root 210 mar 12 03:00 backup-20260312-0300.sha256A flag --single-transaction garante dump consistente das tabelas InnoDB sem travar o site, e o set -euo pipefail faz o script abortar no primeiro erro, evitando hashes de arquivos incompletos.
Verificação automática de integridade com sha256sum e gzip -t
A checagem de integridade do backup é o que diferencia esta rotina de um simples tar agendado. Adicione ao final do script, antes do echo, o bloco de testes:
ERRO=0
sha256sum -c "backup-$DATA.sha256" --quiet || ERRO=1
gzip -t "db-$DATA.sql.gz" || ERRO=1
gzip -t "files-$DATA.tar.gz" || ERRO=1
tar -tzf "files-$DATA.tar.gz" > /dev/null || ERRO=1
zcat "db-$DATA.sql.gz" | tail -n 5 | grep -q "Dump completed" || ERRO=1
if [ "$ERRO" -ne 0 ]; then
echo "FALHA de integridade no backup $DATA" | mail -s "[BACKUP] ERRO seudominio.com.br" "$ALERTA"
logger -t wp-backup "falha de integridade em $DATA"
exit 1
fi
find "$DEST" -type f -mtime +14 -deleteCada teste cobre uma falha distinta: sha256sum -c detecta corrupção posterior à criação, gzip -t valida a compressão, tar -tzf lê o índice completo do arquivo e a busca por “Dump completed” confirma que o mysqldump chegou ao fim. Rode novamente e observe:
sudo /usr/local/bin/wp-backup.sh && echo "exit=$?"Backup 20260312-0312 criado
exit=0Atenção: a linha find com -delete remove backups com mais de 14 dias. Ajuste o valor antes de agendar e confirme que $DEST aponta para o diretório correto — um caminho errado apaga arquivos de outro lugar.
Agendar no cron do Debian 13 e enviar para destino remoto
O agendamento de backup com cron no Debian 13 deve rodar fora do horário de pico e com prioridade reduzida. Crie o arquivo /etc/cron.d/wp-backup:
echo '0 3 * * * root nice -n 19 ionice -c3 /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1' | sudo tee /etc/cron.d/wp-backup
sudo systemctl status cron --no-pager | head -n 3● cron.service - Regular background program processing daemon
Loaded: loaded (/usr/lib/systemd/system/cron.service; enabled)
Active: active (running)Para a cópia remota, instale o rclone, configure um remote (S3, Backblaze ou SFTP) com rclone config e acrescente ao script, após a verificação passar:
rclone copy "$DEST" remoto:backups-wp/seudominio.com.br --include "*$DATA*"
rclone check "$DEST" remoto:backups-wp/seudominio.com.br --include "*$DATA*"O rclone check compara hashes entre origem e destino, então a integridade é confirmada também após o upload. Se o WordPress usar banco em outro host, como em instalações com acesso remoto ao MySQL via cPanel, adicione -h com o endereço do servidor no mysqldump.
Problemas comuns e como resolver
Sintoma: mysqldump retorna “Access denied for user”
Causa: o grep no wp-config.php capturou aspas duplas em vez de simples, ou o usuário do banco não tem privilégio PROCESS/LOCK TABLES.
Solução: confira com grep DB_ /var/www/seudominio.com.br/wp-config.php o tipo de aspas usado e ajuste o cut. Se o erro persistir, conceda GRANT SELECT, LOCK TABLES, SHOW VIEW, TRIGGER ON banco.* TO 'usuario'@'localhost';.
Sintoma: gzip -t falha com “unexpected end of file”
Causa: disco cheio durante a escrita ou o processo foi morto pelo OOM killer em VPS com pouca RAM.
Solução: verifique df -h /var/backups e journalctl -k | grep -i "out of memory". Libere espaço, reduza o nível de compressão para gzip -6 e mantenha o nice/ionice no cron.
Sintoma: o cron não executa, mas o script roda manualmente
Causa: PATH reduzido no ambiente do cron ou arquivo em /etc/cron.d sem o campo de usuário.
Solução: use caminhos absolutos (/usr/bin/mysqldump) no script e confirme que a linha em /etc/cron.d tem o campo root antes do comando. Verifique grep CRON /var/log/syslog ou journalctl -u cron.
Sintoma: alerta por e-mail nunca chega
Causa: o Debian 13 não instala MTA por padrão; mailutils sem Postfix ou relay configurado não entrega nada.
Solução: instale e configure um relay SMTP conforme o passo a passo para configurar servidor de e-mail no VPS Linux, ou substitua o mail por um webhook curl para Telegram ou Slack.
Perguntas frequentes sobre backup WordPress com checagem de integridade
Como verificar se o backup do WordPress está íntegro automaticamente?
Gere um hash SHA-256 com sha256sum logo após criar o arquivo .tar.gz e o dump SQL, salve o hash em um arquivo .sha256 ao lado do backup e agende no cron um script que execute sha256sum -c e gzip -t. Se algum teste falhar, o script deve sair com código diferente de zero e disparar um alerta por e-mail ou log, sinalizando que o arquivo não pode ser usado para restauração.
Qual a diferença entre backup por plugin e backup via script no servidor?
O backup por plugin roda dentro do PHP, depende do WP-Cron e dos limites de memória e tempo de execução do WordPress, o que pode gerar arquivos truncados em sites grandes. O backup via script com mysqldump, tar e cron roda fora do PHP, com acesso total ao sistema, permite verificação de integridade com hashes e pode enviar cópias para destino remoto sem carregar o site.
Com que frequência devo rodar o backup do WordPress no Debian 13?
Depende da frequência de alterações: lojas WooCommerce e portais com publicação diária costumam exigir dump do banco a cada poucas horas e arquivos uma vez ao dia. Sites institucionais estáticos ficam bem com uma rotina diária. O importante é que a retenção cubra o tempo que você levaria para perceber um problema.
Preciso testar a restauração mesmo com a checagem de hash passando?
Sim. O hash prova que o arquivo não mudou desde a criação, e o gzip -t prova que ele descompacta, mas nenhum dos dois garante que o conteúdo é suficiente para subir o site. Importe o dump em um banco de teste e extraia o tar em um diretório temporário pelo menos uma vez por mês.
Conclusão
- Em Debian 13 com acesso SSH, prefira o script com mysqldump, tar e sha256sum ao plugin: ele valida o arquivo e não depende de visitas ao site.
- Faça o script falhar de forma explícita (exit 1 e alerta) para que um backup corrompido nunca passe despercebido.
- Envie a cópia para um destino remoto com rclone check e agende um teste real de restauração periodicamente.
Leia também
- Backup MariaDB Docker com rsync: automação e integridade
- Passo a passo para configurar backup automático com cron no VPS Linux e servidor dedicado
- Entenda backup Linux com snapshots: rotina e verificação
Precisa de ajuda com backup do WordPress?
Se preferir não manter scripts e cron por conta própria, a hospedagem de sites da AviraHost inclui rotinas de backup gerenciadas e suporte para orientar a restauração quando necessário.
