Post-Mortem: Cuando los Backups Automatizados fallan y el SII te respira en la nuca (Guía de Supervivencia)

El Viernes Negro

17:45 de un viernes. Clásico. Terminando el día y pensando en el taco de Vespucio, cuando me entra la llamada de un viejo amigo, típico dueño PYME que encuentra caro pagar soporte informático mensual...

—"Compadre, no entra el sistema. Dice que los archivos están encriptados. Y hay un archivo de texto pidiendo Bitcoins."

Maaal... Ransomware PYME. El terror de cualquier Soporte TI en Santiago.

Le dije lo que todo ingeniero dice para calmar las aguas: "Tranquilo, tenemos **backups automatizados* diarios a las 3 AM. Borramos todo, restauramos y el lunes operan normal."*

Me conecté por VPN, fui a la carpeta /var/backups/ y ahí estaban los archivos .sql.gz. Todos con fecha de hoy. Pesaban 45KB.

45KB.

Una base de datos de 10 años de facturación no pesa 45KB. Al abrir el archivo, no había INSERT INTO. Solo había un mensaje de error de mysqldump que se había guardado como si fuera el respaldo.

Llevaban 6 meses respaldando un error. 6 meses de Facturación Electrónica SII a la basura.

Si crees que esto no te puede pasar porque tienes un cronjob corriendo, siéntate. Te voy a explicar cómo la recuperación de desastres es lo único que te separa de la quiebra (y de las multas del fisco).

Cuando el SII se suma a la fiesta

En Chile, perder datos no es solo un problema técnico; es un problema tributario grave.

El Ransomware PYME no solo te bloquea la operación. Si pierdes el libro de ventas o las referencias de la Facturación Electrónica SII, entras en un terreno pantanoso.

Según la normativa vigente (y el Código Tributario, Art. 97), el "no llevar contabilidad" o la pérdida de registros puede acarrear multas que duelen. Estamos hablando de sanciones que van desde 1 UTM hasta el 50% o 300% de los impuestos eludidos si no puedes probar tus ventas.

¿Sabes cuánto cuesta reconstruir la contabilidad de un año a mano? Mucho más que contratar una consultoría preventiva de ciberseguridad en Chile.

El problema real es la falsa sensación de seguridad. El 90% de los sysadmins configuran el backup y nunca, jamás, hacen un simulacro de restauración hasta que tienen el fuego en la cocina.

Un Script de Backup "A Prueba de Balas"

Olvídate de los scripts de una línea. Un script bash backup decente tiene que validar que lo que guardó sirve.

Aquí te dejo la versión sanitizada del script que implementamos después del desastre. Copia, pega y adáptalo. Esto no es código de tutorial, es código de producción.

#!/bin/bash

# ---------------------------------------------------------
# AUTOR: Tu SysAdmin de Confianza
# DESCRIPCIÓN: Backup MySQL con verificación de integridad
# y subida a Nube (S3/MinIO).
# ---------------------------------------------------------

# CONFIGURACIÓN
DB_USER="root"
DB_PASS="TuPasswordSuperSegura123"
DB_NAME="facturacion_prod"
BACKUP_DIR="/mnt/backups/mysql"
DATE=$(date +%Y-%m-%d_%H%M)
FILENAME="backup_${DB_NAME}_${DATE}.sql.gz"
LOG_FILE="/var/log/db_backup.log"
SLACK_WEBHOOK="https://hooks.slack.com/services/T000/B000/XXXX"

# Función de Log
log_message() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> $LOG_FILE
}

log_message "INICIO: Comenzando backup de ${DB_NAME}"

# 1. DUMP DE LA BASE DE DATOS
# Usamos --single-transaction para no bloquear tablas InnoDB en producción
mysqldump -u $DB_USER -p$DB_PASS --single-transaction --quick --lock-tables=false $DB_NAME | gzip > $BACKUP_DIR/$FILENAME

# Verificamos código de salida de mysqldump (PIPESTATUS para capturar el error antes del gzip)
if [ ${PIPESTATUS[0]} -ne 0 ]; then
    log_message "ERROR CRÍTICO: Falló el mysqldump. Abortando."
    curl -X POST -H 'Content-type: application/json' --data '{"text":"🚨 FALLÓ BACKUP DB: Error en mysqldump"}' $SLACK_WEBHOOK
    exit 1
fi

