sickn33/agentic-awesome-skills/disaster-recovery
Claude Code and agent skill by sickn33/agentic-awesome-skills
- community
- ext:[{"type":"config","description":"Configuration overrides"}]
Checking that the SKILL.md file is still in the repository.
Implement disaster recovery strategies and runbooks. Configure RPO/RTO
Install
npx vskill@latest install sickn33/agentic-awesome-skills/disaster-recoverySemi-extensibleMentions customization, but needs skill-specific knowledge. Read the extensible skills standard
SKILL.md
Disaster Recovery
Implement disaster recovery strategies including RTO/RPO planning, AWS cross-region failover patterns, DR testing procedures, and automated failover scripts.
RTO/RPO Planning
DR Strategies Comparison
AWS Cross-Region DR Implementation
Fragments below provision or replace paid production configuration: confirm exact account, engine/version support, target region, KMS/IAM grants, backups and approved change window first. The listed tier timings/frequencies are planning examples, not platform guarantees or universal compliance rules. Aurora secondary-cluster creation also needs supported regional engine/version, subnet/security settings and instances; a cluster object alone is not a working DR application. S3 requires versioning on both buckets, replication-role/KMS permissions and explicit handling of existing objects; put-bucket-replication replaces existing rules, so merge a reviewed snapshot rather than overwriting it. Replication is not an immutable backup and can replicate corruption/deletion. Use a private unique temporary file instead of shared /tmp/replication-config.json when implementing.
AWS Cross-Region DR Implementation
Failover runbook and worked drill
The former executable script promoted a replica and declared success after a health URL without fencing the primary, updating app DB credentials or verifying routing/data. Do not automate that sequence unchanged. Use an owner-approved, service-specific runbook with explicit incident authority and rollback limits:
- Record disruption/declaration times, intended account/regions and last verified
recoverable transaction/replication lag. Obtain the loss acceptance decision.
- Fence the old writer and producers, including jobs/webhooks, and verify fencing;
a network partition can leave a healthy writer reachable from some clients.
- Promote the selected replica with service-specific prerequisites; record the
returned status and wait under bounded operator supervision. A promotion breaks the old replication relationship and may not be automatically reversible.
- Update DR app database endpoint/secret references, migration compatibility,
queues, session stores and allowlists. Scale approved capacity; verify readiness and a synthetic write/read transaction against the intended new writer.
- Change the approved traffic records only after readiness. Primary health checks
must identify the primary independently, not follow the failover service name. DNS resolution alone is not proof traffic reached DR; inspect region markers, TLS/SNI, caches, errors, replication consistency and external dependencies.
- Mark restoration only after end-to-end checks pass. Notifications require an
authorized recipient/channel and redact secrets. Report unknowns, not an unconditional “Operational” result. Keep the old writer fenced.
- Fail back only after explicit resynchronization/consistency and write-fencing
review; never bring both independent databases online as writers.
Worked tabletop: disruption 10:00 UTC, declared 10:04, DR write/read verified 10:18, latest recovered committed transaction 09:58. Measured recovery elapsed from disruption is 18 minutes and data-age gap is 2 minutes; the 14 minutes from declaration is a separate interval. These invented times illustrate measurement, not a successful drill or proof of the example tier targets.
Contents
When to Use
- Defining RTO and RPO targets for critical systems
- Designing multi-region or multi-cloud disaster recovery architectures
- Implementing automated failover and failback procedures
- Conducting DR tests (tabletop, component, full failover)
- Meeting compliance requirements for contingency planning (SOC 2, HIPAA, FedRAMP, ISO 27001)
Limitations
- Guidance and checklists only; not legal advice and not a substitute for a qualified auditor.
- Docs-only import: upstream templates and scripts not bundled.
Example
Adapted from BagelHole/DevOps-Security-Agent-Skills (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: helper scripts and templates not bundled.
Security
- Security scanPassed, 100 of 100Pattern checks on the skill's files.
- Model reviewNot runA model review is scheduled for the next rescan.
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingskills/disaster-recovery/SKILL.md
Popularity
- Repository stars
- 48,756
- Repository forks
- 7,077
- 7-day trend score
- 54
Stars and forks are for the whole GitHub repository, not this skill alone. Not refreshed yet.
Extension points
configConfiguration overrides
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/sickn33/agentic-awesome-skills/disaster-recovery)