Backups & Disaster Recovery
This statement summarises how Agentic Labs LLC protects customer data against loss and how we restore service after a disruption. It is maintained by Agentic Labs LLC and reflects the current production configuration.
1. Recovery objectives
| Metric | Target | Scope |
|---|---|---|
| RPO (Recovery Point Objective) | ≤ 24 hours | Primary application database; managed object storage |
| RTO (Recovery Time Objective) | ≤ 4 hours | Restoration of core platform read/write functionality |
| PITR window | 7 days rolling | Primary application database |
Targets apply to the production environment under normal failure conditions (single-region infrastructure failure, accidental deletion, data corruption). They are objectives, not contractual SLAs unless agreed separately in writing.
2. What is backed up
- Primary database (Postgres, managed): continuous WAL archiving with point-in-time recovery and daily automated snapshots.
- Object storage (reports, exports, user-uploaded artefacts): versioned with managed replication.
- Configuration & infrastructure-as-code: stored in version control with full history.
- Secrets: stored in the managed secrets store; recovered from the platform's encrypted backups, never exported to backup files.
3. Backup mechanics
- Frequency: continuous WAL streaming + daily snapshots for the database; continuous versioning for object storage.
- Retention: 7 days of point-in-time recovery; 30 days of daily snapshots.
- Encryption: AES-256 at rest, TLS 1.2+ in transit, for both live data and backups.
- Isolation: backups are stored in separate, access-controlled storage from the live database; production credentials cannot delete historical snapshots.
- Geographic redundancy: backups are replicated across multiple availability zones within the primary region.
4. Restore testing
We test restores from production backups at least quarterly. Tests cover (a) full database restore to a clean environment, (b) point-in-time restore to a specific timestamp, and (c) object-storage version rollback. Results and any remediation items are tracked internally.
5. Disaster recovery scenarios
| Scenario | Response | Target |
|---|---|---|
| Accidental data deletion or corruption (single tenant) | Point-in-time restore to staging, targeted re-import | RTO ≤ 4h · RPO ≤ 5 min |
| Database instance failure | Managed failover to standby instance | RTO ≤ 15 min · RPO ≤ 1 min |
| Availability-zone failure | Automatic re-balancing to healthy AZs in the same region | RTO ≤ 1h · RPO ≤ 5 min |
| Full region failure | Restore from cross-region backups into the secondary region | RTO ≤ 24h · RPO ≤ 24h |
| Ransomware / malicious deletion of live data | Restore from immutable backup snapshot prior to compromise | RTO ≤ 4h · RPO ≤ 24h |
6. Incident communication
During a major incident affecting availability or data integrity, we communicate via in-product banner and email to account administrators. Post-incident reviews for severity-1 incidents are shared on request to affected customers under NDA.
7. Customer-side responsibilities
- Maintain accurate administrator contact details for incident notifications.
- Where required by internal policy, export your own copy of watchlists, reports and audit logs via the API on a schedule appropriate to your risk appetite.
- Protect API tokens and rotate them on personnel changes — restores cannot recover from credential compromise that occurred after the last clean snapshot.
8. Changes
This statement reflects the current configuration. Material changes to RPO, RTO, retention or geographic posture will be reflected here and, where they reduce protection, communicated to account administrators in advance.
9. Contact
Procurement and security questions: security@ctizero.com.