Backup and Disaster Recovery

Pathrule3 Rules • 1 Memory • 2 Skills

Backup and disaster recovery are proven by restoring a usable service within agreed data-loss and downtime objectives, not by a dashboard showing successful copy jobs. This bundle defines RPO and RTO, immutable isolation, encryption and access, dependency-complete recovery, validation, failover, and game-day procedures. Unlike Postgres Schema, it owns recoverability across the whole workload rather than database structure.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

test-backup-restore

infra/

backups/

Set backup policy from workload RPO and retention

Isolate backup authority from production compromise

runbooks/

A recovery is complete only after service validation

RPO and RTO describe business loss, not product features

run-disaster-recovery-game-day

Rules

Set backup policy from workload RPO and retention/infra/backupshighstrictBackup frequency, retention, immutability, replication, and validation derive from business-approved data-loss and evidence needs.

1	Backup frequency, retention, immutability, replication, and validation derive from business-approved data-loss and evidence needs. A daily schedule chosen by convention can violate the workload's recovery point objective or retain sensitive data longer than policy allows. Enforce this boundary in /infra/backups so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Inventory authoritative stores, object data, queues where replay is impossible, configuration, keys, and control-plane state required for recovery.
4	- Set recovery point objective, retention tiers, legal holds, deletion behavior, and regional isolation per data class.
5	- Monitor successful capture, age of the latest restorable point, replication lag, retention enforcement, and validation outcomes.
6	- Keep replication distinct from backup because corruption or deletion can replicate immediately.
7
8	Verification: Measure the actual newest recoverable point for each data class after delayed jobs, corruption, deletion, and regional isolation scenarios; compare it with the approved RPO.

Isolate backup authority from production compromise/infra/backupshighstrictBackup copies, deletion controls, encryption keys, and restore roles use separate trust boundaries and tightly audited access.

1	Backup copies, deletion controls, encryption keys, and restore roles use separate trust boundaries and tightly audited access. An administrator, ransomware event, or compromised production role can erase recovery if it controls both the primary system and every backup copy. Enforce this boundary in /infra/backups so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Use separate accounts, projects, vaults, or equivalent boundaries for protected copies and restrict production roles to creating backups without deleting them.
4	- Enable immutable or locked retention where supported and protect policy changes with independent approval.
5	- Separate backup encryption and recovery key access from routine workload credentials while preserving an emergency access path.
6	- Alert on deletion attempts, retention changes, disabled jobs, unusual restores, and changes to recovery identities.
7
8	Verification: Compromise a test production administrator and attempt to list, decrypt, shorten retention, overwrite, and delete protected copies; confirm independent controls and alerts hold.

A recovery is complete only after service validation/runbookshighstrictRestore procedures rebuild dependencies, apply deletion state, verify integrity, and prove user-facing behavior before traffic returns.

1	Restore procedures rebuild dependencies, apply deletion state, verify integrity, and prove user-facing behavior before traffic returns. A database that starts is not a recovered product when objects, keys, identity, DNS, configuration, queues, or downstream reconciliation are missing. Enforce this boundary in /runbooks so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Define dependency order and the source of truth for infrastructure, configuration, secrets, certificates, data, indexes, caches, queues, and integrations.
4	- Restore into an isolated environment, apply migrations and deletion tombstones, then run integrity and application-level acceptance checks.
5	- Reconcile asynchronous work and external systems before enabling writes or sending delayed notifications.
6	- Measure from declared disaster to validated service and record data loss against RTO and RPO, including manual waits.
7
8	Verification: Run the documented procedure with primary systems unavailable and no unstated operator access; verify representative reads, writes, identities, objects, jobs, and external effects.

Memories

RPO and RTO describe business loss, not product features/runbooksStorage durability, snapshot frequency, and failover mode are implementation choices, while acceptable data loss and downtime come from product and operational impact.

1	Storage durability, snapshot frequency, and failover mode are implementation choices, while acceptable data loss and downtime come from product and operational impact. Record objectives per workload and critical journey, including the point from which time starts and the evidence that ends recovery.
2
3	Include detection, decision, access, infrastructure provisioning, data transfer, validation, DNS or traffic change, and backlog processing in RTO measurement. Resolve conflicts between cost and objective explicitly with the business owner. Review objectives when data volume, dependency graph, regions, or customer commitments change. Keep the decision explicit at /runbooks; moving it into an incidental caller makes behavior depend on which route happened to execute first.
4
5	See /infra/backups for protection policy and the disaster recovery drill for measured evidence. That related boundary consumes this decision and carries the evidence that proves it still holds.

Skills

test-backup-restore/rootRestore a representative backup into isolation and verify data integrity, security, application behavior, and recovery timing.

1	---
2	name: test-backup-restore
3	description: Restore a representative backup into isolation and verify data integrity, security, application behavior, and recovery timing.
4	---
5
6	# Test Backup Restore
7
8	Run this procedure whenever the governed surface changes or its operational evidence becomes stale.
9
10	1. Select a recovery point without advance notice, record its age, and provision an isolated target using the documented recovery identities and infrastructure path.
11	2. Restore every registered data class, configuration, key, object, and index dependency, then apply migrations, retention state, and deletion tombstones.
12	3. Run integrity checks plus representative authenticated reads, writes, searches, jobs, exports, and cross-store reconciliation without contacting production users.
13	4. Measure achieved data loss and elapsed recovery, destroy the isolated environment safely, and create owned fixes for every manual step or failed objective.
14
15	Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory.

run-disaster-recovery-game-day/runbooksRun a controlled disaster scenario through declaration, failover or restore, validation, communication, and return to normal.

1	---
2	name: run-disaster-recovery-game-day
3	description: Run a controlled disaster scenario through declaration, failover or restore, validation, communication, and return to normal.
4	---
5
6	# Run Disaster Recovery Game Day
7
8	Run this procedure whenever the governed surface changes or its operational evidence becomes stale.
9
10	1. Choose a credible failure, safety boundaries, observers, abort conditions, target RPO and RTO, and systems that must remain untouched.
11	2. Declare the event without handing responders hidden implementation answers, then follow the real command, access, communication, and recovery runbooks.
12	3. Measure detection, decision, provisioning, data recovery, validation, traffic shift, backlog, and customer communication while recording workarounds and unsafe assumptions.
13	4. Return to normal safely, reconcile data and external effects, publish a blameless exercise report, and track measurable fixes through the next drill.
14
15	Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory.

Why this pattern

Agents configure backup schedules but never prove that data, keys, configuration, dependencies, and operator access can restore a functioning service on time.

Built for Teams responsible for production data durability, continuity, and disaster recovery.

Keeps your assistant from:

Successful backup jobs that produce unusable restores
Attackers or operators deleting primary data and its backups together
Recovery plans missing keys, identities, configuration, or external dependencies

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25