Un backup no sirve porque exista. Sirve cuando puedes restaurarlo. Esta frase parece obvia, pero en muchos entornos la copia se da por buena simplemente porque hay un fichero, una tarea programada o una consola que dice que el job terminó correctamente.
La realidad aparece el día que hay que recuperar: rutas incompletas, bases de datos inconsistentes, backups corruptos, claves perdidas, retenciones mal definidas, logs que nadie revisaba o copias guardadas en el mismo servidor que acaba de fallar.
No se verifica el contenido No se prueba restauración Se copia una base de datos en caliente sin consistencia No se incluyen configuraciones No se copian certificados No se guardan scripts operativos No hay retención definida No hay logs claros No hay alerta si falla La copia está en el mismo disco
Un backup útil debe estar pensado desde la recuperación, no desde la copia.
Datos de aplicación Configuración Bases de datos Certificados Secrets Scripts Crontabs Unidades systemd propias Documentación mínima
En un servidor web, por ejemplo, no basta con copiar /var/www. También pueden ser críticos /etc/apache2, /etc/nginx, /etc/letsencrypt, scripts de despliegue y tareas programadas.
Una política simple puede ser:
Diarios: 7 días Semanales: 4 semanas Mensuales: 6-12 meses
Guardar todo para siempre no es sostenible. Guardar demasiado poco puede dejarte sin punto de recuperación válido.
tar -tzf backup.tar.gz >/dev/null gzip -t backup.sql.gz pg_restore -l backup.dump >/dev/null ls -lh /backup
Verificar no es restaurar, pero detecta errores básicos: archivo corrupto, compresión dañada, fichero vacío o backup incompleto.
mkdir /tmp/restore-test tar -xzf backup.tar.gz -C /tmp/restore-test ls -lah /tmp/restore-test
Para bases de datos:
gunzip -c backup.sql.gz | mysql -u root -p base_test createdb base_test pg_restore -d base_test backup.dump
La restauración debe probarse antes de necesitarla. Bajo presión no es el momento de descubrir cómo funciona tu backup.
Todo backup automático debe dejar trazabilidad.
Inicio backup Rutas incluidas Tamaño generado Resultado de verificación Copia remota Errores Fin backup
Ejemplo:
echo "[$(date '+%F %T')] Inicio backup" >> /var/log/backup.log echo "[$(date '+%F %T')] Backup OK" >> /var/log/backup.log
Un backup manual depende de memoria humana. Eso no escala.
cron systemd timer scripts con set -euo pipefail flock para evitar concurrencia logs por ejecución alertas si falla
Ejemplo de cron:
30 2 * * * /usr/local/sbin/backup-server.sh
Pero cron sin logs ni alertas no es suficiente.
Un backup en el mismo servidor protege poco.
rsync -avz /backup/ backupuser@backup-host:/data/backups/servidor1/
Lo mínimo razonable es que la copia sobreviva a la pérdida del VPS, del disco o del filesystem principal.
Creer que snapshot equivale siempre a backup No probar restore No copiar configuración No guardar certificados No revisar logs No monitorizar fallo No tener copia externa No cifrar copias sensibles No documentar recuperación No saber cuánto tarda restaurar
Datos críticos identificados Configuración incluida Base de datos copiada correctamente Backup verificado Restauración probada Retención definida Logs activos Alertas configuradas Copia externa validada Permisos revisados Cifrado aplicado si procede Procedimiento documentado
Un backup útil no se mide por cuántos ficheros genera, sino por la confianza que tienes al restaurarlo. La copia es solo una parte. La prueba real es recuperar servicio, datos y configuración en un tiempo aceptable.
En producción, un backup no probado es una promesa. Y las promesas no restauran sistemas.