Configurar backups automàtics a S3

Configurar recolzaments automàtics en S3 sembla una tasca senzilla, però la pràctica demostra una altra cosa. El que comença com un cron amb aws s3 cp acaba convertint-se en una font constant d’incertesa: còpies incompletes, errors silenciosos, costos que es disparen sense avís, o polítiques de cicle de vida mal dissenyades que t’eliminen el recolzament abans d’adonar-te’n.

Quan té sentit S3 per a backups

S3 té avantatges clars: durabilitat alta, accés programàtic, replicació entre regions, i una política de preus estable. Però no és un sistema d’arxius. Si vens del món de NFS, ZFS, o de solucions tipus Bacula/NetBackup, cal replantejar com i què es recolza.

Els backups en S3 tenen sentit si:

1. Les dades estan en forma d’arxius i no requereixen recolzament a nivell de bloc.
2. No necessites recuperació instantània, sinó durabilitat i disponibilitat controlada.
3. Pots treballar amb backups immutables o versionats.
4. Et serveix tenir visibilitat sobre cada arxiu recolzat.

Per a VMs completes, discos muntats o bases de dades en calent, hi ha opcions millors o almenys complementàries (com snapshots EBS, RDS backups automàtics o solucions que integrin S3 com a destinació final però no com a mecanisme principal de snapshot).

Errors comuns en configurar backup en S3

1. Creure que un aws s3 sync diari ho resol tot

És un dels errors més freqüents. aws s3 sync és útil, però està lluny de ser una solució de backup completa. Per defecte, no gestiona versions ni control de canvis, i si un arxiu desapareix localment, també desapareix del destí (llevat que especifiquis el contrari). És a dir, no protegeix contra errors humans o corrupció silenciosa.

Per evitar això, cal:

1. Deshabilitar l’opció d’esborrat amb –exact-timestamps i sense –delet.
2. Habilitar versionat al bucket i gestionar-lo explícitament (més sobre això endavant).
3. Registrar hashes o fer servir eines que verifiquin integritat, no només timestamps.

2. No revisar les polítiques de cicle de vida

Molts buckets de S3 s’omplen ràpid i algú acaba aplicant una política de cicle de vida agressiva. Després, un arxiu important s’elimina per error i no hi ha backup. El problema no és només aplicar polítiques d’eliminació automàtica, sinó fer-ho sense tenir visibilitat real de què s’està esborrant i quan.

Recomanació: mai facis servir polítiques d’expiració fins que tinguis visibilitat clara del contingut i freqüència d’accés. I si fas servir versionat, assegura’t d’aplicar regles diferents a versions anteriors (noncurrent versions).

3. No fer proves reals de restauració

És més comú del que hauria de ser: el backup està configurat, els logs diuen que tot va bé, però el dia que cal recuperar alguna cosa, ningú sap com, o l’arxiu està corrupte. Tenir backup sense prova de recuperació no serveix. Almenys una vegada al mes, descarrega un arxiu aleatori i compara’l amb l’original.

Quines eines i enfocaments funcionen millor

Sync + control de versions

Una estratègia que funciona bé en molts entorns:

1. Es fa servir aws s3 sync sense –delete.
2. El bucket té habilitat versionat.
3. Es manté un log local amb els arxius recolzats i els seus checksums.
4. S’ audita setmanalment el contingut del bucket.

Això permet:

1. Recuperar arxius eliminats o sobrescrits.
2. Veure diferències entre versions.
3. Evitar errors massius per una mala execució de l’ script.

Tar + SHA256

Per a estructures d’arxius que canvien poc però són grans (com /etc, configuracions, codi font), fer tarballs diaris amb data (tar czf etc-YYYYMMDD.tar.gz) i pujar-los a S3 sol ser més efectiu que sincronitzar carpeta a carpeta. Això permet mantenir snapshots coherents i verificar integritat amb SHA256 fàcilment.

Desavantatges: ocupa més espai si no fas deduplicació, i necessites lògica per rotar arxius i evitar acumulació innecessària.

Backups incrementals amb rclone

Si es busca alguna cosa més granular que aws s3 sync, rclone ofereix més flexibilitat:

1. Suporta S3 com a backend.
2. Permet fer backups incrementals o amb timestamp en el nom de carpeta remot.
3. Té verificació d’ integritat més robusta.
4. Facilita el xifrat en trànsit i en repòs (client-side, a més del de S3).

Això sí, no està en tots els entorns per defecte, i mantenir la versió al dia és clau. També requereix una mica més de configuració.

