Check Designer — Backup & Restore Policy (Draft)
Status: Draft administrative policy — subject to attorney review before commercial launch.
Operator detail: Technical procedures remain in `BACKUP_RESTORE_RUNBOOK.md` and `RESTORE_AND_RECOVERY.md`.
1. Purpose
This policy explains what is backed up, who performs restore, and what customers can export in current Check Designer deployments.
2. Backup scope
2.1 Operator-managed backups (production)
The operator runs scheduled backups (e.g., `check-designer-daily-backup.sh`) that typically include:
| Asset | Included |
|---|---|
| SQLite database (`prod.db`) | Yes — all tenants in instance file |
| Manifest + SHA256 checksums | Yes |
| Optional config archive | May include paths to Nginx, PM2, TLS — not `.env` contents in manifest |
| MICR font files | Often included or documented separately |
Critical: `BANK_DATA_ENCRYPTION_KEY` lives in `.env` — must be backed up separately (password manager / secure vault). Restoring the database without the correct key prevents decryption of account numbers and signatures.
2.2 Customer-initiated export (in-app)
Users with backup permission may download:
| Export | Scope | Sensitive data |
|---|---|---|
| Database backup (`GET /api/backup/database`) | Entire SQLite file for this deployment | Contains encrypted blobs; still highly sensitive |
| Project JSON (`GET /api/backup/project-json`) | Structured export | Account numbers and signatures redacted in JSON; MICR fonts not included |
Both exports are audited. Database download is instance-wide — not per-tenant filtering in current implementation.
3. Restore
| Actor | Capability |
|---|---|
| Operator | Restore from backup using server restore script (dry-run default; `--apply` requires explicit approval) |
| Customer self-service restore | Not provided in-app — restore is an operator action |
Restore may overwrite `prod.db`. Pre-restore snapshots should be taken per runbook. Do not run production restore without approval.
Restore drill scripts copy backups to an isolated test path — they do not overwrite production `prod.db` during drills.
4. Retention
Daily and manual backups are retained per operator disk policy (often 30+ days). See `DATA_RETENTION_POLICY.md`.
Customers should not rely solely on operator backups for regulatory record-keeping — maintain your own copies if required.
5. PostgreSQL (future)
A planned migration may move production to PostgreSQL. Backup tooling would transition to Postgres-aware scripts after cutover approval. Until then, SQLite backup policy above applies.
6. RTO / RPO (placeholders)
| Metric | Draft placeholder |
|---|---|
| RPO (max data loss) | *[Define at launch — e.g., 24h if daily backup only]* |
| RTO (time to restore service) | *[Define at launch — operator-dependent]* |
7. Customer responsibilities
- Request exports before major configuration changes
- Store exports securely; treat database downloads like production secrets
- Coordinate with operator for disaster recovery — do not attempt unsupported restore steps on production server without operator involvement
8. No guarantee
Backups reduce risk but do not guarantee recovery from all failure modes (corruption, ransomware, key loss). Attorney and operational review required before SLA commitments.
*Draft only — backup scripts and API behavior unchanged in Phase 2P-A.*