| name | velero-backup-restore-guard |
| description | Use this skill when guarding Velero backup schedule changes, restore operations, BackupStorageLocation mutations, or volume snapshot configuration. Trigger on any request to run a velero restore, delete a Schedule, change a BSL default, or modify backup retention. |
| allowed-tools | Read Grep Glob WebFetch |
| metadata | {"author":"github: Raishin","version":"0.1.0","updated":"2026-05-05","category":"resilience"} |
Velero Backup/Restore Guard
Purpose
Guard live Velero operations — restore execution, schedule deletion, BackupStorageLocation changes, and volume snapshot configuration — against data loss, scope creep, and missing rollback posture. A Velero restore is destructive: it overlays resources onto the cluster. Every guarded operation requires confirmed cluster context, explicit scope, current state capture, and explicit platform-team sign-off before any mutation executes.
Lean operating rules
- Confirm cluster context (
kubectl config current-context) and target namespace before any Velero operation — ambiguous context is a hard stop.
- Capture current state of the target Backup, Schedule, or BSL (
velero backup describe <name> --details, kubectl get schedule <name> -o yaml) before every write — Velero has no built-in undo.
- For restore operations: require
includedNamespaces to be explicitly scoped; a cluster-wide restore (includedNamespaces: []) requires explicit platform-team sign-off.
- Require pre-restore validation (
velero backup describe <name> --details and a trial restore on a non-production cluster) before every non-emergency production restore; treat skipping validation as a hard stop. Velero has no --dry-run flag on velero restore create — do not recommend one.
- Block deleting a Schedule that is the only backup for a production namespace unless an alternative backup source is confirmed.
- Block changing a BSL
default: true without confirming no in-progress backups and reviewing the impact on all dependent Schedules.
- Check pre-backup hook coverage on stateful workloads (PostgreSQL, MySQL, Kafka) — missing quiesce hooks mean inconsistent backups.
- Label all claims as live evidence, documentation-based, or inference.
References
Load these only when needed:
Response minimum
- Confirmed cluster context and target scope
- Current state of the Backup/Schedule/BSL (evidence level)
- Hard-stop assessment (is this a blocked operation?)
- Explicit platform-team sign-off status
- Recommended validation step or safe-path command
- Rollback posture
- Post-operation verification steps
