Kubernetes Backup and Restore with Velero Explained

When administrators start working with Kubernetes, their attention usually focuses on Deployments, Services, Pods, and automated scaling. After all, Kubernetes provides powerful mechanisms for managing containerized workloads and replacing failed application instances. However, an important question often receives less attention: What happens when essential Kubernetes resources or application data are accidentally deleted, corrupted, or permanently lost?

This is where Kubernetes backup and restore becomes an essential part of cluster operations. Although Kubernetes can recreate failed Pods and maintain a desired application state, it does not automatically provide a complete backup solution for every workload and its persistent data.

For example, a Deployment controller can replace a failed Pod. However, if the Persistent Volume containing important database files becomes unavailable or corrupted, simply starting another Pod will not recover the missing information.

Likewise, if an administrator accidentally deletes a Namespace containing important application resources, Kubernetes cannot automatically reconstruct the previous configuration unless another system preserves that information.

Therefore, a reliable Kubernetes environment needs more than automated orchestration. It also requires a backup and disaster recovery strategy that considers both Kubernetes resources and the actual data used by applications.

One interesting solution is Velero, an open-source tool designed to back up, restore, and migrate Kubernetes resources and supported persistent data.

In this article, we will examine how Kubernetes backup and restore works with Velero, explore different storage backup methods, and walk through practical examples. Furthermore, we will discuss automated backup schedules, disaster recovery scenarios, and the important differences between Velero and etcd snapshots.

Why Does Kubernetes Need a Backup Solution?

At first glance, Kubernetes appears to provide many features that are closely related to recovery. Controllers continuously monitor the cluster and attempt to reconcile the actual state with the desired configuration.

For example, if a Pod disappears, the appropriate controller can normally create another instance. Similarly, when a worker node fails, Kubernetes may schedule replacement Pods on other available nodes, provided sufficient resources and storage access are available.

However, these mechanisms are primarily designed to maintain application availability. They are not equivalent to traditional backups.

Imagine an application running inside a Kubernetes Namespace called production-app. The Namespace contains Deployments, Services, ConfigMaps, Secrets, and PersistentVolumeClaims.

If someone accidentally deletes that Namespace, many associated resources may be removed. Consequently, the desired configuration stored in Kubernetes no longer contains those objects.

In this situation, Kubernetes does not know that the previous state should be restored.

The same principle applies to application data. A PersistentVolumeClaim provides access to storage, but it does not automatically protect the stored information against accidental deletion, corruption, or failures of the underlying storage system.

Therefore, we need to distinguish between two important concepts.

High availability helps applications continue operating despite certain infrastructure failures. Backup and restore, on the other hand, allows administrators to recover previous configurations or data after an incident.

Both are important, but they solve different problems.

What Is Velero?

Velero is an open-source backup, restore, and migration tool for Kubernetes environments.

Originally known as Heptio Ark, the project provides mechanisms for protecting Kubernetes resources and, depending on the configuration, persistent application data.

One of its main advantages is that Velero works with the Kubernetes API.

As a result, it can capture resource definitions such as Deployments, StatefulSets, Services, ConfigMaps, Secrets, and many other Kubernetes objects.

Furthermore, Velero supports several methods for protecting Persistent Volumes. These include CSI Volume Snapshots, CSI Snapshot Data Movement, and File System Backup.

Backup metadata and supported volume backup data can be stored in object storage systems, including Amazon S3 and appropriately configured S3-compatible solutions.

This is particularly useful because backups can be stored separately from the Kubernetes cluster itself.

However, Velero should not be misunderstood as a universal solution that automatically creates application-consistent backups of every workload.

For example, database systems such as PostgreSQL and MySQL have additional consistency requirements that must be considered when selecting a backup strategy.

Understanding the Velero Architecture

Before installing Velero, it helps to understand how its components work together.

Velero consists of a command-line interface and server-side components running inside Kubernetes.

The Velero CLI allows administrators to create backups, inspect backup status, configure schedules, and initiate restores.

Meanwhile, the Velero server runs inside the cluster and processes the corresponding Kubernetes custom resources.

For example, when you execute a backup command, Velero creates a Backup resource. The server-side controllers then process that resource and coordinate the backup operation.

Additionally, Velero uses BackupStorageLocations to define where backup metadata and related data should be stored.

Depending on the storage provider, Velero may require a compatible plugin.

