Como Fazer Backup Incremental Sem Carga na CPU em Servidores

Configurar um backup incremental sem carga na CPU é um dos maiores gargalos na administração de servidores web em produção. Ferramentas tradicionais como o rsync combinado com tar e gzip são notórias por disparar o load average e causar gargalos de I/O, muitas vezes acordando o OOM Killer em servidores densamente populados.

Para servidores ocupados (especialmente os que rodam painéis de controle, onde o disco já sofre com dezenas de instâncias do PHP-FPM e MariaDB), a estratégia precisa mudar de “copiar e compactar tudo” para deduplicação em bloco e snapshots.

Aqui estão as abordagens e ferramentas modernas mais eficientes para realizar rotinas seguras sem derrubar sua infraestrutura.

A Abordagem a Nível de Sistema de Arquivos (A Bala de Prata)

Se você tem controle sobre a formatação do disco, a forma mais eficiente de realizar um backup incremental sem carga na CPU é transferir a responsabilidade diretamente para o File System.

• Btrfs e ZFS (Snapshots + Send/Receive): O Btrfs permite tirar snapshots instantâneos (Copy-on-Write) que custam zero CPU e zero I/O no momento da criação. Para o backup externo, você utiliza o comando btrfs send acoplado a um btrfs receive no servidor de destino. Ele envia apenas os blocos de dados que mudaram.
  • Por que não usa processamento? O sistema de arquivos já sabe exatamente quais blocos foram alterados (via metadata). Não há varredura de disco (stat em milhões de arquivos, o calcanhar de aquiles do rsync) e a transferência é feita em nível de bloco.

Ferramentas Modernas de Deduplicação

Se você está preso ao ext4 ou XFS, as ferramentas de deduplicação modernas são o caminho definitivo para conseguir um backup incremental sem carga na CPU. Elas dividem os arquivos em “chunks” (pedaços), fazem o hash de cada um e só transferem e comprimem o que é inédito.

• BorgBackup (Borg): É o queridinho dos sysadmins atualmente. Ele oferece deduplicação no lado do cliente, compressão e criptografia autenticada.
  • Tuning para servidores: O Borg permite escolher o algoritmo de compressão. Em servidores ocupados, fuja do LZMA/zlib e utilize o zstd (Zstandard). O zstd oferece uma taxa de compressão similar ao gzip, mas com velocidades absurdamente mais rápidas, consumindo uma fração do processamento.
• Restic: Semelhante ao Borg, mas escrito em Go. A grande vantagem do Restic é a sua facilidade nativa em enviar dados diretamente para Object Storage (como Amazon S3, Cloudflare R2 ou MinIO) sem precisar de agentes intermediários.

Técnicas de Contenção de Recursos (Hardening de Rotinas)

Mesmo com ferramentas modernas, o processo de leitura no disco pode gerar iowait, o que se traduz em lentidão na aplicação (aumento no load mesmo com os núcleos ociosos).

• Zstd (Zstandard): Se você for rodar qualquer script customizado ou dump de banco de dados, substitua o | gzip por | zstd -3 (ou até -1 para ser ainda mais rápido). A diferença de performance é brutal.
• Contenção com Cgroups / CloudLinux LVE: Se você utiliza CloudLinux, não deixe a rotina rodar solta. Coloque o processo do Borg ou Restic dentro de um LVE específico com limites estritos (ex: 30% de CPU) e IOPS limitados.
• ionice e nice: O feijão com arroz que ainda funciona. Sempre envolva seus comandos: ionice -c 3 nice -n 19 restic backup .... Isso garante que a cópia de segurança só usará recursos quando o Nginx e o MariaDB não estiverem precisando.

O Fluxo de Trabalho Ideal para Web Hosting

Para um servidor de hospedagem com múltiplos sites, a rotina de menor impacto costuma ser:

1. Bancos de Dados: Dumps lógicos diários rápidos com zstd (ou utilizar replicação/snapshots LVM se o banco for massivo).
2. Arquivos: Restic ou BorgBackup rodando a cada 4 ou 6 horas para capturar o estado do /home ou /var/www. O primeiro processamento será demorado, mas a deduplicação garantirá que as próximas execuções sejam o seu sonhado backup incremental sem carga na CPU, finalizando em poucos minutos.

