k8s-backup_skill

Overview

This skill provides Kubernetes backup and restore workflows using Velero. It automates detection, backup creation, restore operations, scheduled backups, and basic disaster recovery steps. The skill exposes commands to list and describe backups and restores, create selective backups and restores, and manage TTL and schedules. It is focused on practical, repeatable operations for cluster data protection and workload migration.

How this skill works

The skill wraps common Velero actions: detect Velero installation, list backup locations, create backups with namespace, label, resource include/exclude, and TTL options, and create restores with namespace mappings or resource filters. It also lists and inspects existing backups, restores, and schedules, and supports creating cron-based schedules via kubectl manifests. For disaster recovery it guides creating a DR backup, locating it, and restoring to the same or a different cluster while monitoring status transitions.

When to use it

• Before making major changes to cluster workloads or configuration.
• To implement routine scheduled backups for production namespaces.
• When preparing for cluster migration or workload relocation between clusters.
• During disaster recovery drills or actual failover events.
• To capture selective state (configmaps, secrets) without pods or PVCs.

Best practices

• Verify Velero is installed and backup storage is reachable before creating backups.
• Use descriptive, timestamped names for DR and retention-critical backups.
• Test restores regularly in a sandbox cluster to validate backup completeness.
• Exclude large or ephemeral resources (pods) from backups and separately manage persistent volumes.
• Apply TTLs to avoid indefinite storage retention and prune old backups automatically.

Example use cases

• Create a nightly scheduled backup of the production namespace with a 30-day TTL.
• Perform a label-selected backup for an application prior to a config change.
• Restore a backup to a new namespace for testing or to a different cluster for migration.
• Exclude persistentvolumeclaims from a config-only restore to avoid overwriting production data.
• Run a disaster recovery workflow: create DR backup, copy to target cluster, and restore there.