1. Purpose
Define the backup, restoration, and failover commitments SlashLogixx makes for the Spark platform and SlashLogixx-operated products, so that customers can size their own resilience plans against ours.
2. Recovery Objectives
| Objective | Target | Scope |
|---|---|---|
| RTO (Recovery Time) | ≤ 4 hours | Hosted Spark tiers (Cloud, Connect, Studio IDE) |
| RPO (Recovery Point) | ≤ 24 hours | Customer data hosted by SlashLogixx |
| Backup retention | 30 days, rolling | Daily snapshots; longer retention by contract |
| Backup encryption | AES-256 at rest | All backup artifacts |
| Off-site copy | Separate region | Critical customer data |
"Target" is the commitment we plan and exercise against. Actual recovery on a given event may be faster or slower. Material misses are written up in a post-mortem under the Incident Response policy.
3. Backups
- Database snapshots are taken at least daily and verified for restorability on a recurring basis.
- Object storage carrying customer artifacts is configured for cross-region durability.
- Configuration and infrastructure-as-code is held in version control; the entire platform can be re-stood up from source with no manual state.
4. Restore Testing
- A representative database restore is performed at least quarterly. Successful restores are recorded; failures trigger remediation tickets and re-testing.
- A full disaster-recovery drill (failover to a secondary region) is performed at least annually.
5. Failure Modes
- Single-host failure. Automatic failover via the underlying cloud provider; no customer action.
- Region degradation. Manual failover to a secondary region within the stated RTO.
- Vendor outage. Where a critical subprocessor is the source of failure, status updates are published to customers and (where feasible) traffic is routed away from the affected dependency.
- Catastrophic loss. Restoration from off-site backups; communication cadence follows the incident-response severity table.
6. Customer Responsibilities
- Customers are encouraged to maintain their own export of business-critical data using the Platform's export tooling.
- Spark Studio and Spark OnPrem customers are responsible for backup, restore, failover, and DR on the infrastructure they operate. SlashLogixx provides reference guidance on request.
7. Communication During Disruption
- For SEV-1 or SEV-2 events, SlashLogixx posts status and ETA updates to affected customers no less than every two (2) hours until service is restored.
- Post-mortems are published or shared with affected customers within ten (10) business days of resolution.
8. Business-Continuity (Non-Tech) Events
For events affecting SlashLogixx as a business (key-person loss, facility loss, prolonged communication outage), a designated alternate is identified for every critical operational role. Customer-facing service continuity does not depend on the availability of any single individual.
9. Plan Review
This plan is reviewed annually, after every SEV-1 incident, and after any material change in platform architecture.
10. Contact
For BCP/DR evidence requests, audit walkthroughs, or to obtain the most recent restore-test summary: security@slashlogixx.com.