#Overview

Alauda Container Platform provides two types of backup and restore operations:

• Cluster backup and restore: Backs up and restores control plane data, including etcd, registry, logging, and monitoring data.
• Application backup and restore: Backs up and restores applications and their persistent volumes based on Velero.

#Cluster backup and restore

Cluster backup protects the control plane state and platform data.

#etcd backup and restore

etcd is the key-value store for Alauda Container Platform, which persists the state of all resource objects. An etcd backup plays a crucial role in disaster recovery.

For detailed instructions, see etcd Backup and Restore.

#Registry backup and restore

For registry backup and restore, see Alauda Container Platform Registry Data Backup and Recovery.

#Logging backup and restore

Currently supports ClickHouse. Contact technical support.

#Monitoring backup and restore

For monitoring backup and restore, see VictoriaMetrics Backup and Recovery.

#Application backup and restore

As a cluster administrator, you can back up and restore applications running on Alauda Container Platform by using Velero.

#Architecture

Application backup and restore consists of two components:

• Alauda Container Platform Data Backup Essentials: Provides the UI and is installed on the global cluster.
• Alauda Container Platform Data Backup for Velero: Provides Velero and is installed on workload clusters.

#Application installation

To enable application backup and restore:

1. Download Alauda Container Platform Data Backup Essentials and Alauda Container Platform Data Backup for Velero from the Customer Portal.
2. Upload the packages to the platform.
3. Install Data Backup Essentials on the global cluster.
4. Install Data Backup for Velero on workload clusters.

After installation, configure a backup repository to store backup data.

#Backing up and restoring applications

You back up applications by creating backup schedules and restore applications by executing recovery tasks.

For detailed instructions, see:

• Create application backups
• Restore applications

#Backup considerations

Before configuring backup policies, consider the following architectural factors that affect backup and recovery strategies.

#Immutable OS clusters

For clusters running on Immutable OS, VM Snapshot is not required or recommended as a backup strategy for disaster recovery scenarios.

Why VM Snapshot is not recommended:

• Immutable OS design: The operating system layer is read-only and managed centrally by the platform. When a node fails, the platform automatically creates a new node with the correct configuration.
• Distributed system nature: Kubernetes is a distributed system. VM Snapshot cannot capture the consistent state of distributed components like etcd quorum.
• Disaster recovery limitations: VM Snapshot is typically stored with original data and cannot handle site-level disasters.

Recommended backup approach:

• Cluster state: Use etcd backups to capture control plane state
• Application data: Use PV snapshots or Restic for persistent volumes
• Cluster configuration: Use GitOps/IaC for configuration management

#Usage scenarios

#Backup and restore within the current cluster

Restore applications to the current cluster after accidental deletion or failure. Application resources typically do not require modification during recovery.

#Cross-cluster application migration

Common scenarios include:

• Development and testing across data centers
• Resource migration between clusters
• Replication from production to development/testing clusters

Considerations:

• Ensure similar CPU and memory specifications between source and target clusters
• Maintain consistent network modes to avoid resource restoration issues
• If subnets differ, pod IPs will change after recovery
• Assess whether image migration is required before restoring data