Introduction

If you want a lightweight backup of Kubernetes configuration objects such as namespaces, deployments, services, and config maps, the simplest approach is to export their YAML definitions with kubectl. This is useful for configuration recovery and auditing, but it is not the same as full disaster recovery because it does not automatically include persistent volume data, secrets policy decisions, or cluster-wide control-plane state.

A Basic Backup Script

The following shell script exports common namespaced resources into a timestamped directory:

1#!/usr/bin/env bash
2set -euo pipefail
3
4STAMP="$(date +%Y%m%d-%H%M%S)"
5OUT_DIR="k8s-backup-${STAMP}"
6mkdir -p "${OUT_DIR}"
7
8for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
9  mkdir -p "${OUT_DIR}/${ns}"
10
11  kubectl get deploy -n "${ns}" -o yaml > "${OUT_DIR}/${ns}/deployments.yaml" || true
12  kubectl get svc -n "${ns}" -o yaml > "${OUT_DIR}/${ns}/services.yaml" || true
13  kubectl get configmap -n "${ns}" -o yaml > "${OUT_DIR}/${ns}/configmaps.yaml" || true
14  kubectl get ingress -n "${ns}" -o yaml > "${OUT_DIR}/${ns}/ingresses.yaml" || true
15  kubectl get secret -n "${ns}" -o yaml > "${OUT_DIR}/${ns}/secrets.yaml" || true
16done
17
18kubectl get ns -o yaml > "${OUT_DIR}/namespaces.yaml"

This creates one folder per namespace and stores the exported manifests there.

Why This Is Useful

This type of backup helps with:

• recreating workloads after accidental deletion
• reviewing cluster configuration over time
• migrating definitions to another cluster
• keeping an external snapshot of declarative objects

If your workloads are already fully defined in GitOps manifests or Helm charts, this export may be less important as a source of truth, but it is still useful as a cluster-state snapshot.

Clean Up the YAML Before Restore

Raw kubectl get -o yaml output includes fields that should not usually be applied back directly, such as:

• 'status'
• resource versions
• UIDs
• managed fields

For a restore-friendly export, strip those fields before reuse. A common pattern is to process the YAML with yq, but even without that, treat the backup as a reference snapshot first and a direct restore input second.

Namespace-Specific Backup

If you only care about one namespace, keep the script narrower:

1#!/usr/bin/env bash
2set -euo pipefail
3
4NS="production"
5mkdir -p backup/${NS}
6
7kubectl get all -n "${NS}" -o yaml > backup/${NS}/all.yaml
8kubectl get configmap -n "${NS}" -o yaml > backup/${NS}/configmaps.yaml
9kubectl get secret -n "${NS}" -o yaml > backup/${NS}/secrets.yaml

This is often enough for application-level backup workflows.

Know the Limits

Manifest export is not a complete Kubernetes backup strategy by itself. It does not automatically preserve:

• persistent volume contents
• external cloud resources created by controllers
• RBAC expectations outside the exported objects
• cluster add-on state or CRD definitions unless you include them explicitly

For fuller backup and restore workflows, tools such as Velero are often a better fit than ad hoc shell scripts.

Common Pitfalls

The most common mistake is assuming exported YAML is sufficient to restore everything exactly as it was. Persistent data and cloud-integrated resources usually need separate backup logic.

Another issue is restoring raw manifests without removing generated metadata such as resourceVersion or status. Those fields often make restore attempts fail or behave unpredictably.

A third pitfall is exporting only Deployment objects and forgetting the related services, config maps, ingress resources, secrets, and namespace definitions that the workloads depend on.

Finally, back up secrets carefully. Including them in plain YAML may be necessary operationally, but it also changes the security profile of your backup storage immediately.

Summary

• 'kubectl get -o yaml scripts are a simple way to back up Kubernetes object definitions.'
• Export common namespaced resources into a timestamped directory structure.
• Treat raw YAML exports as configuration snapshots, not perfect one-step restores.
• Remember that persistent volume data and some external resources need separate backup handling.
• Use dedicated backup tools when you need full cluster recovery rather than lightweight manifest export.