Bases de dades: dump primer, sempre

Mai copiïs directament els directoris d’una base de dades activa (MySQL, PostgreSQL, MongoDB) sense fer servir les eines de backup corresponents. Fes dump o fes servir les APIs de snapshot de cada sistema.

Exemple típic per a PostgreSQL:

pg_dumpall -U postgres | gzip > /backups/pg-$(date +%F).sql.gz
aws s3 cp /backups/pg-$(date +%F).sql.gz s3://tu-bucket/db/

Després, trencada localment aquests dumps. I si la base és gran, avalua usar pg_basebackup o wal-g amb S3.

Consideracions de seguretat

S3 és segur si ho configures bé, però hi ha errors comuns:

Permisos massa amplis

No donis de tot al bucket a tothom. Fes servir polítiques d’IAM amb s3:PutObject limitat per prefix si és possible.

Falta de xifrat al client

Aunque S3 xifra per defecte en servidor (SSE-S3 o SSE-KMS), en alguns entorns és bona idea xifrar també del costat del client amb GPG o similar, sobretot si les dades són sensibles.

Manca de registres d’ accés

Activa el logging d’ accés al bucket o fes servir CloudTrail amb filtres de S3. Si hi ha un accés no autoritzat, te’n assabentaràs massa tard si no tens això habilitat.

Monitorització i alertes que valen la pena

La configuració bàsica funciona fins que alguna cosa falla i ningú se n’assabenta. Alguns elements que han demostrat ser útils:

1. CloudWatch Alarms: per notificar si un job no corre (per exemple, si no hi ha aws s3 cp en logs en les últimes 24h).
2. Verificació diària d’ objectes: script que revisi el nombre d’ objectes nous per dia. Si no canvia durant 3 dies, probablement el backup està trencat o el cron no corre.
3. Alertes de facturació per bucket: si el volum de dades puja molt de cop, pot ser un error o una pujada accidental massiva.

Gestió de costos

Un altre error comú és pensar que S3 és econòmic sempre. Ho és si cuides:

1. Transaccions: cada operació té un cost. Evita sobreús de sync sense lògica prèvia (per exemple, pujades innecessàries).
2. Versionat sense control: pot duplicar l’espai consumit si no apliques polítiques a versions antigues.
3. Classes d’ emmagatzematge mal triades: no tots els backups han d’ anar a STANDARD. Avalua GLACIER Instant Retrieval o INTELLIGENT_TIERING si l’accés és molt esporàdic.

Scripts i patrons d’ ús recomanats

Exemple bàsic amb tar, rotació i pujada:

#!/bin/bash
set -euo pipefail 

SRC_DIR="/etc"
BACKUP_DIR="/backups"
DATE=$(date +%F)
FILENAME="etc-${DATE}.tar.gz"
S3_BUCKET="s3://mi-bucket/respaldos/etc"

# Crear backup
tar czf "${BACKUP_DIR}/${FILENAME}" "${SRC_DIR}

# Verificar integritat
sha256sum "${BACKUP_DIR}/${FILENAME}" > "${BACKUP_DIR}/${FILENAME}.sha256"

# Pujar a S3
aws s3 cp "${BACKUP_DIR}/${FILENAME}" "${S3_BUCKET}/"
aws s3 cp "${BACKUP_DIR}/${FILENAME}.sha256" "${S3_BUCKET}/"

# Rotar localment
find "${BACKUP_DIR}" -type f -mtime +7 -name 'etc-*.tar.gz*' -delete

Aquest patró és més predictible que sync i més fàcil d’auditar.

Versionat en S3: com fer-lo anar bé sense complicar-te la vida

Habilitar el versionat en S3 és fàcil. Administrar-lo bé, no tant. L’opció existeix per a evitar pèrdues accidentals, però si es deixa sense política ni revisió, pot acabar acumulant gigabytes de versions velles que no necessites i que no sabies que estaves pagant.

Bones pràctiques concretes:

1. Habilitar versionat des de l’ inici. No es pot aplicar retroactivament a objectes antics.
2. Nomenar els backups amb timestamp. Encara que tinguis versionat, nomenar els arxius explícitament amb la data (backup-YYYYMMDD.sql.gz) fa molt més fàcil la gestió.
3. Aplicar regles de lifecycle diferenciades per a versions actuals i anteriors. Exemple típic:

{
"Rules": [
    {
      "ID": "Eliminar versions antigues",
      "Status": "Enabled",
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 30
      },
      "Prefix": ""
    },
    {
      "ID": "Transició a Glacier després de 60 dies",
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 60,
          "StorageClass": "GLACIER_IR"
        }
      ],
      "Prefix": ""
    }
  ]
}

Consell pràctic: Si el bucket té dades mixtes (arxius vius + backups), fa servir prefixos (recolzaments/, uploads/, etc.) i aplica regles diferents per prefix. Així evites eliminar alguna cosa per error o arxivar a Glacier un arxiu que es fa servir cada setmana.

Restauracions reals: què esperar i com preparar-te

Aquí és on molts backups fallen. No és estrany trobar entorns on els backups són a S3, però ningú ha practicat una restauració. El pitjor és que les expectatives són irreals: la gent assumeix que la restauració és immediata, però si fas servir Glacier Deep Archive, la recuperació pot trigar hores.

Recomanacions:

1. Si necessites recuperar en minuts, fes servir STANDARD o GLACIER_IR.
2. Si pots esperar més de 12 hores i vols estalviar, considera DEEP_ARCHIVE, però només per a backups mensuals o històrics.
3. Mai facis restauracions directes sobre producció. Descarrega a un staging, verifica integritat, després restaura.

Exemple pràctic: recuperació selectiva

Suposem que es va perdre un arxiu de configuració de fa 3 dies. Si fas servir versionat, pots llistar versions:

aws s3api list-object-versions --bucket mi-bucket --prefix etc/config.yml

Obtindràs els VersionId, dates i mides. Després pots restaurar una versió específica:

aws s3api get-object \
  --bucket mi-bucket \
  --key etc/config.yml \
  --version-id EXAMPLEVERSIONID123 \
  config-restaurado.yml

Això és més eficient i segur que mantenir múltiples còpies amb noms diferents.

Scripting defensiu i errors silenciosos

Una lliçó dolorosa que tots aprenem alguna vegada: si el teu script de backup falla i no ho notifica, ningú ho nota fins que ja és tard. I amb S3 això passa més del que hauria, perquè molts comandaments (aws s3 cp, sync, etc.) fallen parcialment, retornen codis no estàndard o simplement no ho reporten tot.

Recomanacions per a un scripting més confiable:

1. Fes servir set -euo pipefail en tots els teus scripts de shell.
2. Captura i valida el codi de sortida explícitament.
3. Si fas servir aws s3 sync, valida també la sortida. Un Completed 5.0 MiB/5.0 MiB pot ser enganyós si hi va haver errors en arxius intermedis.
4. No depenguis només de cron: integra alertes amb email, Slack o un sistema de monitoratge (com Zabbix, Prometheus, etc.).

Exemple de verificació explícita:

OUT=$(aws s3 cp /ruta/archivo.sql.gz s3://mi-bucket/backup/ 2>&1) || {
    echo "Fallo al subir archivo a S3"
    echo "$OUT"
    exit 1
}

I si treballes en entorns on el backup falla per falta de disc o xarxa intermitent, considera fer servir flock per evitar execucions simultànies, i logs rotatius (logrotate o similars).

Documentació i automatització

Una part que molts subestimen: documenta el procés de backup i restauració. No n’hi ha prou amb deixar un script a /usr/local/bin/backup.sh. Defineix:

1. Què es recolza (carpetes, bases de dades, arxius).
2. Amb quina freqüència.
3. On es guarda.
4. Quina versió d’awscli o rclone es requereix.
5. Com es valida i com es recupera.

I quan el procés estigui ben definit, converteix aquest coneixement en codi: automatitza la provisió del bucket, les polítiques d’IAM, els lifecycle rules. Fes servir Terraform o CloudFormation si ja els apliques al teu stack. Res d’això evita errors humans, però sí que els fa més traçables i repetibles.

Conclusió

No hi ha una única forma correcta de fer backups a S3, però sí que hi ha moltes formes dolentes que es veuen massa sovint. Les solucions simples (sync, cron, sense monitoratge) poden durar mesos sense fallar… fins que ho fan. I quan això passa, és costós.

Les estratègies que millor han funcionat en entorns reals combinen diverses capes:

1. Backups amb timestamp, controlats per scripts versionats.
2. Verificació periòdica i independent.
3. Versionat al bucket, amb lifecycle controlat.
4. Monitoratge actiu i notificacions en cas d’ error.
5. Proves regulars de recuperació.

L’objectiu no és només donar suport, sinó saber que pots recuperar, de forma controlada i dins del temps que realment importa.