For volume backup operations, additional components such as CSI drivers and the Velero Node Agent may also be involved.

The Node Agent supports file-system-based backup operations and certain snapshot data movement workflows.

Consequently, the complete architecture separates Kubernetes resource protection from the mechanisms used to protect persistent data.

This distinction becomes especially important when choosing a recovery strategy.

What Can Velero Back Up?

When planning Kubernetes backup and restore, I recommend distinguishing between Kubernetes resources and application data.

The first category includes Kubernetes API resources. These describe how applications should run and how they are connected.

Examples include:

Deployments and StatefulSets
Services and selected networking resources
ConfigMaps and Secrets
Namespaces and ServiceAccounts
PersistentVolumeClaims
Custom resources supported by the backup configuration

These objects are essential for reconstructing the application structure.

However, backing up a PersistentVolumeClaim resource does not automatically mean the actual files stored on its associated volume have been copied into a durable backup repository.

That brings us to the second category: persistent application data.

Examples include uploaded documents, application-generated files, database storage directories, and other information written to Persistent Volumes.

For these workloads, Velero needs an appropriate volume backup method.

Therefore, always verify which resources and which volume data are actually included in a backup.

Method 1: Backing Up Persistent Volumes with CSI Snapshots

Modern Kubernetes storage systems commonly use the Container Storage Interface, or CSI.

CSI provides a standardized way for storage vendors and software projects to integrate storage functionality into Kubernetes.

Some CSI drivers support creating Volume Snapshots.

When the required CSI snapshot functionality is available, Velero can use it to capture a snapshot of a Persistent Volume.

One advantage is that the snapshot operation is handled by the storage infrastructure rather than reading every application file individually.

This can be particularly efficient for large volumes, depending on the capabilities of the storage platform.

However, there is an important limitation.

A CSI snapshot may remain stored within the same underlying storage system as the original volume.

Consequently, the snapshot might not protect against the complete failure or loss of that storage environment.

For example, if both the production volume and its snapshots reside on the same storage system, a catastrophic failure could affect both.

Therefore, storage snapshots should not automatically be treated as independent disaster recovery backups.

Additionally, the CSI driver must support the necessary snapshot functions, and the Kubernetes cluster must have the relevant snapshot components configured.

Method 2: CSI Snapshot Data Movement

CSI Snapshot Data Movement extends the snapshot approach by transferring snapshot data into a backup repository.

Instead of stopping after the storage system creates a snapshot, Velero coordinates the transfer of the captured data to a configured backup storage location.

This is especially interesting for on-premises Kubernetes environments where snapshots alone may not provide sufficient protection against storage failures.

For example, a storage system may be capable of creating snapshots but may not offer a convenient way to retain those snapshots independently.

In such cases, transferring the snapshot data into object storage can provide an additional recovery option.

Furthermore, newer Velero implementations support different data mover approaches, depending on the Velero release and available storage capabilities.

However, CSI Snapshot Data Movement requires a compatible configuration and may depend on the features exposed by the CSI driver.

Therefore, before enabling this method, verify that the chosen Velero version, CSI driver, and data mover are compatible.

It is also important to understand the performance impact of transferring potentially large volumes to an external repository.

After all, backup operations consume network bandwidth, CPU, memory, and storage capacity.

Method 3: File System Backup with Velero

Not every Kubernetes storage system supports CSI snapshots.

For example, some local storage solutions or particular volume configurations may not provide a usable snapshot interface.

For these situations, Velero offers File System Backup, commonly abbreviated as FSB.

Instead of relying on a native storage snapshot, this method reads files from supported Pod volumes and transfers them to a backup repository.

The Velero Node Agent participates in the backup process, while supported repository functions handle storage and data transfer.

One advantage is flexibility. File System Backup can protect certain volumes even when native snapshot support is unavailable.

However, there are limitations.

For example, File System Backup does not support every possible volume type, and files may be modified by the application while the backup is running.

Consequently, the resulting backup does not automatically represent an application-consistent point in time.

This is particularly important for databases.

Copying PostgreSQL or MySQL database files while the database continues writing data is not automatically equivalent to a valid database backup.

Therefore, production databases often require application-aware backup procedures or carefully coordinated snapshot methods.

Installing Velero in Kubernetes

Before installing Velero, you need a functioning Kubernetes cluster and an appropriately configured kubectl connection.

