Backup WP-CLI: Automatize Backups de WordPress Sem Painel

O gerenciamento de servidores Linux para WordPress e WooCommerce evoluiu significativamente. Para administradores de sistemas, desenvolvedores e profissionais de TI que operam em ambientes de VPS Linux, abandonar a dependência exclusiva de painéis gráficos como cPanel ou DirectAdmin não é apenas uma questão de custo, mas de controle granular sobre a infraestrutura. Neste tutorial, exploraremos como utilizar o wp-cli para realizar backups completos, automatizar processos e garantir a integridade dos dados em ambientes LEMP Stack (Linux, Nginx, MySQL/MariaDB, PHP) ou rodando sob OpenLiteSpeed.

Por que Automatizar Backups via Linha de Comando?

A migração de uma hospedagem compartilhada para um VPS oferece performance superior, mas traz a responsabilidade da gestão direta. Plugins de backup são ferramentas valiosas, mas eles rodam dentro do ambiente PHP, consumindo recursos de CPU e memória que poderiam ser otimizados para o próprio tráfego do site. Além disso, em cenários de otimização WP extrema, manter plugins desnecessários pode ser um risco de segurança ou de performance.

O uso de scripts shell combinados com wp-cli permite:

• Isolamento de Recursos: O backup roda fora do ciclo de vida do WordPress, evitando timeouts de execução PHP.
• Portabilidade: Scripts shell são universais entre distribuições Linux, facilitando a migração de compartilhada ou entre diferentes VPSs.
• Controle Total: Você decide exatamente o que é excluído (logs, caches temporários) e como os arquivos são comprimidos.

Pré-requisitos: Preparando o Ambiente

Antes de executar qualquer comando, certifique-se de que seu servidor atenda aos requisitos básicos. Este tutorial assume que você já possui acesso SSH com privilégios de root ou um usuário com sudo habilitado em uma distribuição Debian/Ubuntu ou CentOS/RHEL.

Primeiro, garanta que o wp-cli está instalado e funcional. Se você estiver utilizando uma stack moderna como a oferecida por soluções otimizadas, verifique a versão:

wp --version

Se o comando retornar um erro de "comando não encontrado", instale-o seguindo a documentação oficial ou através do gerenciador de pacotes da sua distribuição. Além disso, para uma automação eficiente, é crucial ter o OpenLiteSpeed ou Nginx configurados corretamente e o serviço de banco de dados (MySQL/MariaDB) rodando.

Etapa 1: Estruturação do Diretório de Backups

A organização é a chave para a manutenção futura. Crie um diretório dedicado para armazenar os backups. Evite salvar backups no mesmo disco onde o banco de dados está ativo se possível, mas em VPSs menores, uma estrutura lógica dentro do servidor é aceitável desde que haja rotação.

sudo mkdir -p /var/backups/wp-sites/$(date +%Y-%m)

Este comando cria um diretório hierárquico baseado no ano e mês. Para o site específico, vamos criar uma subpasta identificadora:

sudo mkdir -p /var/backups/wp-sites/$(date +%Y-%m)/meu-site.com.br

Atribua as permissões corretas para garantir que apenas o usuário do sistema (geralmente www-data no Ubuntu ou nginx no CentOS) possa ler os arquivos, mas que o root possa gerenciá-los.

sudo chown -R root:www-data /var/backups/wp-sites/
sudo chmod -R 750 /var/backups/wp-sites/

Etapa 2: Backup do Banco de Dados com WP-CLI

O wp-cli possui um comando nativo poderoso para exportação de banco de dados: wp db export. Diferente de usar mysqldump manualmente, o wp-cli lê automaticamente as credenciais do arquivo wp-config.php, eliminando a necessidade de hardcodar senhas sensíveis no seu script shell.

Execute o seguinte comando para exportar o banco de dados atual:

cd /var/backups/wp-sites/$(date +%Y-%m)/meu-site.com.br
wp db export --path=/var/www/meu-site.com.br

O parâmetro --path aponta para a raiz da instalação do WordPress. O resultado será um arquivo SQL com o nome gerado automaticamente (ex: 2023-10-27_meu-site.sql). Para fins de compressão e segurança, renomeie ou mova este arquivo imediatamente após a criação.

Dica Pro: Se você quiser adicionar uma marca d'água no topo do SQL para identificar a origem, use o comando wp db export com a flag --add-drop-table para garantir que a restauração substitua tabelas existentes sem erros de duplicidade.

wp db export --path=/var/www/meu-site.com.br --add-drop-table

Etapa 3: Backup dos Arquivos do WordPress

Agora que o banco de dados está seguro, precisamos compactar os arquivos do site. Isso inclui temas, plugins, uploads e o próprio núcleo do WordPress. Utilizaremos o tar para criar um arquivo compactado com alta eficiência.

Ao fazer backup de arquivos em produção, é crucial excluir diretórios que não devem ser versionados ou que consomem muito espaço, como caches de plugins (w3-cache, object-cache.php) e logs do servidor web.