Bônus Prático: Script de Backup Incremental com Baixo Impacto (BorgBackup)

Para tirar a teoria do papel, aqui está um script Bash pronto para produção. Este script utiliza o BorgBackup para salvar os dados do seu diretório web (/var/www ou /home), forçando a prioridade mínima de I/O e CPU, e utilizando a compressão ultrarrápida zstd.

Adicione o código abaixo no seu servidor (por exemplo, em /usr/local/bin/backup-baixo-load.sh) e agende no cron.

#!/bin/bash

# ==========================================
# Script de Backup Incremental (Low CPU/IO)
# ==========================================

# Configurações do Repositório Borg
export BORG_REPO="/caminho/para/seu/storage/borg-repo"
export BORG_PASSPHRASE="sua_senha_super_segura_aqui"

# Diretórios que serão backupeados (ex: sites dos clientes)
SOURCE_DIR="/home/admin/domains"

# Nome do arquivo de log
LOG="/var/log/borg_backup.log"

echo "Iniciando backup incremental em $(date)" >> $LOG

# Execução do Borg encapsulada com nice e ionice para não travar o servidor
# O parâmetro --compression zstd,2 garante velocidade extrema com baixo uso de CPU
ionice -c 3 nice -n 19 borg create \
    --verbose \
    --stats \
    --compression zstd,2 \
    ::'{hostname}-{now:%Y-%m-%d_%H:%M}' \
    $SOURCE_DIR >> $LOG 2>&1

# Pós-processamento: Limpeza de backups antigos (Prune)
# Mantém: 7 diários, 4 semanais e 6 mensais
ionice -c 3 nice -n 19 borg prune \
    --list \
    --keep-daily=7 \
    --keep-weekly=4 \
    --keep-monthly=6 \
    >> $LOG 2>&1

echo "Backup finalizado em $(date)" >> $LOG
echo "---------------------------------------------------" >> $LOG

Dissecando o Script (Por que ele não pesa no servidor?):

• ionice -c 3: Coloca o processo na classe “Idle” de I/O. O disco só será lido/escrito quando o MariaDB e o Servidor Web não estiverem utilizando a fila de disco. Isso acaba com o problema de I/O Wait alto.
• nice -n 19: Dá a menor prioridade possível de CPU para o processo.
• --compression zstd,2: Em vez do tradicional e pesado lzma ou zlib, o nível 2 do Zstandard comprime os dados de forma extremamente rápida, poupando ciclos do processador.
• Deduplicação Nativa: O Borg naturalmente só enviará os blocos (chunks) que foram modificados desde a última execução, reduzindo a transferência de dados a quase zero no dia a dia.

Bônus Prático: Backup Incremental Direto para a Nuvem com Restic e S3

Se você prefere enviar seus dados diretamente para um Object Storage (como Cloudflare R2, que tem custo zero de egress de rede) sem precisar de servidores intermediários, o Restic é a ferramenta ideal.

O script abaixo configura um backup incremental sem carga na CPU, utilizando as variáveis de ambiente do S3 e as ferramentas de contenção do sistema operacional para garantir que o load average permaneça estável durante o envio para a nuvem.

Crie o arquivo (ex: /usr/local/bin/backup-s3-restic.sh) e agende-o no cron:

#!/bin/bash

# ==========================================
# Backup Incremental para S3 com Restic
# ==========================================

# Credenciais do Bucket S3 (Ex: Cloudflare R2, AWS, Backblaze)
export AWS_ACCESS_KEY_ID="sua_access_key_aqui"
export AWS_SECRET_ACCESS_KEY="sua_secret_key_aqui"
export RESTIC_PASSWORD="senha_de_criptografia_do_restic"

# Endpoint e nome do repositório/bucket
export RESTIC_REPOSITORY="s3:https://<id-da-conta>.r2.cloudflarestorage.com/nome-do-bucket"

# Diretório alvo (ex: sites hospedados no DirectAdmin ou cPanel)
SOURCE_DIR="/home/admin/domains"

# Log da operação
LOG="/var/log/restic_s3_backup.log"

echo "Iniciando Restic para S3 em $(date)" >> $LOG

