Backup + restore

Hub records are the most critical Claresia data — the org-memory store. Every deployment mode includes backup + restore. This page covers the policies, RPO/RTO targets, and the operational drill you should run quarterly.

Per-mode backup matrix

Mode	Backup mechanism	Retention	RPO	RTO
A Shared	Daily Aurora snapshot, multi-AZ replication	35 days	5 min	4 hours
B Dedicated	Daily Aurora snapshot + weekly cross-region copy + multi-AZ replication	90 days	5 min	1 hour
C BYOC	Customer-controlled (Terraform module ships defaults)	Customer-defined	Customer-defined	Customer-defined

• RPO (Recovery Point Objective): max acceptable data loss
• RTO (Recovery Time Objective): max acceptable time to restore

Mode A — Shared

• Aurora cluster takes automated daily snapshots, retained 35 days
• Multi-AZ failover (writes acknowledged across 3 AZs)
• Cross-region copy NOT included (upgrade to Mode B for that)

Restore options

• Point-in-time recovery within last 7 days, to any second
• Snapshot restore within last 35 days
• All restores are tenant-scoped (RLS reapplies; no cross-tenant access)

How to request a restore

1. Open a Sev 1 ticket in Slack/Teams Connect channel
2. Specify the restore point (timestamp) + which records (record_id, time range, record_type, etc.)
3. Claresia restores to a parallel Hub instance, validates, then swaps DNS
4. Estimated wall-clock: 4 hours (RTO target)

Mode B — Dedicated

Same as Mode A plus:

• Weekly cross-region copy to your DR region (eu-central-1 if primary eu-south-1; or reverse for EU)
• Snapshots retained 90 days
• Customer-rotatable CMEK protects snapshots (your KMS key encrypts the snapshot)

Restore options

• Point-in-time recovery within last 35 days, to any second
• Snapshot restore within last 90 days
• Cross-region restore within last 14 days (most recent weekly copy)

How to request a restore

Same as Mode A but RTO target is 1 hour.

Mode C — BYOC

Customer-controlled. The Claresia Terraform module ships defaults that mirror Mode B (daily snapshot + multi-AZ + 90-day retention), but you can change anything.

Customer responsibilities

• Configure backup retention to meet your compliance requirements
• Test restores quarterly (Claresia provides the test script)
• Maintain CMEK key custody (without it, snapshots are unrecoverable)

Customer-managed Postgres example

# Snapshot
aws rds create-db-cluster-snapshot \
  --db-cluster-identifier claresia-dainese-hub \
  --db-cluster-snapshot-identifier claresia-dainese-hub-2026-05-03

# List
aws rds describe-db-cluster-snapshots \
  --db-cluster-identifier claresia-dainese-hub

# Restore to a new cluster (parallel)
aws rds restore-db-cluster-from-snapshot \
  --db-cluster-identifier claresia-dainese-hub-restored \
  --snapshot-identifier claresia-dainese-hub-2026-05-03 \
  --kms-key-id <your-cmek-key>

After restore, run the verification CLI:

claresia-hub-verifier verify \
  --backend postgres \
  --dsn 'postgres://...claresia-dainese-hub-restored...' \
  --tenant dainese \
  --cosign-public-key ~/.claresia/cosign-pub.pem

Quarterly restore drill (recommended for Mode B/C)

1. Pick a non-prod time window
2. Trigger a restore to a parallel instance (DOES NOT affect production)
3. Run the verifier — every record should pass provenance + cosign
4. Compare a sample of records to production (record_id-by-record_id) — 100% match expected
5. Document the wall-clock time → record as a governance_event of kind backup.drill_completed
6. Review with your compliance team

The drill does not cause downtime. Production keeps serving from the live instance throughout.

What we DON’T back up

• Telemetry events older than the retention window (purged per retention)
• LLM platform-side conversation history (lives in Anthropic / Microsoft / OpenAI / Google — their backup story applies)
• Browser extension cached state (LRU, no permanence)
• Adaptive Card render history (renders are derived; no need to back up)

Right-to-erasure interaction

When a customer purges a record per GDPR Art. 17, the purge propagates to:

• Live primary
• All in-flight read replicas
• All snapshots within retention window (Claresia rewrites to encrypted-blob marker)
• Cross-region copy (synchronous purge)

Restoring a snapshot from before the purge will not resurrect the purged records — they’re cryptographically erased from snapshots within 24 hours of the purge request.

Backup integrity verification

Claresia runs monthly automated integrity checks on all backups:

1. Random snapshot pick
2. Restore to a sandbox cluster
3. Run claresia-hub-verifier on every record
4. Generate a report
5. If any tampered or cosign_invalid records found: page on-call
6. Report shared with all Mode B/C customers as a governance_event of kind backup.integrity_check_passed

Customer escalation if backup-related issue

• Slack/Teams Connect channel
• Email backup@claresia.com (Sev 1 — paged 24/7)
• Phone hotline (Mode B/C only) — your CSM can provide

Reference

• Hub schema
• Retention
• Storage backends
• Provenance + Audit