cd /var/backups/wp-sites/$(date +%Y-%m)/meu-site.com.br
tar -czvf wordpress-backup-$(date +%F).tar.gz \
  --exclude=./wp-content/cache \
  --exclude=./wp-content/uploads/temp \
  --exclude=./wp-content/debug.log \
  --exclude=./wp-config.php.bak \
  /var/www/meu-site.com.br

Neste comando, -czvf significa: criar (c), comprimir com gzip (z), mostrar verbosidade (v) e especificar o arquivo de saída (f). As flags --exclude garantem que apenas os arquivos essenciais sejam incluídos, reduzindo drasticamente o tempo de compressão e o tamanho final do backup.

Etapa 4: Criando um Script Shell Automatizado

Para transformar esse processo manual em uma rotina confiável, vamos consolidar os comandos em um script shell. Crie um arquivo chamado /usr/local/bin/wp-backup.sh:

sudo nano /usr/local/bin/wp-backup.sh

Insira o seguinte conteúdo no script:

#!/bin/bash

# Configurações
SITE_NAME="meu-site.com.br"
WP_PATH="/var/www/meu-site.com.br"
BACKUP_DIR="/var/backups/wp-sites/$(date +%Y-%m)/${SITE_NAME}"
DATE=$(date +%F)
LOG_FILE="/var/log/wp-backup-${SITE_NAME}.log"

# Verifica se o diretório existe, senão cria
mkdir -p "$BACKUP_DIR"

# Inicia log
echo "Iniciando backup para $SITE_NAME em $(date)" >> "$LOG_FILE"

# 1. Backup do Banco de Dados
echo "Exportando banco de dados..." >> "$LOG_FILE"
wp db export "$BACKUP_DIR/db-${DATE}.sql" --path="$WP_PATH" --add-drop-table >> "$LOG_FILE" 2>&1

if [ $? -ne 0 ]; then
    echo "Erro na exportação do banco de dados!" >> "$LOG_FILE"
    exit 1
fi

# 2. Backup dos Arquivos
echo "Compactando arquivos..." >> "$LOG_FILE"
tar -czvf "$BACKUP_DIR/files-${DATE}.tar.gz" \
  --exclude=./wp-content/cache \
  --exclude=./wp-content/uploads/temp \
  --exclude=./wp-content/debug.log \
  --exclude=./wp-config.php.bak \
  -C "$WP_PATH" . >> "$LOG_FILE" 2>&1

if [ $? -ne 0 ]; then
    echo "Erro na compactação dos arquivos!" >> "$LOG_FILE"
    exit 1
fi

echo "Backup concluído com sucesso para $SITE_NAME." >> "$LOG_FILE"

# 3. Rotação de Backups (Mantém apenas os últimos 7 dias)
find /var/backups/wp-sites/$(date +%Y-%m)/${SITE_NAME} -mtime +7 -delete
echo "Rotação realizada." >> "$LOG_FILE"

Após salvar o arquivo, torne-o executável:

sudo chmod +x /usr/local/bin/wp-backup.sh

Teste a execução manual para garantir que não há erros de permissão ou caminhos incorretos:

/usr/local/bin/wp-backup.sh

Verifique o arquivo de log gerado em /var/log/ para confirmar a integridade do processo.

Etapa 5: Agendamento com Cron

Com o script funcionando, o próximo passo é integrá-lo ao sistema operacional via Cron. Isso garante que os backups ocorram independentemente de interações humanas.

Edite o crontab do root ou do usuário específico:

sudo crontab -e

Adicione a seguinte linha para rodar o backup diariamente às 3:00 da manhã, horário em que o tráfego costuma ser menor:

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

Essa configuração executa o script e redireciona qualquer saída de erro ou sucesso para um log específico do cron, permitindo monitoramento centralizado.

Considerações Finais sobre Plugins Essenciais e OpenLiteSpeed

Embora a automação via wp-cli cubra 90% das necessidades técnicas de backup, é importante ressaltar o papel dos plugins essenciais. Em ambientes OpenLiteSpeed, por exemplo, plugins de cache como o LiteSpeed Cache são fundamentais para a performance, mas devem ser excluídos do backup de arquivos (como fizemos na etapa 3) pois são regeneráveis e podem conter configurações locais específicas que conflitam em restaurações.

Além disso, manter uma cópia offline ou enviada para um storage externo (como AWS S3 ou Google Cloud Storage) é uma prática recomendada. Você pode estender o script shell acima adicionando comandos aws s3 sync ou rclone ao final do processo para enviar os arquivos .tar.gz e .sql para nuvem, criando uma estratégia de backup 3-2-1 completa.

Ao dominar essas técnicas, você não apenas garante a segurança dos seus dados em WordPress e WooCommerce, mas também demonstra profissionalismo na gestão de infraestrutura, reduzindo a superfície de ataque e aumentando a resiliência do seu ambiente web.