Guia de Backup Automatizado no Linux para Armazenamento S3

A perda de dados em servidores de produção pode destruir a reputação de uma empresa e causar enormes prejuízos financeiros. Embora provedores de VPS ofereçam snapshots de disco, possuir backups independentes e armazenados fora do servidor de origem é uma regra de ouro de infraestrutura.

Neste guia, ensinamos como criar uma rotina automatizada de backup de arquivos e bancos de dados para o armazenamento em nuvem Amazon S3 (ou qualquer object storage compatível, como MinIO ou Backblaze).

1. Configurando as Credenciais (AWS CLI)

O utilitário recomendado para interagir com o S3 a partir do terminal Linux é o AWS CLI.

Instalação e Configuração:

1. Instale o pacote:
   sudo apt install awscli -y
2. Crie uma chave de acesso (Access Key e Secret Key) no console da AWS através do serviço IAM, limitando as permissões apenas para ações no bucket de backup desejado.
3. Configure as credenciais no servidor Linux executando:
   aws configure

2. Escrevendo o Script de Backup

Crie um script em bash para automatizar o dump do banco de dados (neste exemplo, PostgreSQL) e a compactação da pasta de arquivos estáticos.

#!/bin/bash

# Configurações
BACKUP_DIR="/tmp/backups"
BUCKET_NAME="meu-bucket-de-backup-seguro"
DATA=$(date +%Y-%m-%d-%H%M)

# Criar pasta temporária
mkdir -p $BACKUP_DIR

# 1. Backup do Banco de Dados
pg_dump -U postgres meu_banco > $BACKUP_DIR/db_$DATA.sql

# 2. Compactação dos arquivos da aplicação
tar -czf $BACKUP_DIR/arquivos_$DATA.tar.gz /var/www/minha-app

# 3. Envio criptografado para o S3
aws s3 cp $BACKUP_DIR/db_$DATA.sql s3://$BUCKET_NAME/db_$DATA.sql --sse AES256
aws s3 cp $BACKUP_DIR/arquivos_$DATA.tar.gz s3://$BUCKET_NAME/arquivos_$DATA.tar.gz --sse AES256

# Limpeza de arquivos locais temporários
rm -rf $BACKUP_DIR

3. Automatizando com o Cron Job

Para rodar o script automaticamente todas as noites (às 02:00 da manhã):

1. Abra as tarefas agendadas do sistema:
   sudo crontab -e
2. Adicione a linha no final do arquivo:
   0 2 <em class="text-slate-400"> </em> * /home/usuario/scripts/backup.sh > /dev/null 2>&1

4. Restaurar em um banco de teste

O backup só vale se a restauração foi ensaiada. Baixe o dump para um banco vazio, nunca por cima da produção:

aws s3 cp s3://meu-bucket-de-backup-seguro/db_2026-10-01-0200.sql /tmp/restore.sql
sudo -u postgres createdb meu_banco_teste
sudo -u postgres psql -d meu_banco_teste -f /tmp/restore.sql
sudo -u postgres psql -d meu_banco_teste -c '\dt'

\dt lista as tabelas. Se a lista está vazia, o dump não entrou. Os arquivos da aplicação voltam para um diretório separado:

aws s3 cp s3://meu-bucket-de-backup-seguro/arquivos_2026-10-01-0200.tar.gz /tmp/arquivos.tar.gz
sudo mkdir -p /var/www/restore-teste
sudo tar -tzf /tmp/arquivos.tar.gz | head
sudo tar -xzf /tmp/arquivos.tar.gz -C /var/www/restore-teste

tar -tzf lista o conteúdo antes de extrair. Confira o primeiro caminho. Um arquivo que começa com / extrai na raiz do destino e pode sobrescrever a aplicação. Apague /tmp/restore.sql depois do teste. O cron da seção 3 precisa gravar a saída em um log, não em /dev/null, para o dia em que o pg_dump falhar:

0 2 * * * /home/usuario/scripts/backup.sh >> /var/log/backup-s3.log 2>&1

Conclusão

Ter políticas de backup automatizadas e armazenadas fora da infraestrutura de origem é indispensável. Configurando criptografia no nível do S3 e monitorando a execução desses scripts, seu negócio estará totalmente protegido contra exclusões acidentais, desastres de hardware ou ataques virtuais.