Additionally, you need an object storage destination supported by your chosen Velero storage plugin.

For example, you might use Amazon S3 or a compatible storage solution such as MinIO.

Once the storage destination is ready, install the Velero CLI on your administration workstation.

The correct installation package and supported Kubernetes versions depend on the Velero release.

Therefore, I recommend checking the release-specific documentation before installing Velero in production.

Example: Installing Velero with S3 Storage

The following command demonstrates the general installation structure for an environment using the AWS storage plugin.

However, the placeholders must be replaced with settings appropriate for your infrastructure.

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:<PLUGIN_VERSION> \
  --bucket <BACKUP_BUCKET> \
  --secret-file <CREDENTIALS_FILE> \
  --backup-location-config region=<REGION> \
  --use-node-agent

The --provider option identifies the selected provider integration.

Meanwhile, --plugins specifies the storage plugin image. The plugin version must be compatible with the installed Velero release.

The --bucket parameter identifies the object storage bucket, while --secret-file supplies credentials from a local file.

Finally, --use-node-agent installs the components required for File System Backup and supported data movement operations.

For S3-compatible storage systems using a custom endpoint, additional backup-location settings may be necessary.

Likewise, CSI snapshot support may require additional installation flags and configuration, depending on the Velero version.

Important: The command above is an installation template, not a complete production configuration. Always verify plugin compatibility, storage permissions, authentication, and network access before proceeding.

Checking the Velero Installation

After installation, inspect the Pods in the Velero Namespace:

kubectl get pods -n velero

Additionally, check the configured backup storage locations:

velero backup-location get

If the storage location is unavailable, investigate the provider configuration, credentials, bucket permissions, and network connectivity.

A working object storage connection is essential before attempting your first backup.

Practical Example: Creating a Kubernetes Backup

Let’s assume you have a test application running inside a Namespace called demo-app.

The Namespace contains a Deployment, Service, ConfigMap, and possibly a PersistentVolumeClaim.

To create a backup of the selected Namespace, run:

velero backup create demo-app-backup \
  --include-namespaces demo-app

Velero creates a Backup resource and begins processing the selected Kubernetes objects.

However, whether volume data is also protected depends on your storage configuration and selected backup method.

Therefore, do not assume that a successful resource backup automatically includes all persistent files.

Checking Backup Status

First, list the available backups:

velero backup get

For additional details, run:

velero backup describe demo-app-backup --details

You can also inspect the backup logs:

velero backup logs demo-app-backup

These commands are useful when investigating warnings, incomplete backups, or problems with persistent volumes.

Furthermore, inspect the details of any configured volume backup operations.

After all, the most important question is not simply whether Velero created a backup object. The real question is whether all required application data can be recovered from it.

Creating a File System Backup

Suppose you want to explicitly use File System Backup for eligible Pod volumes.

Assuming the Velero Node Agent and backup repository are configured correctly, you can use the following command:

velero backup create demo-app-fs-backup \
  --include-namespaces demo-app \
  --default-volumes-to-fs-backup

The --default-volumes-to-fs-backup option tells Velero to use file-system-based backup for eligible Pod volumes by default.

However, unsupported volumes are not automatically protected.

Therefore, you should verify that the expected volume backup operations have actually completed.

For example, inspect the PodVolumeBackup resources:

kubectl get podvolumebackups -n velero

If a backup operation fails, investigate its status and the related Velero logs.

This verification is especially important when introducing a new storage backend or migrating an existing workload.

Restoring Kubernetes Resources with Velero

Creating a backup is only half the process. The real value becomes apparent when you successfully restore an application.

Velero provides the restore create command for this purpose.

For example, the following command starts a restore from our previous backup:

velero restore create demo-app-restore \
  --from-backup demo-app-backup

Velero then processes the resources stored in the backup and attempts to recreate them in the Kubernetes cluster.

However, existing resources can affect the restore operation.

For example, Velero does not automatically overwrite every existing object. The behavior depends on the resource type and selected restore policies.

Therefore, a first restore test should ideally be performed in a separate, isolated environment.

Monitoring the Restore

List the available restores:

velero restore get

Next, inspect the details:

velero restore describe demo-app-restore --details

For troubleshooting, read the restore logs:

velero restore logs demo-app-restore

Once the operation finishes, inspect the restored resources:

