Backup automático em Linux com cron e rsync: rotina diária local + offsite

Backup automatizado em servidor Linux não é luxo — é a única coisa entre você e uma noite ruim quando o disco falha, o filesystem corrompe ou alguém roda rm -rf no diretório errado. Apesar disso, muito sysadmin ainda terceiriza essa decisão pra “depois” e descobre na hora do incidente que o último snapshot é de seis meses atrás.

Este tutorial monta uma rotina diária de backup local com rsync (usando snapshots por hardlink pra economizar espaço) e replicação offsite por SSH, agendada com cron. Tudo em script idempotente, com log estruturado e retenção configurável. Foco em servidor Linux genérico (Debian/Ubuntu/Rocky/Alma) rodando como VPS — sem dependências exóticas, sem agente proprietário.

Tempo estimado de execução: 30-40 minutos pra configurar a primeira vez, depois roda sozinho. Restauração de arquivo individual leva segundos; restauração completa depende do volume de dados.

Pré-requisitos

Verifique versões antes de prosseguir:

rsync --version | head -n 1
systemctl status cron      # debian/ubuntu
systemctl status crond     # rhel/rocky/alma

Se rsync não estiver instalado: sudo apt install rsync (Debian/Ubuntu) ou sudo dnf install rsync (Rocky/Alma).

Estrutura de diretórios e estratégia

Antes de escrever script, defina o layout. A receita usa três níveis:

• /backup/local/daily/YYYY-MM-DD/ — snapshots diários (mantidos 7 dias)
• /backup/local/weekly/YYYY-WW/ — snapshots semanais (mantidos 4 semanas)
• /backup/local/monthly/YYYY-MM/ — snapshots mensais (mantidos 6 meses)

Cada snapshot diário é uma cópia completa aparente, mas rsync --link-dest reaproveita os arquivos não alterados como hardlinks do dia anterior. Resultado: 30 dias de backup ocupam pouco mais que 1 cópia completa + deltas de mudanças.

A replicação offsite copia só o snapshot mais recente (current) pra um servidor remoto, criando lá a mesma estrutura de histórico se desejar (ou só substituindo a cópia mais nova).

Script de backup local

Esta seção monta o script principal que cron vai disparar todo dia. Ele faz snapshot incremental com hardlinks, rotaciona retenção e gera log.

sudo mkdir -p /backup/local/{daily,weekly,monthly}
sudo mkdir -p /var/log/backup
sudo chown -R root:root /backup /var/log/backup
sudo chmod 700 /backup

#!/bin/bash
set -euo pipefail

# Configuração
SOURCE_DIRS="/etc /home /var/www /var/lib/mysql-dumps"
BACKUP_ROOT="/backup/local"
LOG_FILE="/var/log/backup/backup-$(date +%Y-%m).log"
RETENTION_DAILY=7
RETENTION_WEEKLY=4
RETENTION_MONTHLY=6

TODAY=$(date +%Y-%m-%d)
DEST="$BACKUP_ROOT/daily/$TODAY"
LATEST_LINK="$BACKUP_ROOT/daily/current"

# Função de log com timestamp
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" >> "$LOG_FILE"
}

log "===== Início do backup $TODAY ====="

# Detecta snapshot anterior pra --link-dest
LINK_DEST_ARG=""
if [ -d "$LATEST_LINK" ]; then
    LINK_DEST_ARG="--link-dest=$(readlink -f "$LATEST_LINK")"
    log "Usando link-dest: $LINK_DEST_ARG"
fi

mkdir -p "$DEST"

# Sync com rsync
rsync -aHAX --delete \
    --numeric-ids \
    $LINK_DEST_ARG \
    $SOURCE_DIRS \
    "$DEST/" >> "$LOG_FILE" 2>&1

# Atualiza symlink 'current'
ln -snf "$DEST" "$LATEST_LINK"

log "Backup local concluído. Tamanho do snapshot:"
du -sh "$DEST" >> "$LOG_FILE" 2>&1

# Retenção: apaga snapshots diários antigos
find "$BACKUP_ROOT/daily" -maxdepth 1 -type d -name "20*" -mtime +$RETENTION_DAILY -exec rm -rf {} \;
log "Retenção diária aplicada (mantendo $RETENTION_DAILY dias)"

log "===== Fim do backup $TODAY ====="

sudo chmod 700 /usr/local/sbin/backup-daily.sh

sudo /usr/local/sbin/backup-daily.sh

tail -n 50 /var/log/backup/backup-$(date +%Y-%m).log

ls -lah /backup/local/daily/
du -sh /backup/local/daily/current/

Replicação offsite por SSH

Backup local protege contra falha de aplicação ou erro humano. Não protege contra perda total do servidor (incêndio, hipervisor corrompido, acesso comprometido). Pra isso, replique pra outro servidor — idealmente em região diferente.

sudo ssh-keygen -t ed25519 -f /root/.ssh/backup_key -N "" -C "backup@$(hostname)"
sudo chmod 600 /root/.ssh/backup_key

