Cohesity Backup Architecture
A cohesity backup architecture groups storage nodes into one shared cluster to protect data. You set it up by joining nodes, creating storage domains, and setting backup rules. Most teams start by linking their virtual machines and databases to the cluster. They often give broad admin roles to engineers so setup goes fast. Broad roles create risk because one bad command can delete backup snapshots. How cohesity backup architecture works The system runs on a distributed file system that spans
Zero Trust Architecture + Backup Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A cohesity backup architecture groups storage nodes into one shared cluster to protect data. You set it up by joining nodes, creating storage domains, and setting backup rules. Most teams start by linking their virtual machines and databases to the cluster. They often give broad admin roles to engineers so setup goes fast. Broad roles create risk because one bad command can delete backup snapshots.
How cohesity backup architecture works
The system runs on a distributed file system that spans across multiple hardware or cloud nodes. Every node in the cluster acts as both a storage unit and a compute engine. There is no single master node that can fail and stop your backups. If one node goes down, the other nodes take over the active tasks right away.
Data enters the cluster through logical pools called storage domains. These domains hold your rules for deduplication, compression, and encryption. When a backup job runs, the system breaks the incoming data into small chunks. It checks if those chunks already exist in the storage domain. It only writes new chunks to the disk, which saves a lot of space.
The platform uses infinite snapshots to track changes over time without copying full files. Each snapshot points to the exact data blocks needed to restore a file or database. When a user needs to recover data, the cluster builds a view from those blocks. It can mount that view straight to a server so apps come back online fast.
How role setup and data protection policies operate
Teams manage backup jobs by creating protection policies inside the cluster control plane. A policy sets how often backups run and how long the cluster keeps snapshots. You can also add rules to copy snapshots to cold cloud storage or tape. Once a policy is ready, you attach it to your databases, virtual machines, or file shares.
Access to the cluster depends on role-based access control and external identity providers. Admins map directory groups to specific cluster roles. You can limit a role so a team only sees its own databases or virtual machines. Multi-tenancy features also let teams split one cluster into isolated views for different business units.
Zero Trust Architecture + Backup Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native cluster roles solve and what they miss
Native roles and storage domains solve the problem of basic login control and data isolation. They make sure only approved users can log in to the cluster management interface. They also keep backup jobs organized and stop hardware failures from causing data loss. Immutability settings help protect saved snapshots from basic file tampering.
Still, native setup only checks who logs in at the start of a session. Once an engineer or script logs in with an admin role, the system trusts every action. It does not inspect individual commands or database queries in flight during a restore or test. If someone mounts a production backup to fix a bug, they see raw user data.
Native backup tools do not mask sensitive fields inside mounted databases during live fixing. Engineers running queries against restored data can read raw emails, phone numbers, card numbers, and national IDs. Also, shared service accounts used for automation make it hard to see which person ran a destructive command. Teams need a way to check every command and rewrite sensitive fields in results.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How does the cluster handle a node failure during a backup job?
The distributed file system moves active tasks to healthy nodes right away. Your backup job keeps running without data loss because data blocks replicate across nodes.
Can teams test backup data without copying full databases?
Yes, the cluster creates zero-cost clones from existing snapshots in seconds. Teams can mount these clones to test servers without using extra storage space.
Why is role-based access control not enough for restored databases?
Role-based access only controls who can trigger a restore or log in to a database. It does not block risky queries in flight or mask emails and card numbers in query results.