A reliable K3s backup strategy should protect both the Kubernetes cluster state and the server configuration required to rebuild a failed control-plane node.
The good news is that a K3s control plane can usually be backed up while the cluster is still running. There is no need to stop Kubernetes just to create a backup, as long as the datastore is handled correctly.
Back Up the Kubernetes State with etcd Snapshots
If K3s uses embedded etcd, the safest approach is to create a supported snapshot instead of copying the live database directory.
A typical command is:
k3s etcd-snapshot save --name controlplane-backup
The etcd snapshot contains critical cluster information such as:
- Deployments
- Services
- ConfigMaps
- Secrets
- Namespaces
- Custom Resources
- Persistent Volume definitions
- Kubernetes cluster metadata
For disaster recovery, this is one of the most important parts of the entire backup process.
Copying the live etcd database files directly while K3s is running is not recommended because the resulting backup may not be consistent.
Save K3s Configuration and Credentials
The cluster state alone is not enough. A control-plane backup should also preserve the files required to recreate the K3s server.
Important locations can include:
/etc/rancher/
/etc/rancher/k3s/config.yaml
/etc/rancher/k3s/k3s.yaml
/var/lib/rancher/k3s/server/cred/
/var/lib/rancher/k3s/server/tls/
/var/lib/rancher/k3s/server/manifests/
/var/lib/rancher/k3s/server/token
/root/.kube
These directories may contain:
- K3s configuration
- certificates
- private keys
- cluster tokens
- Kubernetes manifests
- kubeconfig files
Because many of these files contain sensitive credentials, the backup destination should be protected accordingly.
Create a Separate Operating System Inventory
A good disaster recovery process should also record exactly what was installed on the server.
Useful information includes:
cat /etc/os-release
uname -a
rpm -qa | sort
systemctl list-unit-files --state=enabled
ip addr
ip route
lsblk
df -h
cat /etc/fstab
This data can be stored in a separate text file such as:
controlplane-os-packages.txt
Keeping this information outside the compressed archive makes it much easier to inspect when rebuilding the server.
It can help identify:
- Linux distribution and version
- kernel version
- installed packages
- enabled services
- disk layout
- mount points
- network configuration
- routing information
Include Important Operating System Configuration
Depending on the environment, it may also be useful to back up selected system directories such as:
/etc
/boot
/root/.ssh
/etc/ssh
/etc/pki
/etc/letsencrypt
/usr/local/bin
/usr/local/sbin
/var/spool/cron
These locations can contain important custom configuration, SSH keys, certificates, cron jobs, administration scripts, firewall rules, and other settings required to recreate the node.
Avoid Backing Up Container Runtime Data
One common mistake is including the entire Kubernetes or container runtime directory in the archive.
Directories such as:
/var/lib/rancher/k3s/agent/containerd/
/var/lib/kubelet/
/var/lib/cni/
may contain:
- container images
- overlay filesystem layers
- temporary runtime files
- Unix sockets
- caches
- container snapshots
These files are usually not required for control-plane recovery and can increase the backup size dramatically.
A backup that should be around 1 GB can easily become tens of gigabytes if container runtime data is included.
For this reason, the backup should focus on configuration, credentials, manifests, and the etcd snapshot rather than volatile runtime data.
Generate an Integrity Checksum
After creating the compressed archive, generate a SHA-256 checksum:
sha256sum controlplane-backup.tgz > controlplane-backup.tgz.sha256
This allows the archive to be validated later with:
sha256sum -c controlplane-backup.tgz.sha256
Checksums help detect incomplete transfers, corrupted files, or accidental changes.
Transfer the Backup to a Separate Server
The backup should not remain only on the Kubernetes node.
If the node suffers from:
- disk failure
- filesystem corruption
- accidental deletion
- hardware failure
- complete server loss
a local backup would be lost together with the server.
The archive should therefore be transferred to separate storage using a method such as:
- SFTP
- SCP
- rsync over SSH
- object storage
- backup software
- FTP or FTPS in controlled internal environments
The remote storage should ideally use a dedicated backup account with restricted permissions.
Delete Local Backups Only After a Successful Transfer
Cleanup order is critical.
A safe backup workflow is:
- Create the etcd snapshot.
- Collect configuration and system information.
- Build the compressed archive.
- Generate the checksum.
- Transfer all backup files.
- Confirm that the transfer succeeded.
- Delete the temporary local backup.
- Send a notification.
If the remote transfer fails, the local archive should remain available so the transfer can be retried.
Send Success and Failure Notifications
Automated backup jobs should report their status.
A useful notification can include:
- server hostname
- IP address
- backup date
- backup destination
- archive name
- success or failure status
- error details
This helps administrators detect failed backups before they are actually needed.
Automate the Process
Once the backup has been tested manually, it can be scheduled with cron.
For example, to run every Sunday at 01:00:
0 1 * * 0 /usr/local/bin/backup_controlplane.sh
Scheduling during lower-activity periods is a good idea because creating an etcd snapshot and compressing files can temporarily increase disk I/O and CPU usage.
Recommended K3s Control-Plane Backup Flow
A practical automated process should therefore:
- Detect the node hostname and IP address.
- Export operating system and package information.
- Create an on-demand etcd snapshot.
- Back up K3s configuration, certificates, tokens, and manifests.
- Include important system and SSH configuration.
- Exclude unnecessary container runtime data.
- Create a compressed archive.
- Generate a SHA-256 checksum.
- Transfer the files to remote backup storage.
- Delete the temporary local copy only after success.
- Send an email notification.
- Periodically test the restore procedure.
Conclusion
Backing up a K3s control plane does not normally require Kubernetes downtime. The key is to use an etcd snapshot for the cluster state and combine it with backups of K3s configuration, certificates, tokens, manifests, and operating system information.
At the same time, unnecessary container runtime directories should be excluded to keep the backup small and practical.
A good backup process should also transfer data off the node, verify integrity with checksums, clean up temporary files only after a successful transfer, and provide clear notifications.
Most importantly, backups should be tested periodically. A backup is only truly valuable when it can be restored successfully.