# 2. VALIDACIÓN DE INTEGRIDAD (El paso que todos se saltan)
# Verificamos que el archivo no esté vacío y tenga un tamaño mínimo (ej. 1MB)
FILESIZE=$(stat -c%s "$BACKUP_DIR/$FILENAME")
MINSIZE=1048576 # 1MB en bytes

if [ $FILESIZE -lt $MINSIZE ]; then
    log_message "ERROR: El backup pesa menos de 1MB ($FILESIZE bytes). Sospechoso."
    curl -X POST -H 'Content-type: application/json' --data '{"text":"⚠️ ALERTA: Backup generado es sospechosamente pequeño."}' $SLACK_WEBHOOK
    # No borramos, pero alertamos.
else
    log_message "ÉXITO: Backup generado. Tamaño: $(($FILESIZE / 1024 / 1024)) MB"
fi

# 3. PRUEBA DE RESTAURACIÓN (La prueba de fuego)
# Restauramos en una DB temporal para asegurar que el SQL es válido
TEST_DB="test_restore_db"
mysql -u $DB_USER -p$DB_PASS -e "DROP DATABASE IF EXISTS $TEST_DB; CREATE DATABASE $TEST_DB;"
zcat $BACKUP_DIR/$FILENAME | mysql -u $DB_USER -p$DB_PASS $TEST_DB

if [ $? -eq 0 ]; then
    log_message "VERIFICACIÓN: Restauración en DB de prueba exitosa."
    # Limpieza
    mysql -u $DB_USER -p$DB_PASS -e "DROP DATABASE $TEST_DB;"
else
    log_message "ERROR FATAL: El backup no se pudo restaurar."
    curl -X POST -H 'Content-type: application/json' --data '{"text":"🔥 ERROR CRÍTICO: El backup está corrupto, no pasa el restore test."}' $SLACK_WEBHOOK
    exit 1
fi

# 4. OFFSITE COPY (AWS S3 CLI)
# aws s3 cp $BACKUP_DIR/$FILENAME s3://mi-bucket-backups/
# log_message "Subido a S3"

exit 0

Cómo perder tu pega en 3 pasos

Hemos visto varios servidores morir y siempre es por lo mismo. Si estás cometiendo estos errores, arréglalos hoy. No mañana. Hoy.

A. El Backup Local ("Backup nube local vs AWS")

Guardar el backup en el mismo disco duro donde está la base de datos (/var/lib/mysql y /home/backups en el mismo disco físico). Si el disco muere, pierdes los datos y el respaldo.
Solución: Mínimo un montaje NFS externo, o mejor, directo a S3/Azure Blob. La regla 3-2-1 es sagrada: 3 copias, 2 medios, 1 offsite.

B. Ignorar la "Normativa SII respaldo digital"

Muchos creen que con tener los XML en el portal del proveedor de facturación basta. Grave error si usas un ERP propio o un sistema de gestión, ya que la responsabilidad de la integridad de la data histórica es tuya. Ante una fiscalización, el SII te va a pedir libros mayores y auxiliares. Si tu base está corrupta, prepárate para las multas SII por pérdida de datos.

C. El "Script Silencioso"

El script corre, falla, y no le avisa a nadie. Pasan meses. Cuando vas a buscar el archivo, te das cuenta de que el disco se llenó en febrero y estamos en agosto.
Solución: Monitoreo activo. Si el backup se hace o no, debe sonar una alarma. El silencio no es éxito.

Conclusión: No seas el héroe, sé el paranoico

La recuperación de desastres no es un producto que compras, es una mentalidad. Ese viernes en Patronato logramos recuperar data de un disco viejo que el dueño tenía en su casa (pura suerte), pero perdieron 2 semanas de ventas. El costo operativo fue brutal.

¡No esperes a tener el ransomware en la pantalla para preocuparte!

Si este post te incomodó porque te hizo recordar alguna mala práctica... revisa tus crons ahora mismo y valida tus respaldos, pruébalos.

Si necesitas estructurar un plan serio de respaldos y dejar de sufrir con la informática, apóyate en un equipo de Soporte TI y Continuidad Operativa que mantenga tus sistemas andando.

Si sabes de alguien que tiene la idea de que no necesita una empresa de soporte TI porque tiene "un amigo que lo puede ver", cuéntale esta historia de lo caro que le puede salir.

¿Y tú? ¿Ya verificaste que están sanos los respaldos? Comenta (y sé honesto, que aquí no juzgamos... tanto).