Syself Autopilot clusters are declarative and reproducible, so you back up what Git cannot: your application data. Keep manifests in Git and back persistent data up to object storage, rather than taking full-system backups of nodes. The right strategy depends on the workload and your operational needs.

GitOps and declarative infrastructure#

If your workloads are managed through GitOps workflows, the Kubernetes resources already exist in version-controlled repositories.

In these environments, Kubernetes manifests can be recreated directly from Git repositories using tools such as ArgoCD or Flux. This significantly reduces the need to back up Kubernetes resource definitions themselves.

With GitOps-based workflows, disaster recovery often becomes a matter of:

1. Recreating the cluster
2. Reconnecting infrastructure components
3. Restoring persistent application data
4. Re-syncing workloads from Git

Back up your persistent data#

While Kubernetes resources are often reproducible, application data usually is not.

The most important backups in a Kubernetes environment are commonly:

• Databases
• User uploads
• AI and machine learning datasets
• Stateful application data

For production workloads, backups should ideally be stored outside the cluster itself using external object storage or dedicated backup systems.

Common approaches include:

• S3-compatible object storage
• Database-native backup tooling
• Volume snapshots
• Application-level backup automation

Kubernetes backup solutions#

Syself Autopilot fully supports Kubernetes-native backup solutions.

One of the most commonly used tools is Velero⁠, which can back up:

• Kubernetes resources
• Persistent volume snapshots
• Cluster metadata
• Namespaces and workloads

Velero integrates with multiple object storage providers and is commonly used for disaster recovery and migration scenarios.

Other Kubernetes backup solutions can also be used depending on workload requirements and operational preferences.

What should you back up?#

As a general guideline: