backup_daily.sh · sqlite3 .backup + PRAGMA integrity_check + gzip + rotación 7 días · retención por tiers (ADR-0012) · frescura verificada por check_backup_freshness.

El principio

Un backup que no se ha verificado no es un backup: es un archivo con esperanza. La política de iForja es que cada backup pasa una comprobación de integridad (PRAGMA integrity_check) en el momento de crearse, y que su frescura se verifica de forma independiente por los hardening checks.

Script canónico

El backup diario lo genera un único script real:

scripts/backup_daily.sh   · snapshot diario del SQLite (cron / systemd timer)

Lo que hace, paso a paso (según el propio script):

1 · SNAPSHOT

sqlite3 .backup (no copia raw, evita corrupción WAL)

→

2 · INTEGRIDAD

PRAGMA integrity_check · si no es ok, borra y sale con error

→

3 · COMPRESIÓN

gzip -9 del snapshot verificado

→

4 · ROTACIÓN

Borra backups > 7 días · escribe manifest LATEST

# Cronjob recomendado (03:00 hora local):
0 3 * * * /data/assistant/Forja/scripts/backup_daily.sh >> .../backup.log 2>&1

Política de retención (ADR-0012)

La retención por tiers está definida como política en ADR-0012. El backup diario cubre el tier operativo local (7 días); la aplicación completa de los tiers de largo plazo es parte del roadmap de enforcement.

Tier · datoRetención

T1 Legal/Audit · audit_events, approvals, compliance_*, ADRs10 años

T2 Financiero · registros transaccionales de tenants regulados7 años

T3 Operacional · checkpoints, plans, logs runtime2 años

T4 Efímero · session memory, working set, caches90 días

T5 PII · datos personales identificablesmínimo legal

Justificación regulatoria (ADR-0012): T1 responde a EU AI Act Art. 18; T2 al sector banca/seguros; T5 a la minimización de GDPR. El hash chain de audit_events se preserva a través del archivado.

Verificación de frescura

La comprobación automática la realiza el hardening check check_backup_freshness (ver Hardening checks):

Verifica que existe un backup con antigüedad ≤ 24 h en el directorio de backups.
Si el directorio no existe o no hay backups → hallazgo critical/high.
Si el backup más reciente está caducado → hallazgo high (release-blocking).

Es una verificación de frescura e integridad en creación, complementaria a un restore-test completo (reconstrucción total + verificación de la hash chain), que forma parte del roadmap de verificación.

Retención local y almacenamiento de largo plazo

Local (hot) · 30 días en el directorio de backups · rotación automática por backup_daily.sh
Archivado de largo plazo · política ADR-0012: snapshot periódico a almacenamiento frío para los tiers legales/financieros

El archivado cifrado a almacenamiento frío externo (USB/cloud del cliente con cifrado client-side) está definido como política en ADR-0012 y es parte del roadmap de enforcement; no está implementado dentro del script de backup diario. Documentado aquí como intención, no como funcionalidad activa.

Integración con audit / compliance

ISO 27001 A.8.13 · Information backup → cubierto por backup_daily.sh + check_backup_freshness
Retención (ADR-0012) → soporte de evidencia para los tiers legal y financiero
Auditor externo → puede reconstruir un backup recibido de forma independiente y correr PRAGMA integrity_check sobre él

Backup y restore