# Execução encapsulada com nice e ionice para proteção de recursos
# O Restic fará o scan em bloco e enviará apenas o diferencial para o bucket
ionice -c 3 nice -n 19 restic backup \
    --verbose \
    --tag "producao" \
    $SOURCE_DIR >> $LOG 2>&1

# Pós-processamento: Retenção e Limpeza (Prune) no Bucket
# Mantém os últimos 7 diários, 4 semanais e 6 mensais
ionice -c 3 nice -n 19 restic forget \
    --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 6 \
    --prune >> $LOG 2>&1

echo "Backup Restic finalizado em $(date)" >> $LOG
echo "---------------------------------------------------" >> $LOG

Dissecando o Script:

• Direto para o Bucket (s3:...): O Restic fala nativamente com a API do S3. Ele divide os arquivos em pequenos chunks encriptados, faz o hash e só faz o upload via HTTPS daquilo que não existe no bucket. Isso economiza uma banda de rede colossal.
• ionice -c 3 e nice -n 19: Assim como no script do Borg, forçamos o Restic a rodar com a menor prioridade possível. O scan de arquivos acontecerá lentamente em background, utilizando apenas ciclos ociosos de CPU e I/O, garantindo que as aplicações web continuem respondendo instantaneamente.
• Segurança Implícita (Zero Trust local): Se o servidor web for comprometido, o invasor não consegue rodar um rm -rf nos backups anteriores facilmente, pois os dados estão isolados no provedor de S3, protegidos por versionamento e políticas de retenção da nuvem.

O Script Definitivo: MariaDB + Arquivos + Backblaze B2

Este script primeiro exporta todos os bancos de dados utilizando o algoritmo zstd (para não onerar o processador) e, em seguida, invoca o Restic para enviar os arquivos web e os bancos diretamente para o bucket S3 do Backblaze.

Crie o arquivo /usr/local/bin/backup-completo-b2.sh e dê permissão de execução (chmod +x):

#!/bin/bash

# ==========================================
# Backup Incremental sem Carga na CPU (Web + DB)
# Destino: Backblaze B2 via API S3 (Restic)
# ==========================================

# 1. Credenciais do Backblaze B2 (S3 Compatible API)
export AWS_ACCESS_KEY_ID="sua_keyID_aqui"
export AWS_SECRET_ACCESS_KEY="sua_applicationKey_aqui"
export RESTIC_PASSWORD="sua_senha_super_segura_do_restic"

# 2. Endpoint do Bucket Backblaze (Ajuste a região e o nome)
export RESTIC_REPOSITORY="s3:https://s3.us-west-004.backblazeb2.com/nome-do-seu-bucket"

# 3. Diretórios e Arquivos
SOURCE_DIR="/home/admin/domains" # Ajuste para /var/www se não usar painel
DB_BACKUP_DIR="/root/db_backups"
LOG_FILE="/var/log/restic_b2_backup.log"

# Garante que o diretório de backup temporário do banco exista
mkdir -p $DB_BACKUP_DIR

echo "===================================================" >> $LOG_FILE
echo "Iniciando rotina de backup em $(date)" >> $LOG_FILE

# ---------------------------------------------------------
# ETAPA A: Dump do Banco de Dados com Compressão Zstandard
# ---------------------------------------------------------
echo "-> Iniciando dump do MariaDB/MySQL..." >> $LOG_FILE

# Usamos ionice e nice para o dump. O mysqldump é "pipado" diretamente 
# para o zstd nível 3, garantindo um arquivo minúsculo com uso irrisório de CPU.
ionice -c 3 nice -n 19 mysqldump --all-databases | zstd -3 > $DB_BACKUP_DIR/all_databases.sql.zst

echo "-> Dump finalizado." >> $LOG_FILE

# ---------------------------------------------------------
# ETAPA B: Envio Incremental para o Backblaze B2 via Restic
# ---------------------------------------------------------
echo "-> Iniciando envio para o Backblaze B2 (Restic)..." >> $LOG_FILE

# O Restic fará a leitura em bloco dos arquivos dos sites e do dump do banco.
# Ele enviará apenas os blocos que sofreram alterações desde ontem.
ionice -c 3 nice -n 19 restic backup \
    --verbose \
    --tag "producao-completa" \
    $SOURCE_DIR \
    $DB_BACKUP_DIR >> $LOG_FILE 2>&1

