velero-backup-restore-guard

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:

• [Workflow and output contract](references/workflow-and-output.md)
• [Safety checklist](references/safety-checklist.md)

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