Backup and Recovery Policy
1. Purpose
Section titled “1. Purpose”Defines requirements for backing up and recovering Meridian Seven systems and data within defined recovery objectives.
2. Scope
Section titled “2. Scope”All production systems, databases, and data stores supporting Meridian Seven services, including customer data, application configurations, and operational data.
3. Recovery Objectives
Section titled “3. Recovery Objectives”| Objective | Target | Definition |
|---|---|---|
| RTO | 4 hours | Maximum time from incident to service restoration |
| RPO | 24 hours | Maximum acceptable data loss (worst case) |
Targets apply to all critical systems. Non-critical systems may have relaxed targets documented in the system inventory.
4. Backup Systems
Section titled “4. Backup Systems”4.1 Database — Supabase PITR
Section titled “4.1 Database — Supabase PITR”| Parameter | Value |
|---|---|
| System | Supabase PostgreSQL |
| Method | Continuous WAL archiving with Point-in-Time Recovery |
| Frequency | Continuous |
| Retention | 7 days |
| Encryption | AES-256 at rest |
| Location | Supabase managed infrastructure |
Recovery: Supabase dashboard → Database → Backups → select timestamp → initiate PITR → verify integrity → update connection strings if new instance.
4.2 Google Workspace — Cube Backup
Section titled “4.2 Google Workspace — Cube Backup”| Parameter | Value |
|---|---|
| System | Google Workspace (Gmail, Drive, Calendar, Contacts) |
| Method | Incremental via Cube Backup |
| Frequency | Daily |
| Retention | 365 days |
| Encryption | AES-256 at rest, TLS in transit |
| Location | Backblaze B2 (US) via Cube Backup |
Recovery: Cube Backup dashboard → locate user/file/mailbox → select backup point → restore → verify completeness.
4.3 Object Storage — Backblaze B2
Section titled “4.3 Object Storage — Backblaze B2”| Parameter | Value |
|---|---|
| System | File and document storage |
| Method | Versioned object storage with lifecycle rules |
| Frequency | Daily sync |
| Retention | 90 days (versioned) |
| Encryption | AES-256 at rest, TLS in transit |
| Location | Backblaze B2 US |
Recovery: Backblaze dashboard or b2 CLI → list versions → download → restore → verify integrity.
4.4 Source Code — GitHub
Section titled “4.4 Source Code — GitHub”| Parameter | Value |
|---|---|
| System | All application source code |
| Method | Git distributed version control |
| Frequency | Continuous (every push) |
| Retention | Full history (indefinite) |
| Encryption | GitHub managed |
Branch protection rules prevent force-push to main. Every clone is a full backup.
4.5 Secrets and Configuration — Doppler
Section titled “4.5 Secrets and Configuration — Doppler”| Parameter | Value |
|---|---|
| System | Environment variables, API keys, secrets |
| Method | Versioned config with audit log |
| Frequency | Every change (versioned) |
| Retention | Full change history |
| Encryption | AES-256 at rest, TLS in transit |
Any previous version can be restored instantly.
5. Backup Schedule Summary
Section titled “5. Backup Schedule Summary”| System | Method | Frequency | RPO | Retention |
|---|---|---|---|---|
| PostgreSQL (Supabase) | PITR / WAL | Continuous | Minutes | 7 days |
| Google Workspace | Cube Backup | Daily | 24 hours | 365 days |
| Object Storage | Backblaze B2 | Daily | 24 hours | 90 days |
| Source Code | GitHub / Git | Continuous | Minutes | Indefinite |
| Secrets / Config | Doppler | Continuous | Minutes | Indefinite |
6. Backup Verification
Section titled “6. Backup Verification”- Failed backup alerts sent to Slack #ops; investigated within 4 hours
- Weekly: verify backup jobs are on schedule, retention policies enforced, storage capacity reviewed — documented in Weekly Security Review GitHub issue
- Quarterly restoration tests:
| Test | Procedure | Success Criteria |
|---|---|---|
| Database restore | Restore Supabase PITR to test instance | Data integrity verified, application connects |
| Google Workspace restore | Restore sample mailbox and Drive files | Files and emails match expected content |
| File restore | Restore sample files from Backblaze B2 | File integrity verified via checksum |
Restoration test results retained for audit: date, systems tested, recovery time, issues, remediation.
7. Disaster Recovery Procedures
Section titled “7. Disaster Recovery Procedures”7.1 Database Corruption or Loss
Section titled “7.1 Database Corruption or Loss”- Declare incident per Incident Response Plan
- Assess scope of data loss/corruption
- Initiate Supabase PITR to most recent clean point
- Verify data integrity; update application connections if needed
- Conduct post-incident review
7.2 Cloud Service Provider Outage
Section titled “7.2 Cloud Service Provider Outage”- Check provider status page and estimated recovery time
- If RTO is at risk, initiate failover:
- Cloud Run outage (web): DNS failover to static maintenance page via Cloudflare
- Cloud Run outage (agents): Agent service is degraded; notify customers via status page
- Supabase outage: Application enters read-only/degraded mode; await recovery or initiate PITR to alternate instance
- Communicate via GCP Cloud Monitoring status dashboard; document incident
7.3 Ransomware or Destructive Attack
Section titled “7.3 Ransomware or Destructive Attack”- Isolate affected systems immediately
- Assess scope of compromise
- Do NOT pay ransom
- Restore from backups predating the compromise
- Rotate all credentials via Doppler
- Conduct full security investigation; report to law enforcement if appropriate
8. Data Retention Periods
Section titled “8. Data Retention Periods”| Data Type | Retention | Disposal Method |
|---|---|---|
| Production database backups | 7 days (PITR window) | Automatic expiration |
| Google Workspace backups | 365 days | Automatic expiration via Cube Backup |
| File storage backups | 90 days (versioned) | Lifecycle rule expiration |
| Audit logs | 3 years | Secure deletion |
| Incident records | 3 years | Secure deletion |
| Financial records | 7 years | Secure deletion |
9. Roles and Responsibilities
Section titled “9. Roles and Responsibilities”| Role | Responsibility |
|---|---|
| CTO | Policy owner; approves DR procedures; owns quarterly restoration tests |
| CISO | Monitors backup compliance; includes in security reviews |
| Engineering Lead | Assists with restoration tests; maintains backup configurations |
| On-Call Engineer | Responds to backup failure alerts; initiates DR procedures |
10. Related Documents
Section titled “10. Related Documents”- Information Security Policy
- Incident Response Plan
- Data Classification Policy
Meridian Seven — Confidential