kubectl get all -n demo-app
kubectl get pvc -n demo-app
kubectl get configmaps -n demo-app

However, kubectl get all does not display every Kubernetes resource type.

Consequently, you should also verify Secrets, custom resources, storage bindings, and any other objects required by the application.

Most importantly, test the application itself.

A Deployment may exist and its Pods may be running, while the application remains unusable because of missing data or unavailable dependencies.

Automating Kubernetes Backups with Velero Schedules

Manual backups are useful for experiments, but production environments generally require automation.

Velero supports scheduled backup operations through Schedule resources.

For example, you can configure a daily backup using a cron expression.

velero schedule create daily-backup \
  --schedule="0 2 * * *" \
  --include-namespaces demo-app \
  --ttl 168h

This schedule creates a backup every day at 02:00 according to the schedule’s time interpretation.

The --ttl 168h option sets a retention period of seven days.

However, these settings are only examples.

For a production application, backup frequency should depend on how often the data changes and how much information the organization can afford to lose.

Furthermore, scheduled backups must be monitored.

A backup job that runs automatically but has been failing for several weeks provides little protection.

Therefore, I recommend configuring appropriate alerting and regularly reviewing backup status, storage capacity, and retention behavior.

Velero vs etcd Backups: What Is the Difference?

If you already know how to create an etcd snapshot, you may wonder whether Velero can replace that procedure.

The short answer is no, not completely.

etcd is the central data store used by Kubernetes to persist cluster state.

An etcd snapshot captures the database state at a particular point in time and can be used as part of a control-plane recovery procedure.

Velero, on the other hand, focuses on protecting Kubernetes resources through the API and supporting backup methods for persistent application data.

Consequently, the two tools operate at different levels.

For example, an etcd snapshot may be critical when rebuilding a damaged Kubernetes control plane.

Velero is especially useful when restoring application resources, recovering a deleted Namespace, or migrating selected workloads to another Kubernetes cluster.

However, Velero does not automatically recreate the entire underlying Kubernetes infrastructure.

Therefore, a complete disaster recovery strategy may benefit from using both etcd snapshots and Velero backups.

Each protects different aspects of the environment.

Database Backups in Kubernetes Require Special Attention

Databases are among the most challenging workloads to protect correctly.

Systems such as PostgreSQL and MySQL continuously modify their storage while processing transactions.

Consequently, copying database files while the application is running can produce an inconsistent backup.

Although Velero can protect suitable Persistent Volumes, not every storage-level backup is automatically application-consistent.

For example, a CSI snapshot may capture the storage state at a particular point in time, but that does not necessarily guarantee that all database transactions have been handled in a way suitable for recovery.

Therefore, database-aware backup procedures remain important.

For PostgreSQL, appropriate solutions may involve logical dumps, physical backups, or Write-Ahead Log archiving.

MySQL also provides database-specific backup and replication mechanisms.

Furthermore, some Kubernetes database Operators include features for creating and managing database backups.

In production, I would often use Velero to protect Kubernetes resource definitions while relying on an appropriate database-specific backup solution for critical database contents.

This separation can make recovery procedures easier to understand and validate.

What Happens If the Entire Kubernetes Cluster Is Lost?

A complete cluster failure is one of the most demanding disaster recovery scenarios.

For example, imagine that all control-plane nodes and their associated infrastructure become unavailable.

In this situation, you cannot simply execute a normal Velero restore against the missing cluster.

First, you need a functioning Kubernetes destination environment.

This may require rebuilding the control plane, installing networking components, configuring storage drivers, and restoring access to external dependencies.

Only after the destination cluster is ready can Velero be configured to access the backup repository and begin restoring supported application resources.

Furthermore, the destination environment may not have exactly the same storage configuration as the original cluster.

For example, StorageClass names, CSI drivers, or external load balancer settings may differ.

Therefore, disaster recovery planning should include infrastructure compatibility, not just backup creation.

Most importantly, test the complete process before a real incident occurs.

Common Kubernetes Backup and Restore Mistakes

One of the most common mistakes is assuming that a completed Velero backup automatically includes all Persistent Volume data.

Depending on the configuration, the backup may contain only Kubernetes resource definitions.

Another mistake is storing backups exclusively within the same infrastructure that hosts the production workloads.

If the storage environment fails completely, both production data and backups may become unavailable.

