Availability, Live DR, backup and the vault
The three availability tiers, the continuity patterns with their RPO and RTO, how Live DR is proven and drilled, the backup policy per environment, long-term retention, and the air-gapped vault.
Availability tiers (production, proposed default)
| Tier | Availability | What it is |
|---|---|---|
| Standard | 99.7% | Multi-zone, HA database, air-gapped backups. |
| Live DR | 99.9% | A second region running live. |
| Live DR Premium | 99.95% | Traffic in both regions, 24×7 priority response. |
Non-production: 95%. Measured monthly at the TRANXACT ingress, excluding the agreed maintenance window. Cloud-provider SLAs sit underneath the one TRANXACT commitment.
Fix the tier before sizing. Live DR runs a full-size second region, which roughly doubles runtime infrastructure cost. Show it as its own line against the downtime cost it removes, and hold integrated third-party systems to the same tier.
Planned and unplanned events
| Event | What happens | Counts against the SLA? |
|---|---|---|
| Planned — updates, resizes, drills | Rolling updates across three nodes keep users working. Downtime changes only in the monthly window (proposed 4 hours). | No, inside the agreed window. |
| Unplanned, in-region — node, pod or zone failure | Pods rescheduled; the database fails over to its synchronous standby. RPO ≈ 0, recovery in minutes. | Only if the tier target is missed. |
| Unplanned, region-wide | With Live DR, the replica is promoted and the traffic manager moves writes. RPO seconds, RTO ≤ 15 minutes (proposed). | Per the tier. |
Continuity patterns
| Pattern | RPO / RTO | Node | DB | Zone | Region | Ransomware |
|---|---|---|---|---|---|---|
| Standard HA (99.7%) | Zone: RPO ≈ 0. Region: restore from vault. | Yes | Yes | Yes | No | Yes |
| Live DR (99.9%) | RPO seconds, RTO ≤ 15 min | Yes | Yes | Yes | Yes | Yes |
| Live DR Premium (99.95%) | RPO seconds, RTO ≤ 5 min | Yes | Yes | Yes | Yes | Yes |
| Passive DR (typical SaaS) — not offered | RPO minutes–hours, RTO hours | Yes | Yes | Yes | Uncertain | No |
Live DR is not a passive standby. The second region runs a full-size cluster and a continuously replicated database, serving live reads, reporting, ASK queries and synthetic postings. Its health is proven every minute, and failover is a promotion — nothing is scaled up or restored.
Integrations must tolerate automatic write promotion and replay anything posted in the last seconds before a failover. Partners’ endpoints must follow the traffic manager (TO_4.10.09, Excluded).
Proving Live DR
| Test | What happens | Business impact | Frequency | Category | R&R |
|---|---|---|---|---|---|
| Continuous verification | Synthetic postings, replication-lag alerting, cross-region ledger checksum | None | Every minute | Standard | TO_4.10.01 |
| Planned switchover drill | Announce → pause writes (seconds) → promote DR → shift traffic → verify ledger → run from DR. Roles swap. | Writes paused for seconds | Quarterly | Standard | TO_4.10.03 |
| Additional switchover drill | As above, outside the quarterly plan | Writes paused for seconds | On request, 2 weeks ahead | Additional | TO_4.10.04 |
| Isolated (fenced) drill | A copy cloned from the DR replica with outbound integrations disabled; destructive tests allowed | None on production | On request, 2 weeks ahead | Additional | TO_4.10.05 |
| Clean-room restore test | Restore from the vault into an isolated environment, scan, reconcile | None on production | Yearly | Standard | TO_4.9.07 |
| Business validation of a drill | The customer confirms processes and integrations after the switchover | Customer effort | Each drill | Excluded | TO_4.10.06 |
After a drill there is no rebuild: the old primary becomes the Live DR. Reads never stop.
Run the first switchover drill and a clean-room restore before go-live. Both are go-live gates, and every later drill is evidence for auditors and the SLA review.
Backup policy (proposed default)
| Production database | Production documents | Non-prod database | Non-prod documents | |
|---|---|---|---|---|
| Frequency | Daily snapshot + continuous logs | Continuous versioning | Daily snapshot | Continuous versioning |
| Point-in-time recovery | Any point in the retention window | Version restore | Last snapshot | Version restore |
| Operational retention | 30 days | 30 days (versions) | 14 days | 14 days |
| Vault copy | Daily, immutable | Daily, immutable | Weekly, immutable | Optional |
| Vault retention | 90 days (extendable) | 90 days (extendable) | 30 days | 30 days |
| Encryption | At rest and in transit; vault keys held separately | At rest and in transit | At rest and in transit | At rest and in transit |
Kubernetes manifests and configuration live in infrastructure-as-code, also copied to the vault — so the runtime is rebuilt, not restored.
Restores
| Restore | Category | Lead time | R&R |
|---|---|---|---|
| On-demand backup before a major change | Standard, service request | Hours | TO_4.9.04 |
| Point-in-time restore | Standard, service request | Hours; P1 immediately | TO_4.9.05 |
| Clean-room restore from the vault | Additional, fee per delivery | Hours | TO_4.9.06 |
| Business sign-off of restored data | Excluded — the finance controller | — | TO_4.9.11 |
The air-gapped vault
- A separate cloud account or tenant, with separate identities, MFA and keys.
- No inbound network path from production. Production pushes one way through a write-only role with no read or delete rights.
- A write-once retention lock (WORM): copies cannot be altered or deleted, even by administrators.
- Deletion needs dual approval; integrity is scanned on arrival.
- Restores go into an isolated environment through the clean-room process — scan, reconcile, then promote — never directly over production.
- An optional offline copy to a second cloud or cold storage, periodically disconnected (TO_4.9.09, Optional).
Why it exists: replication and Live DR copy corruption instantly. Ransomware or bad data replicates too. The vault keeps a clean, unchangeable ledger history outside both regions.
Agree who holds the vault’s break-glass credentials. TRANXACT operates the dual-approval procedure (TO_4.9.12); the customer designates its approvers (TO_4.9.13, Excluded).
Long-term retention (Optional)
| Option | Frequency | Retention | Metric | Block | Category |
|---|---|---|---|---|---|
| Monthly archive copy | Monthly | 1 year | Gigabyte | 256 GB | Optional |
| Quarterly archive copy | Quarterly | 1 year | Gigabyte | 256 GB | Optional |
| Year-end archive copy | Yearly, after close | 2, 3 or 4 years | Gigabyte | 256 GB | Optional |
| Offline copy | Periodic | Per customer policy | Gigabyte | 256 GB | Optional |
| Legal hold on a copy | On request | Until released | Per request | — | Additional |
A retention lock cannot be shortened once set. If audit or legal-hold rules need longer retention, extend it up front — and size it from ledger growth and document volume, not from today’s database size.
Values marked proposed default are the deployment guide’s recommended starting points. Confirm each one per customer; the contract, order form, SLA and DPA prevail over this page.