Learn Velero - Volume Backup: Cloud Snapshot vs Restic/Kopia

#Introduction

This is one of the most important architectural decisions in the entire series: how data on persistent volumes is stored. In episode 3 you installed the node-agent with kopia, and in episode 4 volume backup ran through file-level backup. But on cloud clusters there's a much faster alternative: cloud snapshots. Episode 8 compares the two honestly — speed, cost, portability, and when to choose which.

Imagine two ways to copy a library book: photocopying it page by page (file-level — slow but the result is pure text, portable anywhere) vs scanning the whole shelf at once as blocks (snapshot — very fast but tied to that shelf's brand). Both are legitimate; both have a price.

#Cloud Snapshot: Block-level

#How It Works

Cloud snapshots leverage the cloud provider's native snapshot service: EBS snapshots (AWS), Persistent Disk snapshots (GCP), Azure Disk snapshots. Velero asks the provider to create an instant, consistent copy of the disk blocks — without opening pods or reading files one by one.

Prerequisites: a configured VSL (episode 3) and the node hosting the PVC must be in the same region as the VSL.

velero backup create snapshot-backup \
  --include-namespaces app \
  --snapshot-volumes=true

#Strengths

• Very fast: snapshots are created in seconds, regardless of data size.
• Consistent at the block level: doesn't depend on the running application.
• No node-agent: no DaemonSet needed in the cluster.

#Weaknesses

• Vendor lock-in: an EBS snapshot can only be restored on AWS, usually in the same region.
• Needs additional cloud credentials and a correct VSL.
• Doesn't apply to non-cloud volumes like NFS/CEPH that have no snapshot service.
• Cost: snapshots are stored by the provider and billed per GB.

#Restic/Kopia: File-level Backup

#How It Works

The second approach is file-level backup run by the node-agent — a DaemonSet running on every node. When a volume backup is requested, the node-agent binds the volume to the host, reads it file by file, then stores the data in a repository on the BSL. Velero uses restic (legacy) or kopia (faster, default in Velero 1.18) as its repository engine.

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

For installations that don't have the node-agent yet:

velero install --provider aws --plugins velero/velero-plugin-for-aws:v1.14.0 \
  --bucket velero --secret-file ./credentials-velero \
  --use-node-agent --uploader-type=kopia --default-volumes-to-fs-backup

#Strengths

• Portable: data is stored as files in the BSL; restore can happen on any cluster/provider.
• No snapshot provider needed: works with MinIO, NFS, local volumes, bare metal.
• Repository deduplication and encryption (restic/kopia).
• Cross-region and cross-cloud restore (we cover this in episode 19).

#Weaknesses

• Slower for large volumes (reads every file).
• Consumes node resources (node-agent pods).
• Beta quality: FSB is officially still beta and has limitations (episode 16).
• Cache in the pod filesystem: with kopia, there's an issue when the Velero pod uses ReadOnlyRootFileSystem — the 1.18 docs recommend granting write permission on the cache directory.

#Comparison Table

+----------------------+---------------------------+-----------------------------+
| Aspect               | Cloud Snapshot (EBS/PD)  | File-level (restic/kopia)   |
+----------------------+---------------------------+-----------------------------+
| Speed                | very fast (seconds)       | slow for large data         |
| Dependency           | VSL + cloud region        | node-agent + BSL            |
| Vendor lock-in       | high (region/cloud)       | low (portable)              |
| NFS / non-cloud      | not supported             | supported                   |
| Cost                 | per GB per snapshot       | storage + node resources    |
| Consistency          | block-level               | depends on file state       |
+----------------------+---------------------------+-----------------------------+

#When to Choose Which

• Full cloud provider, large data, tight RPO → cloud snapshot.
• Multi-cloud / bare metal / NFS / portability first → kopia file-level.
• Hybrid (very common in production): cloud snapshots for main workloads in-region, plus kopia for cross-region archives and non-cloud PVCs.

#Closing

Key takeaways:

• Cloud snapshot: fast, block-level, needs a VSL, tied to provider/region.
• File-level (restic/kopia): portable, no snapshot provider needed, good for NFS/bare metal.
• Kopia replaces restic as the default in Velero 1.18; new restic backups are disabled in 1.17+.
• Production is usually hybrid: snapshots for speed, file-level for portability.
• Check velero backup describe --details to see which volume mechanism was used.

In episode 9 next, we make sure backups are consistent at the application level: pre/post backup hooks — flushing databases, pg_dump, resuming after backup — for PostgreSQL/MySQL and stateful applications so data isn't corrupted while being copied.