name: restore-drill
description: Use for recurring backup-restore validation and disaster-recovery simulation, including restore runbooks, drill frequency, pass/fail gates, evidence capture, and remediation tracking.
Restore Drill
Quick Index (Action-Routed)
Read First (All Actions)
MissionScopeTrigger ExamplesRequired PreconditionsDrill TypesFrequency Policy
Action Modules (Read As Needed)
- Planning drills:
Drill Environment PolicyRecovery Objectives (RPO/RTO) EnforcementMandatory Drill Workflow Step 1-2
- Executing and validating drills:
Mandatory Drill Workflow Step 3-8Pass/Fail Gate ModelEvidence Requirements
- Operational hardening:
Restore Runbook Quality StandardCommon Failure Scenarios to SimulateMetrics and Trend TrackingChecklists
Escalation & Output
Escalation RulesDeliverable Format
Mission
Prove backups are restorable under realistic failure conditions and within defined recovery objectives.
Scope
This skill governs planning, execution, evidence capture, remediation, and recurring validation.
Trigger Examples
Use for restore validation, DR simulation, and release-gate recovery checks.
Relationship to Other Skills
- Use Project Backup to establish backup creation, retention, and storage policy.
- Use this skill to validate that those backups restore successfully.
- Use Regression Prevention when drills are part of pre-release or pre-change risk gating.
Required Preconditions
Do not start a drill until these exist:
- current backup artifact(s) identified
- restore target environment available
- restore runbook draft exists
- owner/on-call roles identified
- recovery objectives (RPO/RTO) defined
If any precondition is missing, mark drill status as blocked and fix prerequisites first.
Drill Types
Run multiple drill types; a single happy-path drill is insufficient.
tabletop (planning simulation):
- no system restore performed
- validates people/process/sequence
technical_partial:
- restore one subsystem (e.g., DB only or media only)
- validates component-level recoverability
technical_full:
- restore full stack (code + DB + media + config)
- validates end-to-end recovery path
chaos_variant:
- inject one controlled failure during restore (missing file, bad credential, partial archive)
- validates operator response and runbook quality
Frequency Policy
Minimum cadence:
- tabletop: monthly
- technical_partial: monthly
- technical_full: quarterly
- pre-major-release or pre-high-risk migration: ad hoc mandatory full drill or last-full-drill freshness check
Freshness rule:
- if no successful full drill within the last 90 days, risky production changes are blocked.
Date tracking requirement:
- record
last_successful_full_drill_at - evaluate freshness before every high-risk release gate
Drill Environment Policy
Prefer isolated environments that mirror production characteristics.
Requirements:
- environment parity documented (version/runtime/schema deltas)
- destructive operations isolated from production
- enough representative data volume to test performance realism
- access/permissions available for restore operators
Recovery Objectives (RPO/RTO) Enforcement
Each drill must evaluate:
- achieved RPO: recovered data currency vs target
- achieved RTO: elapsed time to service readiness vs target
Pass criteria:
- achieved RPO <= target RPO
- achieved RTO <= target RTO
If either fails, drill is failed even if app eventually starts.
Mandatory Drill Workflow
Follow in order.
Step 1: Drill Charter
Document:
- drill type
- scope/assets included
- target RPO/RTO
- participants and roles
- planned start/end
- success/failure criteria
Step 2: Artifact Verification
Before restore starts:
- confirm backup artifact timestamp and source
- verify integrity checksums/signatures
- verify encryption/decryption path (if encrypted)
- verify artifact completeness (expected files present)
If integrity fails, stop and escalate.
Step 3: Restore Execution
Execute restore runbook step-by-step:
- code/config restore
- database restore
- media/object restore
- service startup
- dependency/service connectivity checks
Capture timestamps for each phase.
Step 4: Functional Validation
After restore, run mandatory checks:
- app boots without critical errors
- auth/login path works
- at least one critical business flow succeeds
- key API health and core endpoints respond correctly
- representative media/assets are accessible
Step 5: Data Validation
Verify restored data quality:
- key table/entity counts in expected range
- referential integrity/basic constraint sanity
- recent critical records exist (within RPO tolerance)
- no obvious corruption/truncation signals
Step 6: Security Validation
Confirm:
- secrets/credentials are not leaked in logs/artifacts
- restored permissions are least-privilege compliant
- encryption expectations remain intact after restore
Step 7: Timing Evaluation
Compute:
- actual RTO (start restore -> service ready)
- actual RPO (backup point -> incident point simulated)
Compare against targets and mark pass/fail.
For any issue found:
- classify severity
- assign owner
- set due date
- track remediation status
No unresolved critical findings should remain open for next high-risk release.
Pass/Fail Gate Model
Drill passes only if all are true:
- restore completed without unrecoverable errors
- integrity checks passed
- functional/data/security validations passed
- RPO target met
- RTO target met
Drill is conditional pass if:
- core restore succeeded but non-critical checks failed
- remediation ticket created with committed due date
Drill fails if:
- restore cannot complete
- integrity fails
- critical flow fails
- RPO/RTO miss on critical systems
Release-gate implication:
- failed or stale full drill blocks high-risk release until remediation and re-validation
Evidence Requirements
Every drill must produce evidence bundle:
- drill charter
- artifact identity (name/hash/timestamp)
- step-by-step execution log with timestamps
- validation results
- RPO/RTO calculations
- issues + remediation tracker links/IDs
- final pass/fail decision
If evidence is missing, drill is considered invalid.
Restore Runbook Quality Standard
Runbook must be:
- deterministic and ordered
- executable by an operator other than original author
- explicit about prerequisites
- explicit about rollback/retry paths
- explicit about validation checkpoints
Runbook anti-patterns:
- "Restore DB somehow."
- hidden tribal knowledge steps
- missing environment variable requirements
- missing failure branching
Role Model
Minimum roles per drill:
- drill lead (coordinates)
- operator (executes restore)
- observer/scribe (captures evidence)
- approver (signs pass/fail)
For small teams, one person may hold multiple roles, but approver should be distinct where possible.
Common Failure Scenarios to Simulate
Cycle through these over time:
- latest backup artifact corrupted
- backup decrypt key unavailable
- DB version mismatch on restore target
- missing object/media segment
- network dependency temporarily unavailable
- expired credential during restore
Metrics and Trend Tracking
Track over time:
- drill pass rate
- median/95th percentile restore time
- RPO misses count
- mean remediation closure time
- repeated failure categories
Use trend data to improve runbook and backup architecture.
Escalation Rules
Escalate immediately if:
- two consecutive full drills fail
- critical system misses RTO by >25%
- critical data misses RPO target
- restore depends on undocumented manual steps
High-risk releases must pause until corrective actions are implemented.
Checklists
Pre-Drill Checklist
- [ ] scope and objectives documented
- [ ] backup artifact selected and verified
- [ ] environment prepared
- [ ] roles assigned
- [ ] runbook accessible
- [ ] pass/fail criteria agreed
Execution Checklist
- [ ] integrity checks passed
- [ ] restore phases completed
- [ ] service startup validated
- [ ] functional checks validated
- [ ] data checks validated
- [ ] security checks validated
- [ ] RPO/RTO calculated
Post-Drill Checklist
- [ ] evidence bundle archived
- [ ] pass/fail decision recorded
- [ ] remediation items created
- [ ] owners and deadlines assigned
- [ ] next drill date scheduled
When applying this skill, produce:
- drill charter
- execution transcript summary
- validation and timing results
- pass/fail verdict
- remediation plan
- next scheduled drill date
- release-gate status (
pass, conditional, block)