Link Search Menu Expand Document

Rancher snapshots and backups

Rancher snapshots are application-level (etcd) snapshots that do not initiate vSphere or SolidFire snapshots. If you configure a Rancher cluster to take local snapshots (default), these will remain stuck in the etcd VMs, so to get to them you either need to be able to get to (one of?) the etcd VMs, or need to take and retain periodic snapshots with vSphere or from SolidFire (with scheduled volume snapshots that snapshot entire Datastore).

Read about them here.

Backup to S3

In addition to local snapshots, Rancher snapshots can be shipped off to S3-compatible storage such as NetApp StorageGRID or other.

Velero (using Restic for the first test) can backup apps and volume data to StorageGRID S3 storage (see here).

Rancher VMs

Considering that the provisioning can be fully automated, I am not convinced Rancher VMs need to be backed up.

It doesn’t hurt to set a rotating snapshot schedule for SolidFire datastore hosting VMs used for User Clusters, but recovering to an old snapshot may turn out to be useless (I haven’t looked into this yet - I suspect in many falure cases we would need to restore all Master nodes (VMs) at once).

If you keep your dynamic K8s data on SolidFire, backup, replicate and snapshot those volumes, but as far as VM that comprise User Clusters are concerned, they should have no unique data because we should be able to reinstate them at will and do it in minutes.

Container data

If containers use PVs on SolidFire, please refer to data protection of SolidFire data.

Several backup vendors support NetApp Trident CSI, so they may be able to protect volumes on a Trident-based back-end, as well as local (in-VM) PVs.

Kubernetes infrastructure data

Depending on how and where it’s stored, we may need to do something about one or more of the following (in no particular order):

  • Git
  • Security certificates (CA, ICA)
  • Active Directory, MFA/2FA
  • Logs
  • Private registry
  • Network proxy, DNS and switch configuration specific to Rancher

For a cluster, this data should be recoverable from cluster snapshots, but things can get complicated if Management Cluster or Workload Cluster can’t even come up, so we have no way to get to that data. That’s why its best to geographically spread your cluster across physically independent sites - either locally (PROD, DR) or hybrid (On-Premises, Public Cloud).