Velero Documentation

Velero is a tool designed to back up and restore Kubernetes cluster resources and persistent volumes. It can be used with public cloud platforms or on-premises environments to:

• Take backups of your cluster and restore them in case of loss.
• Migrate cluster resources to other clusters.
• Replicate production clusters to development and testing clusters.

Velero architecture consists of two main components:

1. A server that runs on your Kubernetes cluster.
2. A command-line client that runs locally to interact with the server.

Certain Velero API types contain advanced functionality or configurations that cannot be fully managed via the velero CLI and must be configured using JSON or YAML definitions. When these specific types require fine-grained control (such as configuring hooks), you should define them as Kubernetes custom resources using their respective API schemas.

The primary API types requiring manual JSON/YAML configuration include:

• Backup: Defines the scope and configuration of a backup operation.
• Restore: Defines the parameters for restoring data.
• Schedule: Configures automated backup intervals.
• BackupStorageLocation: Defines where backups are stored (e.g., S3, Azure Blob).
• VolumeSnapshotLocation: Defines where volume snapshots are stored.

Certain Velero API types require configuration via JSON or YAML files because they contain functionality that cannot be fully expressed through the velero CLI. Specifically, these types include:

• Backup: Configuration for backup resources.
• BackupStorageLocation: Configuration for defining where backups are stored.
• VolumeSnapshotLocation: Configuration for defining where volume snapshots are stored.
• Hooks: Configuration for backup hooks.

Heptio Ark can be extended to support custom workflows and storage backends:

• Hooks: Allow you to execute specific commands within running pods during a backup. This is useful for tasks like flushing disk buffers or freezing a database before the backup starts.
• Plugins: Enable the development of custom object/block storage backends or per-item backup/restore actions. Plugins can execute arbitrary logic and modify items being backed up or restored without requiring a re-compilation of the core Ark binary.

Velero distinguishes between Backup Storage and Backup Repository to manage data lifecycle and efficiency:

• Backup Storage: The underlying physical or cloud storage (e.g., Object storage or File System) provided by the user. It is responsible for durability and scalability but may lack specialized backup features.
• Backup Repository: A layer between the Data Mover and the Backup Storage. It provides essential Backup & Restore (BR) features such as:
  • Deduplication and Compression: To reduce Total Cost of Ownership (TCO).
  • Security: Encryption at rest, immutability, and ransomware protection.
  • Efficient Retrieval: Optimizing for Recovery Time Objective (RTO) by allowing granular data restoration.
  • Unified Management: Providing a consistent interface for different types of Data Movers and various Backup Storages.

While most Velero operations can be performed via the velero CLI, certain advanced configurations for specific API types can only be managed by providing JSON or YAML definitions. These types include:

• Backup: Configuration for backup operations.
• Restore: Configuration for restore operations.
• Schedule: Configuration for automated backup schedules.
• BackupStorageLocation: Configuration for where backups are stored.
• VolumeSnapshotLocation: Configuration for where volume snapshots are stored.
• Hooks: Configuration for backup/restore hooks.

Velero uses the ItemBlock concept to group related resources that must be backed up together to guarantee backup integrity. Instead of backing up resources individually, Velero identifies these blocks to ensure interdependencies (like Pods, PVCs, and PVs) are captured as a single unit. This is a prerequisite for future features like VolumeGroupSnapshots and parallel backup processing.

Examples of ItemBlocks include:

• A Pod, its mounted PVCs, and the bound PVs for those PVCs.
• A VolumeGroup (related PVCs and PVs) along with any pods mounting these volumes.
• For a ReadWriteMany PVC: the PVC, its bound PV, and all pods mounting that PVC.

To back up persistent volume data, you must select a volume backup solution. You have two primary options:

1. Native Snapshot Plugins: If your storage platform provides a plugin (e.g., Portworx), install it to get native snapshots as part of your Velero backups.
2. File System Backup (FSB): If no native snapshot plugin is available, use Velero's File System Backup, which provides a platform-agnostic file-level backup solution for volume data.

The Unified Repository is designed to decouple data movement from data persistence. Key objectives include:

• Standardized Capabilities: Ensuring all Data Movers (e.g., file system, block, or application-specific movers) can easily access the same set of repository features.
• Pluggability: Allowing different backup repositories or backup storages to be swapped without impacting upper layers, and enabling the insertion of modules between the data mover and the repository to extend capabilities.
• Scalability: Enabling the backup repository to scale resources (CPU, memory, network) independently of the data movers.
• Kopia Integration: Using Kopia as the implementation for the Unified Repository and utilizing the Kopia uploader as a generic file system data mover for Pod Volume backups.