Protect your cluster, impress your boss, and sleep better at night—all with the magical combo of Velero and MinIO.

Table of Contents#

Why You Need Backups for Kubernetes#

Let’s face it—Kubernetes is powerful, but it’s also unforgiving. Accidentally delete a namespace? Yikes. Corrupt a persistent volume? It’s panic time. And nobody wants to explain to their boss, “Sorry, I thought etcd would never betray me.”

Backups aren’t optional. They’re your insurance policy against fat fingers, rogue scripts, and Murphy’s Law. In Kubernetes, a “backup” means not just saving your YAMLs, but also the actual data your apps rely on.

What is Velero?#

Think of Velero as the Swiss Army knife of Kubernetes backup and restore.

  • It backs up your cluster’s resources (deployments, services, secrets, etc.) and persistent volumes.
  • It supports scheduled backups, on-demand backups, and disaster recovery scenarios.
  • It’s cloud-agnostic: works with AWS, Azure, GCP, and any S3-compatible storage (more on that soon).
  • It also migrates workloads between clusters—because sometimes you just want a fresh start somewhere else.

If you run production workloads on Kubernetes and don’t use Velero, you’re basically riding a unicycle on a tightrope… blindfolded.

What is MinIO?#

MinIO is the unsung hero of on-premises object storage.

  • It’s an open-source, S3-compatible object storage solution you can deploy anywhere—your datacenter, your cloud, your closet lab next to your router and collection of USB drives.
  • It “looks” like Amazon S3 to any app that speaks the S3 API.
  • It’s blazing fast, lightweight, and designed for high availability (if you want to get fancy).

Why is this important? Because most enterprise backup tools, including Velero, want to write to S3. But not every organization can (or wants to) use Amazon’s cloud, for reasons ranging from budget to regulatory compliance to “I just like doing it myself.”

Check out my MinIO Install guide with SSL#

How Do They Work Together?#

It’s pretty simple:

  1. Velero takes backups of your Kubernetes resources and data.
  2. Velero needs somewhere to put those backups. (No, /tmp on a pod doesn’t cut it.)
  3. MinIO acts as the storage target.
    • Velero sends all its backup files to a “bucket” in MinIO, using the S3 API.
  4. When you need to restore, Velero fetches data from MinIO and brings your cluster back to life.

Think of MinIO as the cloud storage that never leaves your datacenter.

Should Velero Run in the Same Cluster as Your Workloads?#

Short answer:

Yes, install Velero in the same cluster as your workloads.

Here’s why:

  • Velero needs direct access to the Kubernetes API and resources it’s protecting.
  • Backups and restores work best when Velero can “see” everything: deployments, secrets, PVs, etc.
  • For DR: You install Velero on a new cluster, and point it to the same backup storage (MinIO), then restore from there.

You wouldn’t leave your only fire extinguisher in a neighbor’s garage, right? Same principle.

Do I Need Velero on Every Node?#

Nope!
Velero is installed once per cluster, typically as a Kubernetes deployment (in a velero namespace).

  • The main Velero pod runs as a single deployment.
  • If you use volume backup helpers (like restic/node-agent), those do run as a DaemonSet (one pod per node)—but you only need these for certain types of backups.
  • You do NOT install Velero itself on every node. Just once per cluster. Kubernetes schedules the pods where it likes.

In other words: “Set it and forget it”—but check your logs now and then, just in case.

Why Velero Needs MinIO (Or S3)#

This is the crux of the matter!

Velero Needs an Object Store#

  • Velero doesn’t keep backups inside your cluster (what would be the point?).
  • It needs to write to object storage—specifically, something S3-compatible.

What’s an Object Store?#

  • Think of it as a massive, cloud-based (or on-prem) file server for blobs of data.
  • S3 is the original gold standard, but MinIO talks the same language.

Why MinIO?#

  • On-prem: No AWS? No problem! MinIO gives you “S3 in your datacenter.”
  • Lab/test: Don’t want to rack up cloud charges just to test backup/restore? MinIO is free and fast.
  • Air-gapped/secure: Some places simply can’t send data to the cloud. MinIO to the rescue.

What Actually Gets Stored?#

  • Velero stores:
    • YAML exports of your Kubernetes resources
    • Volume snapshots (or copies, if using restic)
    • Backup metadata
  • All of this lives in MinIO, safe and sound until you need it.

Alternatives#

  • If you’re in AWS, just use S3.
  • In Azure? Use Blob storage with S3 gateway or NFS Gateway.
  • In GCP? There’s S3 interoperability, but honestly, if you want pain-free on-prem, MinIO is hard to beat.

Example: Installing Velero with MinIO on Kubernetes#

Here’s how you might set this up in your home lab or test cluster:

1. Install MinIO#

You can run MinIO as a deployment in your Kubernetes cluster or as a separate VM/container.
Example Helm (quick and dirty):

helm repo add minio https://charts.min.io/
helm install minio/minio --generate-name \
  --set accessKey=myaccesskey,secretKey=mysecretkey

2. Create a MinIO Bucket#

Either use the MinIO web console or the CLI:

mc alias set myminio http://<minio-service>:9000 myaccesskey mysecretkey
mc mb myminio/velero

3. Install Velero#

Assuming you have the Velero CLI installed:

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.8.0 \
  --bucket velero \
  --secret-file ./minio-credentials \
  --use-restic \
  --backup-location-config \
    region=minio,s3ForcePathStyle=true,s3Url=http://<minio-service>:9000

Your minio-credentials file would look like:

[default]
aws_access_key_id = myaccesskey
aws_secret_access_key = mysecretkey

4. Verify Backups#

Create a test backup:

velero backup create test-backup

Check your MinIO bucket. If you see a new folder named after your backup… 🎉 you’re protected!

Gotchas, Tips, and Best Practices#

  • Secure your MinIO instance! Use TLS/SSL and strong credentials. Don’t leave the default keys.

  • Offsite is better: If you really care about your data, sync your MinIO bucket to offsite/cloud storage for true disaster recovery.

  • Automate everything: Use GitOps or ArgoCD to manage your Velero (and MinIO) config as code.

  • Don’t forget PVs: If you use persistent volumes, make sure your backup method covers them. Not all PVs are created equal!

  • Test your restores. Backups are only as good as your last successful restore. (You don’t want to find out during a crisis that your “backups” are just empty YAMLs.)

Conclusion: Don’t Wait Until It’s Too Late#

Kubernetes makes it easy to scale up. It also makes it terrifyingly easy to destroy everything with a single typo. Velero and MinIO are your seatbelt and airbag. Install them before you need them.

To recap:#

  • Velero = Kubernetes backup and restore superhero.
  • MinIO = S3-compatible storage you can run anywhere.
  • Together, they make sure your cluster can always rise from the ashes—no cloud bill required.

So go forth and back up! Your future self (and probably your boss) will thank you.

Questions, clever tips, or backup horror stories? Drop them in the comments. And remember: Nobody ever got fired for having too many backups.

Happy clustering! 🚀