Backup and disaster recovery
This page describes April9's standard availability, backup and disaster recovery (DR) commitments for hosted Stack9 instances, and the mechanism behind each one. They are standard commitments, not negotiated per engagement.
The commitments
| Measure | Commitment |
|---|---|
| Availability | At least 99.90% per month, inclusive of scheduled maintenance |
| RPO (recovery point objective) | No more than 10 minutes of data loss ahead of a disruption |
| RTO (recovery time objective) | Full-service restoration within 24 hours of a client-declared ICT disaster |
| DR test | Annually, against an approved DR test plan, with a DR Test Summary Report to the client |
| DR review | Bi-annual internal DR review, confirmed to the client in writing |
Why it is designed this way
Each commitment rests on a different mechanism, and it matters not to confuse them. The 10-minute RPO comes from continuous log-based backup, not from the snapshot schedule. The 24-hour RTO comes from being able to rebuild an environment from code rather than repair it by hand. And availability is protected mainly by making sure routine releases never consume the availability budget in the first place.
How it works
Availability: 99.90%
- Autoscaling infrastructure. ECS container orchestration with a serverless Aurora database; containers, storage and database scale with demand, so a usage spike is absorbed rather than becoming a capacity outage.
- Releases do not consume the budget. Container hot-swap deployment, automated schema migrations run by the bootstrap on container start, and automatic TLS renewal mean a release lands with virtually no downtime. See Release and upgrade model.
- Protective measures. The database sits in a private VPC subnet with no direct internet exposure, each client's instance is isolated, and network-level filtering removes denial-of-service and other malicious traffic before it reaches the application tier.
- Backups do not count against the target. Cross-region replication runs without affecting service availability.
RPO: point-in-time recovery
The 10-minute RPO is met through near-continuous, log-based backup of the Aurora database (point-in-time recovery). This is a separate mechanism from the daily snapshots and monthly backups in the backup ladder below.
Daily snapshots give a 24-hour recovery point on their own. The 10-minute RPO comes from point-in-time recovery, not from snapshots.
RTO: rebuild, not repair
The 24-hour RTO is documented in the solution's Disaster Recovery Plan, produced during implementation and agreed with the client before go-live. The architecture supports it because:
- infrastructure is defined as code and deployed through automated pipelines, so an environment is rebuilt rather than repaired;
- backups are replicated cross-region to ap-southeast-4 (Melbourne), keeping the recovery position inside Australia;
- the container bootstrap is idempotent, so a rebuilt instance brings its database schema into line with its configuration on start.
The standard backup ladder
| Backup | Cadence | Location |
|---|---|---|
| Point-in-time recovery | Near-continuous, log-based | Replicated to ap-southeast-4 (Melbourne) |
| RDS snapshots | Daily | Replicated to ap-southeast-4 (Melbourne) |
| Full database backups | Monthly | Replicated to ap-southeast-4 (Melbourne) |
Enhanced DR option
For clients whose framework asks for protection against malicious actors, including a compromised administrative account, an enhanced DR position is available as a separately priced option. It is not part of the base service.
| Element | Detail |
|---|---|
| Secondary immutable backup | For production instances, a secondary backup with administrative separation from the primary (separate credentials and policy), write-protected so it cannot be altered or deleted within its retention period, including by a compromised administrative account |
| Retention and RPO ladder | Retained for six months: daily backups (24-hour RPO) for 4 weeks, weekly backups (7-day RPO) for 3 months, monthly backups (30-day RPO) for 6 months |
| Restoration testing | Annual application restoration testing: the application is restored from backup and verified to work, not merely confirmed as backed up. Evidence is included in the annual DR Test Summary Report |
Retention
| Data | Retention | Mechanism |
|---|---|---|
| Application data (databases, file storage) | Seven years, or as the client directs, with disposal at the end of the period per the client's schedule | RDS and S3 with no automatic purge. Soft delete under audit rather than destruction |
| Audit and security logs | Two years, or longer where required | The application audit trail is versioned to S3, alongside AWS CloudTrail. Logs age through S3 lifecycle policy into lower-cost storage classes while remaining queryable and exportable in open formats |
- No tenancy-level storage cap. Retention is configuration against actual data volume, so there is no ceiling at which logs are truncated or overwritten.
- Cost moves with volume. AWS storage is on-charged at cost, so the storage line follows retained volume.
DR testing
The DR Plan is tested annually against an approved test plan, and the results are provided to the client in a DR Test Summary Report. An internal DR review runs bi-annually and is confirmed to the client in writing.
Limits
- Enhanced DR is a separately priced option, not part of the base service.
- The DR Plan is produced during implementation. The commitments are standard; the plan document is specific to each engagement.
- Where a client's own DR framework is referenced but not supplied, April9 assumes alignment with standard industry DR review practice and confirms once the framework is provided.
- Availability applies to the solution as hosted by April9. Latency and availability across the client's own WAN, carrier and egress path are outside April9's control.
- These are standard commitments; achieved performance history against them is not published here.