Backup automático no WordPress: rotina 3-2-1 testada

# Backup automático no WordPress: rotina 3-2-1 confiável e testada

_Por equipe WordPress DEV Teste — publicado em maio de 2026._

## Resposta rápida: como configurar backups automáticos confiáveis no WordPress

Uma rotina de backup WordPress que realmente salva o site na hora da crise tem cinco componentes obrigatórios: (1) cobertura completa de **arquivos + banco de dados + wp-config.php**, exportando o banco antes dos arquivos como recomenda o Advanced Administration Handbook do WordPress; (2) **frequência alinhada ao ritmo de mudança** (diária para blog ativo, contínua/horária para WooCommerce, semanal para institucional estático); (3) **destino off-site** seguindo a regra 3-2-1 do CISA — 3 cópias, 2 mídias, 1 fora do servidor; (4) **automação** via UpdraftPlus, BackWPup ou WP-CLI + cron; e (5) **drill de restauração trimestral em staging**, porque backup não testado não é backup. Os comandos copiáveis, o comparativo de plugins gratuitos e o checklist final estão abaixo.

## O que precisa entrar no backup: arquivos, banco e wp-config

Um WordPress vive em duas camadas, e backup parcial deixa o site irrecuperável. A documentação oficial de Backups do WordPress Advanced Administration Handbook recomenda exportar o **banco de dados primeiro** e em seguida os **arquivos**, mantendo as duas peças juntas no mesmo conjunto.

O que precisa estar no pacote:

– **Banco de dados MySQL/MariaDB**: posts, páginas, comentários, usuários, opções (`wp_options`), metadados de plugins e WooCommerce. É onde mora 100% do conteúdo editorial.
– **wp-content/**: temas, plugins e — crucialmente — `uploads/` (todas as imagens e mídias).
– **wp-config.php**: credenciais do banco, chaves SALT, prefixo da tabela. Sem ele, restaurar é remontar à mão.
– **.htaccess** (Apache) ou snippets de configuração equivalentes (Nginx), além de `mu-plugins/` se existir.
– **Core do WordPress**: opcional do ponto de vista lógico (pode ser rebaixado do wordpress.org), mas inclua para restauração mais rápida.

Backup só do banco basta quando o conteúdo muda e os arquivos ficam estáveis. No momento em que você instala um plugin, troca o tema ou um cliente sobe um PDF para a biblioteca de mídia, o backup de banco isolado deixa de ser suficiente — é o que a documentação da Automattic reforça em seu guia de backup de 2025.

## Frequência ideal por tipo de site

A regra é simples: **a frequência do backup é igual à tolerância de perda de dados** (RPO). Quanto vale o conteúdo das últimas 24 horas? Se a resposta for “muito”, não rode backup diário.

Para lojas, plugins gratuitos com agendamento fixo (UpdraftPlus, BackWPup) não cobrem o gap entre execuções — nesses casos vale considerar backup incremental contínuo (recurso pago no UpdraftPlus Premium ou Jetpack VaultPress) ou replicação no nível do banco (binlog do MySQL).

## Aplicando a regra 3-2-1 do CISA ao WordPress

A regra 3-2-1, formalizada pelo CISA no documento *Data Backup Options* e reproduzida por fornecedores como Veeam e Huntress, diz: mantenha **3 cópias** dos dados, em **2 mídias diferentes**, com **pelo menos 1 cópia off-site**. A evolução moderna é **3-2-1-1-0**: acrescenta-se 1 cópia imutável (write-once, contra ransomware) e 0 erros nos testes de verificação.

No WordPress isso vira:

– **Cópia 1**: backup local no servidor (rápido para restaurar acidentes pequenos).
– **Cópia 2**: cópia em outra mídia — por exemplo, sincronizada para sua máquina de trabalho via rclone, ou em um volume separado.
– **Cópia 3 (off-site)**: bucket S3, Backblaze B2, Google Drive ou outro storage fora da hospedagem.
– **+1 imutável**: bucket S3 com Object Lock ou B2 com retention lock, que o ransomware não consegue sobrescrever.
– **+0 erros**: drill de restauração que valida o dump.

Um backup que vive apenas em `/home/usuario/backups/` do mesmo servidor da hospedagem **não atende ao requisito off-site**. Se o disco falha, a conta é suspensa por inadimplência ou um invasor obtém acesso root, o backup vai junto. Esse é o erro mais comum em hospedagem compartilhada brasileira — e o motivo de existir o nosso guia dedicado de [backup WordPress com a regra 3-2-1 em produção](https://wordpress.fabricandocursos.com.br/backup-wordpress-regra-321-producao/).

## Onde guardar: comparativo de destinos externos

Matriz de destinos para um site WordPress típico de 50 GB/mês:

Para SMB com até 30 GB, Google Drive resolve. Para qualquer coisa que vá crescer, Backblaze B2 com Object Lock é a melhor relação custo-benefício em 2026.

## UpdraftPlus vs BackWPup vs Duplicator: qual plugin gratuito escolher

Os três cobrem o caso básico, mas com filosofias diferentes.

Veredito prático: para **backup automático recorrente com off-site gratuito**, UpdraftPlus é a escolha óbvia em 2026 — é o que recomendo abaixo. BackWPup brilha em quem já tem cron no servidor e quer jobs versáteis. Duplicator é ferramenta de migração, não de backup contínuo.

## Configurando UpdraftPlus passo a passo com Google Drive

Workflow de 7 passos para um site novo:

1. **Instale o UpdraftPlus** em *Plugins → Adicionar novo*, ative e acesse *Configurações → UpdraftPlus Backups*.
2. Na aba **Configurações**, defina o agendamento de arquivos como “Diariamente” e o agendamento do banco também como “Diariamente” (eles são separados de propósito — bancos podem rodar mais frequentemente).
3. **Retenção**: configure “Manter este número de agendamentos de backup” como **14** para o banco e **7** para os arquivos. Mais detalhes na seção de retenção abaixo.
4. Em **Escolha o seu armazenamento remoto**, selecione **Google Drive**. Clique no link de autorização — você será redirecionado ao OAuth do Google, autorize e retorne ao painel; o UpdraftPlus confirma a conexão.
5. Em **Inclua nos arquivos do backup**, mantenha marcados Plugins, Temas, Uploads e Other directories. Em *Mostrar configurações avançadas* adicione exclusões para diretórios de cache (ex.: `wp-content/cache/`, `wp-content/uploads/wpforms/cache/`).
6. Salve as alterações. Clique em **Fazer backup agora** marcando “Incluir o banco de dados” e “Incluir arquivos” + “Enviar este backup para armazenamento remoto”. Acompanhe o log.
7. **Verificação**: abra o Google Drive, confirme a pasta `UpdraftPlus` e os 5 arquivos esperados (`db`, `plugins`, `themes`, `uploads`, `others`). Sem esses arquivos no destino remoto, o backup não conta como off-site.

Observação: a versão gratuita não suporta backup incremental nem OneDrive/Azure — esses destinos exigem a extensão paga.

## Backup manual via WP-CLI e cron: comandos copiáveis

Quando você tem SSH (VPS ou hospedagem com terminal), o WP-CLI elimina a dependência de plugin. O comando `wp db export` invoca o `mysqldump` usando as credenciais `DB_HOST`, `DB_NAME`, `DB_USER` e `DB_PASSWORD` do `wp-config.php`, segundo a documentação oficial do WP-CLI. O par é `wp db import` para restauração. Veja mais comandos no nosso guia de [WP-CLI para gestão avançada do WordPress](https://wordpress.fabricandocursos.com.br/wp-cli-wordpress-automacao-comandos-seguros/).

Script completo `/usr/local/bin/wp-backup.sh`:

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

WP_PATH=”/var/www/seusite”
BACKUP_DIR=”/var/backups/wordpress”
STAMP=$(date +%Y%m%d-%H%M%S)
DB_FILE=”${BACKUP_DIR}/db-${STAMP}.sql.gz”
FILES_FILE=”${BACKUP_DIR}/files-${STAMP}.tar.gz”

mkdir -p “${BACKUP_DIR}”

# 1. Dump do banco (mysqldump via wp-cli)
cd “${WP_PATH}”
wp db export – –add-drop-table | gzip > “${DB_FILE}”

# 2. Compactação dos arquivos (excluindo cache)
tar -czf “${FILES_FILE}” \
–exclude=”wp-content/cache” \
–exclude=”wp-content/uploads/cache” \
-C “$(dirname ${WP_PATH})” “$(basename ${WP_PATH})”

# 3. Envio off-site (Backblaze B2 via rclone)
rclone copy “${DB_FILE}” b2:meu-bucket-backups/db/
rclone copy “${FILES_FILE}” b2:meu-bucket-backups/files/

# 4. Retenção local: manter 7 dias
find “${BACKUP_DIR}” -type f -mtime +7 -delete
“`

Torne executável e agende no cron do sistema:

“`bash
chmod +x /usr/local/bin/wp-backup.sh
crontab -e
“`

Entrada de crontab — banco a cada 6h, arquivos diariamente às 3h:

“`cron
0 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1
“`

Para restaurar:

“`bash
cd /var/www/seusite
gunzip < /caminho/db-20260520-030001.sql.gz | wp db import - tar -xzf /caminho/files-20260520-030001.tar.gz -C /var/www/ ``` Em hospedagem compartilhada sem SSH, esse fluxo não se aplica — fique com UpdraftPlus. **Desative o wp-cron e use o cron do sistema.** O `wp-cron.php` só dispara quando alguém visita o site — em sites de baixo tráfego, o agendamento pode ficar dias parado. Em `wp-config.php`, adicione `define('DISABLE_WP_CRON', true);` e crie no crontab do servidor uma chamada periódica (`*/5 * * * * curl -s https://seusite.com.br/wp-cron.php > /dev/null`) ou, melhor ainda, pule o WordPress e use diretamente o script WP-CLI agendado acima.

## Política de retenção: quantas cópias guardar e por quanto tempo

Retenção curta demais (apenas o backup de ontem) é perigoso: se um malware é injetado e só é detectado em 5 dias, o único backup disponível já está contaminado. Retenção infinita explode o storage. Padrão prático para SMB:

