You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently trying to set up a backup/disaster recovery scheme for my k3s nodes. I noticed that the path at /var/lib/rancher/k3s/agent/containerd is taking up the most space in the entire state, and it seems to be full of container images and root filesystems and not much else -- the kind of data that Kubernetes says is ephemeral.
Would it be safe to not backup that path, with the consequence that when recovering a backup, this directory would be empty? Do the nodes handle such a situation correctly?
My current plan is to backup the /var/lib/rancher/k3s/{agent,data,server}, excluding that large path, and also /etc/rancher. Is this the correct way to backup the cluster?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'm currently trying to set up a backup/disaster recovery scheme for my k3s nodes. I noticed that the path at
/var/lib/rancher/k3s/agent/containerdis taking up the most space in the entire state, and it seems to be full of container images and root filesystems and not much else -- the kind of data that Kubernetes says is ephemeral.Would it be safe to not backup that path, with the consequence that when recovering a backup, this directory would be empty? Do the nodes handle such a situation correctly?
My current plan is to backup the
/var/lib/rancher/k3s/{agent,data,server}, excluding that large path, and also/etc/rancher. Is this the correct way to backup the cluster?Beta Was this translation helpful? Give feedback.
All reactions