# No destino:
sudo useradd -m -s /bin/bash backup-receiver
sudo mkdir -p /home/backup-receiver/.ssh /backup/remote
sudo chown -R backup-receiver: /home/backup-receiver /backup/remote

command="rsync --server -logDtprRe.iLsfxC --delete . /backup/remote/",no-pty,no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAA... backup@servidor-origem

#!/bin/bash
set -euo pipefail

REMOTE_USER="backup-receiver"
REMOTE_HOST="backup.exemplo.com"
LOCAL_CURRENT="/backup/local/daily/current/"
LOG_FILE="/var/log/backup/offsite-$(date +%Y-%m).log"
SSH_KEY="/root/.ssh/backup_key"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" >> "$LOG_FILE"
}

log "===== Início replicação offsite ====="

rsync -aHAX --delete \
    --numeric-ids \
    -e "ssh -i $SSH_KEY -o StrictHostKeyChecking=accept-new" \
    "$LOCAL_CURRENT" \
    "$REMOTE_USER@$REMOTE_HOST:/backup/remote/" >> "$LOG_FILE" 2>&1

log "===== Fim replicação offsite ====="

sudo chmod 700 /usr/local/sbin/backup-offsite.sh
sudo /usr/local/sbin/backup-offsite.sh

Agendamento com cron

Com os scripts validados, agende execução automática diária.

sudo crontab -e

# Garante PATH consistente — cron usa PATH mínimo por padrão
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
[email protected]

# Backup local todo dia às 03:00
0 3 * * * /usr/local/sbin/backup-daily.sh

# Replicação offsite todo dia às 04:30 (depois do local)
30 4 * * * /usr/local/sbin/backup-offsite.sh

Verificação

Depois de 24-48 horas, confirme que tudo está rodando:

# Snapshots diários acumulando
ls -lah /backup/local/daily/

# Log do último run
tail -n 30 /var/log/backup/backup-$(date +%Y-%m).log

# Log do offsite
tail -n 30 /var/log/backup/offsite-$(date +%Y-%m).log

# No servidor de destino
ls -lah /backup/remote/

Você deve ver diretórios datados (2026-05-28, 2026-05-29, etc.), com du -sh mostrando tamanho aparente igual ao dataset mas espaço real consumido bem menor graças aos hardlinks. Confirme com:

du -sh /backup/local/daily/2026-05-29        # tamanho aparente
du -sh --total /backup/local/daily/          # tamanho real total

A diferença entre os dois números é o ganho dos hardlinks.

Resolução de problemas

Script funciona manual mas falha no cron

Quase sempre é PATH. Cron roda com PATH=/usr/bin:/bin por padrão. Solução: ou usar caminhos absolutos no script (/usr/bin/rsync, /usr/bin/ssh), ou definir PATH= no topo do crontab como mostrado acima. Verifique também se MAILTO está configurado pra receber stderr — sem isso, falhas viram silêncio absoluto.

rsync retorna código 23 ou 24

Código 23 indica “alguns arquivos não foram transferidos” (geralmente arquivos abertos ou com permissão restrita); 24 indica “alguns arquivos sumiram durante a transferência” (típico em /var/log ou /tmp). Esses códigos não são necessariamente erro fatal — ajuste o set -e do script pra tolerar com rsync ... || [ $? -eq 23 ] || [ $? -eq 24 ] se forem esperados no seu cenário.

Permission denied no destino offsite

A diretiva command= no authorized_keys é literal — qualquer mudança nas flags do rsync local quebra. Solução: rode o backup-offsite.sh manual com -e "ssh -v" no rsync, capture a linha exata rsync --server ... que ele envia, e atualize o command= no destino com essa string.

Espaço em disco crescendo descontroladamente

Provavelmente o --link-dest não está pegando o snapshot anterior — alguma mudança quebrou o symlink current ou os snapshots estão em filesystems diferentes (hardlinks não cruzam filesystem). Verifique com stat -c '%i' arquivo em duas datas: se o inode for o mesmo, hardlink ativo; se for diferente, está duplicando.

Próximos passos

Esta rotina cobre o básico de produção. Pra evoluir:

• Adicione promoção automática semanal/mensal: cópia (não hardlink) do snapshot diário pra weekly/ toda segunda e pra monthly/ todo dia 1.
• Integre alerta ativo: se o último log tiver mais de 25 horas, dispare notificação (Discord, e-mail, Healthchecks.io). Backup silenciosamente parado é o pior cenário.
• Teste restauração mensal automatizada: restaure um arquivo aleatório do backup mais antigo, compare checksum com produção, logue resultado.
• Avalie criptografia em trânsito e em repouso pro destino offsite (já em trânsito via SSH; em repouso considere LUKS no volume do destino).
• Se você está rodando isso em produção, uma VPS Hostini (/vps) tem volumes NVMe rápidos pra acomodar histórico de snapshots e ainda libera banda generosa pra replicação offsite — o backup deixa de ser fator limitante na escolha de plano.