– **Banco de dados**: 14 cópias diárias + 4 semanais + 6 mensais (esquema GFS — *Grandfather-Father-Son*).
– **Arquivos**: 7 diários + 4 semanais + 3 mensais.
– **Antes de evento crítico** (migração, atualização major, deploy de plugin): snapshot ad hoc rotulado, mantido por 90 dias.
– **Cópia imutável anual**: 1 backup por ano em storage com Object Lock, mantido por 3+ anos para compliance.

O UpdraftPlus permite o GFS apenas em planos pagos; na versão gratuita você define um número único de “agendamentos a manter”. Para GFS de verdade na free, use o BackWPup com múltiplos jobs (diário, semanal, mensal), cada um com seu próprio limite de retenção.

## Drill de restauração: testando o backup em staging em 30 minutos

Esta é a seção que 90% dos tutoriais omite. Backup que nunca foi restaurado é uma hipótese — não um plano.

Drill trimestral em ~30 minutos:

1. **Crie um subdomínio staging** no seu painel (ex.: `staging.seusite.com.br`) apontando para uma pasta vazia.
2. **Baixe o backup mais recente** do destino remoto (Drive, S3, B2). Confirme que os arquivos do banco e dos arquivos estão presentes.
3. **Extraia os arquivos**: `tar -xzf files-XXXX.tar.gz -C /var/www/staging/`.
4. **Crie um banco de dados separado** para o staging (ex.: `wp_staging`) e ajuste `wp-config.php` para apontar para ele.
5. **Importe o dump**: `wp db import db-XXXX.sql.gz` (após `gunzip` se compactado).
6. **Atualize URLs** para o domínio de staging: `wp search-replace ‘https://seusite.com.br’ ‘https://staging.seusite.com.br’ –all-tables –skip-columns=guid`.
7. **Valide visualmente**: home, post recente, página de checkout (WooCommerce), login admin, upload de mídia, busca interna.
8. **Registre a data e o resultado** em um log simples (`backup-drill.md`). Sem registro, no próximo trimestre você não sabe quando foi o último teste.

Falhou em algum passo? Esse é exatamente o ponto do drill — descobrir agora, com tempo, e não às 3h da manhã com o site fora.

Após a restauração real em produção (não no drill), reforce o login com [ativar 2FA no WordPress](https://wordpress.fabricandocursos.com.br/2fa-wordpress-proteger-login/) e regere chaves SALT no `wp-config.php` — restauração após incidente sem rotação de credenciais é convite para reentrada do atacante.

## Erros comuns que tornam um backup inútil

– **Cópia única no mesmo servidor**: viola off-site da 3-2-1. Disco falha, conta é suspensa, ransomware criptografa — backup vai junto.
– **Banco sem os arquivos** (ou vice-versa): restauração impossível. Você precisa dos dois.
– **wp-config.php fora do pacote**: backup “genérico” não inclui credenciais nem SALTs. Reconstruir é dor.
– **Diretórios de cache dentro do backup**: inchaço inútil. Exclua `wp-content/cache/` e caches de plugins.
– **Retenção de 1 dia**: malware detectado tarde sobrescreve o único bom.
– **Cron rodando mas backup quebrado silenciosamente**: sem notificação de falha (e-mail, webhook), o backup “está rodando” há meses sem produzir arquivo válido.
– **Dump SQL truncado por timeout**: PHP `max_execution_time` baixo trunca o export. Por isso `wp-cli` é mais confiável que plugin em sites grandes.
– **Restauração nunca testada**: o erro raiz. Se você nunca restaurou, você não tem backup — tem arquivo.
– **Senha do destino remoto vazada/expirada**: token OAuth do Drive expira, IAM do S3 é desabilitado. Monitore a saúde da conexão.
– **Backup criptografado com chave perdida**: criptografia é boa prática, mas guarde a chave fora do servidor (gerenciador de senhas), nunca dentro do mesmo backup.

## Checklist final de backup confiável

1. ☐ Backup cobre **arquivos + banco + wp-config.php**.
2. ☐ Pelo menos **1 cópia off-site** (Drive, S3, B2, Dropbox ou SFTP externo).
3. ☐ **3 cópias** existindo simultaneamente, em **2 mídias** diferentes.
4. ☐ Pelo menos **1 cópia imutável** (Object Lock) protegida contra ransomware.
5. ☐ Frequência alinhada ao tipo de site (diária no mínimo para sites ativos).
6. ☐ **Retenção GFS** definida (14 dias + 4 semanas + 6 meses como referência).
7. ☐ Notificação por e-mail/Slack em caso de **falha de backup**.
8. ☐ Diretórios de cache **excluídos** do pacote.
9. ☐ **Drill de restauração** executado nos últimos 90 dias, com data registrada.
10. ☐ Chave de criptografia e credenciais do destino guardadas **fora do servidor**.

Se cair em um único item, ajuste antes da próxima publicação. Os outros nove não compensam o que falta.

Backup automático no WordPress: rotina 3-2-1 testada

Deixe um comentário Cancelar resposta

Reach out to us for sponsorship opportunities