kubernetes

etcd Backup CronJob Generator

Generate a Kubernetes CronJob that automatically takes etcd snapshots and uploads them to S3. Includes the Secret, ServiceAccount, and complete CronJob YAML.

Generator

Inputs

etcd Endpoints

For HA clusters with 3 etcd members, use the local endpoint — the CronJob runs on a control plane node.

S3 Endpoint URL

Hetzner Object Storage endpoint or your S3-compatible storage URL.

S3 Bucket Name

S3 Region

Backup Schedule (cron)

Daily at 2am UTC. For 6-hourly: 0 */6 * * *

Retention (days)

days

Number of days of backups to retain in S3. Older backups are pruned automatically.

Namespace

Namespace to deploy the CronJob in. kube-system is conventional for cluster infrastructure jobs.

Output — etcd-backup-cronjob.yaml

# Generated by K8sCalc — etcd-backup-cronjob-generator
# Apply with: kubectl apply -f etcd-backup-cronjob.yaml
#
# Prerequisites on each control plane node:
#   - etcdctl binary available in the container or mounted
#   - etcd PKI certs mounted from the host
---
# S3 credentials secret — replace placeholder values
apiVersion: v1
kind: Secret
metadata:
  name: etcd-backup-s3-secret
  namespace: kube-system
type: Opaque
stringData:
  AWS_ACCESS_KEY_ID: "YOUR_ACCESS_KEY_ID"
  AWS_SECRET_ACCESS_KEY: "YOUR_SECRET_ACCESS_KEY"
---
# ServiceAccount for the backup job
apiVersion: v1
kind: ServiceAccount
metadata:
  name: etcd-backup
  namespace: kube-system
---
# CronJob — runs etcdctl snapshot save then uploads to S3
apiVersion: batch/v1
kind: CronJob
metadata:
  name: etcd-backup
  namespace: kube-system
spec:
  schedule: "0 2 * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: etcd-backup
          hostNetwork: true
          restartPolicy: OnFailure
          tolerations:
            - key: node-role.kubernetes.io/control-plane
              operator: Exists
              effect: NoSchedule
          nodeSelector:
            node-role.kubernetes.io/control-plane: ""
          containers:
            - name: etcd-backup
              image: bitnami/etcd:latest
              command:
                - /bin/sh
                - -c
                - |
                  set -e
                  BACKUP_FILE="/tmp/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db"

                  echo "Taking etcd snapshot..."
                  ETCDCTL_API=3 etcdctl snapshot save "$BACKUP_FILE" \
                    --endpoints=https://127.0.0.1:2379 \
                    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
                    --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
                    --key=/etc/kubernetes/pki/etcd/healthcheck-client.key

                  echo "Verifying snapshot..."
                  ETCDCTL_API=3 etcdctl snapshot status "$BACKUP_FILE" --write-out=table

                  echo "Uploading to S3..."
                  aws s3 cp "$BACKUP_FILE" \
                    s3://my-etcd-backups/$(basename $BACKUP_FILE) \
                    --endpoint-url https://s3.eu-central-1.amazonaws.com \
                    --region eu-central-1

                  echo "Pruning old backups (keeping 7 days)..."
                  aws s3 ls s3://my-etcd-backups/ \
                    --endpoint-url https://s3.eu-central-1.amazonaws.com \
                    --region eu-central-1 | \
                    sort | head -n -7 | \
                    awk '{print $4}' | \
                    xargs -I {} aws s3 rm s3://my-etcd-backups/{} \
                      --endpoint-url https://s3.eu-central-1.amazonaws.com \
                      --region eu-central-1 || true

                  rm -f "$BACKUP_FILE"
                  echo "Backup complete."
              env:
                - name: AWS_ACCESS_KEY_ID
                  valueFrom:
                    secretKeyRef:
                      name: etcd-backup-s3-secret
                      key: AWS_ACCESS_KEY_ID
                - name: AWS_SECRET_ACCESS_KEY
                  valueFrom:
                    secretKeyRef:
                      name: etcd-backup-s3-secret
                      key: AWS_SECRET_ACCESS_KEY
              volumeMounts:
                - name: etcd-pki
                  mountPath: /etc/kubernetes/pki/etcd
                  readOnly: true
          volumes:
            - name: etcd-pki
              hostPath:
                path: /etc/kubernetes/pki/etcd
                type: Directory

Automated etcd Backup Strategy

etcd is the only stateful component of a Kubernetes control plane. If you lose etcd data without a backup, you lose the entire cluster state — all Deployments, Services, Secrets, PVCs, and CRDs.

Why Automated Backups

Manual backups get skipped. Automated CronJobs run reliably even when your team is focused elsewhere. The generated CronJob:

›Runs on a schedule you control
›Uses etcdctl to take a verified snapshot
›Uploads to S3 with a date-stamped filename
›Prunes old backups to control storage costs
›Logs every step for auditability

Snapshot Verification

The CronJob runs etcdctl snapshot status after taking the snapshot. This verifies the snapshot is not corrupted before uploading. A corrupted backup is worse than no backup — it gives false confidence.

Recovery Time Objective

With daily backups, your worst-case data loss is 24 hours. For critical clusters, use 6-hourly backups (0 */6 * * *). The snapshot process takes ~10 seconds for most clusters and has negligible impact on etcd performance.

S3 Retention Formula

storage_cost = snapshot_size_gb × backups_per_day × retention_days × 0.0119

Example: 500 MB snapshot, 1/day, 7 days = 3.5 GB × €0.0119 = ~€0.04/month.

etcdctl Authentication

etcd in kubeadm clusters uses mTLS. The CronJob mounts the PKI directory from the host (/etc/kubernetes/pki/etcd) and uses the healthcheck-client certificate, which has read access to etcd without write permissions — following the principle of least privilege.

Frequently Asked Questions

Why does the CronJob run on control plane nodes?

etcd only runs on control plane nodes. The backup script uses the etcd PKI certificates at /etc/kubernetes/pki/etcd/ which only exist on control plane nodes. The generated CronJob uses a nodeSelector and toleration to ensure it schedules on a control plane node.

How do I verify the backup is working?

Check the CronJob: `kubectl -n kube-system get cronjobs`. Check recent job runs: `kubectl -n kube-system get jobs`. Check logs: `kubectl -n kube-system logs job/etcd-backup-<timestamp>`. Also verify the S3 bucket has new files after the scheduled time.

How do I restore etcd from an S3 backup?

1. Download the snapshot: `aws s3 cp s3://bucket/snapshot.db /tmp/etcd-restore.db`. 2. Stop the API server: remove /etc/kubernetes/manifests/kube-apiserver.yaml. 3. Restore: `etcdctl snapshot restore /tmp/etcd-restore.db --data-dir /var/lib/etcd-restored`. 4. Swap data dirs and restart etcd. 5. Restore the API server manifest.

Can I use this with Hetzner Object Storage?

Yes. Set the S3 endpoint to https://s3.eu-central-1.amazonaws.com and region to eu-central-1. Hetzner Object Storage is S3-compatible and the AWS CLI (used in the CronJob) works with it directly. Generate S3 credentials in the Hetzner Console under Object Storage → Access Keys.

Related Calculators

etcd Backup Size K8s Cluster Cost