Longhorn Backup
You set up a longhorn backup by pointing your cluster to an external store. Then you create a volume snapshot and send the changed blocks to that store. Teams often give wide cluster roles to operators who manage these storage tasks. Broad roles create risk because one bad command can wipe out live volumes. How a longhorn backup works in practice Longhorn splits each Kubernetes volume into small data blocks across your cluster nodes. When you take a snapshot, the system freezes the current bl
Backup Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a longhorn backup by pointing your cluster to an external store. Then you create a volume snapshot and send the changed blocks to that store. Teams often give wide cluster roles to operators who manage these storage tasks. Broad roles create risk because one bad command can wipe out live volumes.
How a longhorn backup works in practice
Longhorn splits each Kubernetes volume into small data blocks across your cluster nodes. When you take a snapshot, the system freezes the current block state. This snapshot stays on the local disk inside your cluster. A local snapshot fails if the whole node or cluster goes down.
A true longhorn backup copies those blocks to an outside storage system. You can use an audit storage or a network file share for this. The first run copies every data block from the volume to the remote store. Later runs only send the blocks that changed since the last run. This block design saves network bandwidth and keeps storage costs low.
Teams schedule these jobs using recurring tasks inside the Kubernetes cluster. You group volumes by label and attach a schedule to each group. The storage controller reads the schedule and runs the copy job on time. It also deletes old snapshots so disks do not fill up.
Setting up remote storage and cluster roles
First, you need a remote bucket or file server outside your cluster. Your cluster needs a secret key to read and write to that bucket. You store this key in a standard Kubernetes secret inside the storage namespace. Then you point the storage manager to the bucket path and secret name.
Once the store is live, operators can trigger a restore to any node. They can also mount a restored volume to inspect data during an incident. Many teams grant full admin roles so engineers can fix broken volumes fast. This makes daily work easy, but it opens a big security gap.
Backup Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native storage roles solve and what they miss
Kubernetes role bindings decide who can talk to the cluster API. You can allow an engineer to view volumes or start a backup job. You can also block developers from changing the remote bucket secret. These rules control who can enter the cluster and touch storage objects.
Still, cluster roles do not watch what happens inside a live session. An engineer who mounts a volume to debug an issue gets full read power. That volume might hold database files with emails, phone numbers, or card numbers. Native storage rules cannot rewrite those fields when someone reads a raw file.
Also, role bindings cannot stop a risky command once a user logs in. An admin with restore rights can also delete a live volume by mistake. Standard cluster logs show that the user connected, not every shell command they ran. Teams need deeper controls to approve destructive actions and mask sensitive data in results.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between a snapshot and a longhorn backup?
A snapshot stays on the local disks inside your Kubernetes cluster. A backup copies those data blocks to an outside store for disaster recovery.
How do you test a restored volume without breaking live apps?
You restore the backup to a new volume with a different name. Then you attach that test volume to a temporary pod to check the files.
Can you run scheduled backups for only specific volumes?
Yes, you can assign custom labels to your important persistent volumes. Then you link those labels to a recurring job schedule in your cluster.