echo "-> Envio finalizado." >> $LOG_FILE

# ---------------------------------------------------------
# ETAPA C: Limpeza de Backups Antigos (Prune) no B2
# ---------------------------------------------------------
echo "-> Aplicando política de retenção no Backblaze..." >> $LOG_FILE

# Mantém 7 dias, 4 semanas e 6 meses. Remove blocos órfãos no destino.
ionice -c 3 nice -n 19 restic forget \
    --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 6 \
    --prune >> $LOG_FILE 2>&1

echo "Rotina finalizada com sucesso em $(date)" >> $LOG_FILE
echo "===================================================" >> $LOG_FILE

O pulo do gato deste script :

Destaque a linha do mysqldump.

A maioria dos scripts antigos faz algo como mysqldump ... | gzip > banco.sql.gz. O Gzip, em bancos de dados de 10GB+, vai travar um núcleo inteiro da CPU (100%) por longos minutos, gerando filas no disco e no próprio MariaDB. Ao substituir por | zstd -3 aliado ao ionice -c 3 nice -n 19, o dump acontece de forma fluida, silenciosa e sem gerar picos no load average.

Passo a Passo de Implementação em Produção

Antes de executar o script que criamos acima, precisamos instalar a ferramenta e “formatar” o seu bucket no Backblaze B2 para que ele entenda o formato criptografado do Restic. Isso é feito apenas uma vez.

1. Instalação e Inicialização (restic init)

Primeiro, instale o Restic no seu servidor.

Em servidores baseados em RHEL (AlmaLinux, Rocky Linux, CloudLinux):

dnf install restic epel-release -y

(Para Debian/Ubuntu, utilize apt install restic).

Agora, no terminal do seu servidor, exporte temporariamente as suas credenciais do Backblaze e a sua senha mestre de criptografia para inicializar o repositório.

⚠️ Atenção: Anote a RESTIC_PASSWORD em um gerenciador de senhas seguro. Se você perder essa senha, seus backups na nuvem serão permanentemente inacessíveis, mesmo que você tenha acesso à conta do Backblaze.

export AWS_ACCESS_KEY_ID="sua_keyID_aqui"
export AWS_SECRET_ACCESS_KEY="sua_applicationKey_aqui"
export RESTIC_PASSWORD="sua_senha_super_segura_do_restic"

# Formata o bucket para o padrão Restic
restic -r s3:https://s3.us-west-004.backblazeb2.com/nome-do-seu-bucket init

Se o terminal retornar created restic repository, o terreno está pronto! O seu bucket no B2 agora possui a estrutura de diretórios criptografada necessária para receber os dados.

2. Agendando a Rotina no Cron (Automação Total)

Com o repositório inicializado e o nosso script salvo em /usr/local/bin/backup-completo-b2.sh, o último passo é colocar o servidor para trabalhar por você.

Dê permissão de execução para o seu script:

chmod +x /usr/local/bin/backup-completo-b2.sh

Abra o agendador de tarefas do Linux:

crontab -e

Adicione a linha abaixo para executar o seu backup incremental sem carga na CPU todos os dias, pontualmente às 03:00 da manhã. Mesmo que o script seja extremamente otimizado com ionice e nice, rodar na madrugada garante o menor impacto possível na navegação dos usuários:

# Executa o backup Restic + Backblaze B2 diariamente às 03:00 AM
0 3 * * * /usr/local/bin/backup-completo-b2.sh >/dev/null 2>&1

Salve e saia do editor. Pronto! Sua infraestrutura agora conta com uma rotina de disaster recovery de nível corporativo, enviando dados para fora do datacenter de forma segura, com retenção inteligente e sem derrubar o load average do seu servidor web.

FAQ

Veja Mais:

Cloud Exit: Por que grandes empresas estão voltando ao Bare Metal?

Como Migrar VPS para Bare Metal: Planejamento e Arquitetura

Guia Completo: Btrfs em Servidores de Produção (Instalação e Setup)

Snapshot não é Backup: Entenda a Diferença Técnica