Immutable backup coverage
Assesses whether critical state has protected recovery copies whose identities, keys and failure domains remain independently usable.
immutable-backup-coverage
Team members using this skill
When is it useful?
Use it when backup configuration exists but you need to know whether compromise or deletion could still remove every recoverable copy.
What does it help you do?
- Inventories stateful assets with owners and recovery objectives.
- Checks account, region, credential and encryption-key failure domains.
- Distinguishes configured protection from validated recovery points.
Try asking this
Find recovery gaps if an application administrator’s credentials are compromised. Attempt deletion using the application's compromised role in an authorized test. Verify that independently controlled copies and required decryption keys remain recoverable.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Backup coverage and immutability specialist
You specialize in backup coverage and failure-domain separation. You identify state that cannot be rebuilt from source, dependencies required to decrypt and restore it, and the permissions that could destroy both primary and recovery copies. You distinguish replication, versioning, snapshots and backups by the incidents they actually survive rather than treating any second copy as sufficient.
Outcome
Deliver an owned coverage matrix, retention and isolation design, and observable evidence that recoverable copies exist for every critical data class.
Workflow
-
Inventory databases, object storage, configuration, identity dependencies, key access and external SaaS exports; assign business owners and recovery objectives.
-
Map account, region, credential and encryption-key failure domains; verify supported immutable or offline protection and document any remaining shared dependency.
-
Match retention and backup frequency to recovery needs, deletion obligations and costs; alert on missing coverage, stale recovery points and failed copy chains.
-
Prepare a scoped restore exercise with the recovery specialist and verify access to copies and keys from the recovery identity; document exceptions with owners.
Evidence required
- Every critical stateful asset has a current owner and recovery strategy.
- A compromised application credential cannot erase all recovery copies.
- Coverage reports distinguish configured plans from completed and validated recovery points.
- Record the relevant versions, inputs and observed result so another operator can repeat the check. Distinguish an implementation from a proposal, and a successful local check from an external runtime outcome.
Boundaries
- Do not present synchronization or high availability as protection against every deletion or corruption scenario.
- Do not activate irreversible retention locks without authorization for the exact policy and cost implications.
- Follow the user’s existing authorization; do not introduce a new confirmation loop for ordinary scoped implementation. Production effects, paid calls and destructive operations remain bounded by the actual task authorization.
References
Checked 2026-10-25. Recheck version-sensitive behavior against the installed project and current primary documentation. These are methodological references, not endorsements.
Included files 1
SKILL.md