Furthermore, incorrect object storage permissions can cause backup operations to fail unexpectedly.

Similarly, incompatible storage plugins or missing CSI snapshot components may prevent specific volume backup methods from working.

Another common problem is never testing restores.

For example, a restored Deployment may depend on a container image that is no longer available or on a StorageClass that does not exist in the recovery cluster.

Therefore, reliable backup operations must always include periodic recovery testing.

Designing a Practical Kubernetes Backup Strategy

In my opinion, the best approach is to start by identifying which resources and application data actually require protection.

From there, you can select the appropriate backup mechanism for each workload.

A practical strategy might include:

Regular Velero backups of important Kubernetes resources.
CSI snapshot or file-system-based protection for supported Persistent Volumes.
Application-consistent backups for critical databases.
Independent etcd snapshots for control-plane recovery.
Protected backup storage outside the production cluster.
Automatic monitoring and alerting for failed backups.
Regular restore tests in isolated environments.
Documented disaster recovery procedures.

Additionally, organizations should define their Recovery Point Objective and Recovery Time Objective.

The Recovery Point Objective, or RPO, describes the maximum acceptable amount of data loss.

The Recovery Time Objective, or RTO, describes how quickly a service should be restored after an incident.

For example, a development environment may tolerate a longer recovery period and less frequent backups.

A business-critical application, however, may require much shorter recovery times and more frequent protection.

Consequently, the backup strategy should be based on operational requirements rather than arbitrary default values.

Frequently Asked Questions About Kubernetes Backup and Restore

What Is Velero in Kubernetes?

Velero is an open-source tool for backing up, restoring, and migrating Kubernetes resources. It also supports different methods for protecting persistent application data, including CSI snapshots and File System Backup.

Can Velero Back Up Persistent Volumes?

Yes. Velero can protect supported Persistent Volumes using different methods. However, the available options depend on the CSI driver, storage system, Velero version, and backup configuration.

Does Velero Replace etcd Backups?

No. Velero and etcd snapshots protect different aspects of Kubernetes. etcd snapshots preserve the cluster’s underlying state database, while Velero focuses on Kubernetes API resources and supported application data.

Can Velero Restore an Entire Kubernetes Cluster?

Velero can restore many Kubernetes resources and supported volume data into a suitable destination cluster. However, it does not automatically recreate the entire Kubernetes infrastructure, including the control plane, networking, and storage systems.

How Can I Automate Kubernetes Backups?

Velero provides Schedules for creating backups automatically. These schedules define when backups run and can include retention settings. Nevertheless, backup monitoring and regular restore testing remain necessary.

Can Velero Back Up PostgreSQL or MySQL?

Velero can back up supported volumes used by database workloads. However, volume backups are not automatically application-consistent. For production databases, database-specific backup procedures or carefully coordinated snapshot methods are often more appropriate.

Conclusion: Kubernetes Backup and Restore Is Essential for Production

Kubernetes provides powerful mechanisms for managing containerized applications, replacing failed Pods, and maintaining the desired state of workloads.

However, these capabilities do not eliminate the need for backups.

Persistent application data can still be lost, Kubernetes resources can be deleted accidentally, and complete infrastructure failures remain possible.

Therefore, Kubernetes backup and restore should be considered a fundamental part of production cluster operations.

Velero provides a useful foundation because it can protect Kubernetes resources through the API and coordinate supported backup methods for Persistent Volumes.

Nevertheless, administrators must understand the differences between Kubernetes resource backups, storage snapshots, and application-consistent data protection.

For example, a successfully restored Deployment is not particularly useful if its database cannot be recovered.

Similarly, a snapshot stored on the same failed storage system may provide little protection during a major infrastructure incident.

My recommendation is to start with a small test application. Create a dedicated Namespace, back it up with Velero, and restore it into an isolated environment.

Next, add persistent storage and investigate which backup method works with your CSI driver.

Afterward, test more complex scenarios involving databases, external dependencies, and eventually a complete cluster rebuild.

By following this approach, you will gain practical experience and discover potential weaknesses before they affect a production environment.

My conclusion is simple: A Kubernetes backup becomes valuable only when you know that the application and its data can actually be restored.

Velero can be an important part of that strategy, but the reliability of the overall recovery process still depends on thoughtful architecture, compatible storage systems, and regular testing.