Guía de Copia de Seguridad Automatizada en Linux para Almacenamiento S3

La pérdida de datos en servidores de producción puede destruir la reputación de una empresa y causar enormes perjuicios financieros. Aunque los proveedores de VPS ofrecen snapshots de disco, contar con copias de seguridad independientes y almacenadas fuera del servidor de origen es una regla de oro de la infraestructura.

En esta guía, enseñamos cómo crear una rutina automatizada de copia de seguridad de archivos y bases de datos hacia el almacenamiento en la nube Amazon S3 (o cualquier object storage compatible, como MinIO o Backblaze).

1. Configurando las Credenciales (AWS CLI)

La herramienta recomendada para interactuar con S3 desde la terminal de Linux es AWS CLI.

Instalación y Configuración:

1. Instale el paquete:
   sudo apt install awscli -y
2. Cree una clave de acceso (Access Key y Secret Key) en la consola de AWS a través del servicio IAM, limitando los permisos únicamente a acciones en el bucket de copia de seguridad deseado.
3. Configure las credenciales en el servidor Linux ejecutando:
   aws configure

2. Escribiendo el Script de Copia de Seguridad

Cree un script en bash para automatizar el volcado (dump) de la base de datos (en este ejemplo, PostgreSQL) y la compresión de la carpeta de archivos estáticos.

#!/bin/bash

# Configuraciones
BACKUP_DIR="/tmp/backups"
BUCKET_NAME="mi-bucket-de-backup-seguro"
DATA=$(date +%Y-%m-%d-%H%M)

# Crear carpeta temporal
mkdir -p $BACKUP_DIR

# 1. Copia de Seguridad de la Base de Datos
pg_dump -U postgres mi_base_datos > $BACKUP_DIR/db_$DATA.sql

# 2. Compresión de los archivos de la aplicación
tar -czf $BACKUP_DIR/archivos_$DATA.tar.gz /var/www/mi-app

# 3. Envío cifrado a S3
aws s3 cp $BACKUP_DIR/db_$DATA.sql s3://$BUCKET_NAME/db_$DATA.sql --sse AES256
aws s3 cp $BACKUP_DIR/archivos_$DATA.tar.gz s3://$BUCKET_NAME/archivos_$DATA.tar.gz --sse AES256

# Limpieza de archivos locales temporales
rm -rf $BACKUP_DIR

3. Automatizando con Cron Job

Para ejecutar el script automáticamente todas las noches (a las 02:00 de la mañana):

1. Abra las tareas programadas del sistema:
   sudo crontab -e
2. Agregue la línea al final del archivo:
   0 2 <em class="text-slate-400"> </em> * /home/usuario/scripts/backup.sh > /dev/null 2>&1

4. Restaurar en una base de prueba

La copia solo vale si la restauración se ensayó. Baje el dump a una base vacía, nunca encima de producción:

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

\dt lista las tablas. Si la lista está vacía, el dump no entró. Los archivos de la aplicación vuelven a un directorio aparte:

aws s3 cp s3://mi-bucket-de-backup-seguro/archivos_2026-10-01-0200.tar.gz /tmp/archivos.tar.gz
sudo mkdir -p /var/www/restore-prueba
sudo tar -tzf /tmp/archivos.tar.gz | head
sudo tar -xzf /tmp/archivos.tar.gz -C /var/www/restore-prueba

tar -tzf lista el contenido antes de extraer. Confirme la primera ruta. Un archivo que empieza con / extrae en la raíz del destino y puede sobrescribir la aplicación. Borre /tmp/restore.sql después de la prueba. El cron de la sección 3 tiene que escribir un log, no /dev/null, para el día en que pg_dump falle:

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

Conclusión

Contar con políticas de copia de seguridad automatizadas y almacenadas fuera de la infraestructura de origen es indispensable. Configurando el cifrado a nivel de S3 y monitoreando la ejecución de estos scripts, su negocio estará totalmente protegido contra eliminaciones accidentales, desastres de hardware o ataques cibernéticos.