Cohesity Immutable Backups
You set up cohesity immutable backups by applying a retention lock to backup snapshots. This lock stops users and apps from changing or deleting saved data before expiration. Teams often rely on storage admin roles to manage these backup rules. Still, broad admin permissions create risks when an attacker steals a high-level login key. A bad actor with admin rights can change policies for future backup runs. How cohesity immutable backups work in practice The platform uses a audit storage, rea
Immutable Backups: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up cohesity immutable backups by applying a retention lock to backup snapshots. This lock stops users and apps from changing or deleting saved data before expiration. Teams often rely on storage admin roles to manage these backup rules. Still, broad admin permissions create risks when an attacker steals a high-level login key. A bad actor with admin rights can change policies for future backup runs.
How cohesity immutable backups work in practice
The platform uses a audit storage, read-many model to protect your saved data snapshots. When a backup job finishes, the system mounts the snapshot in a read-only state. No user or process can overwrite the blocks inside that saved point in time. You also attach a retention lock rule to the storage policy or job. This rule sets a strict timer on how long the snapshot must stay locked. Under strict lock modes, even a cluster admin cannot shorten the timer or delete files. The storage system checks the lock clock against a secure time source. It denies any delete request until the retention timer hits zero.
Teams also pair immutable snapshots with role-based permissions and quorum approvals. Quorum rules require two or more admins to approve major changes on the cluster. If one admin tries to delete a backup group, a second admin must approve it. This step stops a single compromised account from wrecking the backup system alone.
What native backup locks solve and what they leave open
Native retention locks do a great job of protecting past snapshots from ransomware encryption. Once the system locks a snapshot, attackers cannot wipe that specific recovery point. Still, storage locks only protect data after the backup job writes it to disk. They do not inspect the live commands that engineers run on production databases today. They also do not control how admins interact with the backup API or CLI.
A role check only decides who can log in to the management console or database. It does not check what individual queries or scripts do while a session is active. An engineer restoring a snapshot to a test server might query sensitive customer records. Without runtime checks, those queries return raw emails, phone numbers, and card numbers. Likewise, a script with broad API keys can misconfigure retention rules for new jobs. Teams need a way to inspect every command and mask sensitive fields in flight.
Immutable Backups: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Securing live database restores and admin workflows
When teams restore a locked backup to debug an issue, the restored database goes live. Developers then run SQL queries against that restored copy to check data health. Standard storage locks do not hide sensitive data inside that restored database instance. You must control who runs commands on restored systems and what data they read.
Good security pairs immutable storage with strict controls over live admin and database sessions. Instead of handing out static admin keys, teams should approve dangerous actions one by one. Masking rules can also rewrite emails and national IDs in query results during restore tests. This keeps test workflows safe while your locked snapshots stay untouched on disk.
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 beside the service as an open-source proxy, a sidecar for your database or API.
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 review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can a root admin delete a locked backup snapshot early?
It depends on the lock mode you choose when you set up the policy. In strict compliance mode, no user or support staff can delete data before the timer ends.
Do immutable backups protect live databases from bad queries?
No, backup locks only protect saved copies of data on the backup storage cluster. They do not stop a user from running a drop table command on production.
How do teams protect sensitive data when testing backup restores?
Teams apply data masking to the database session during the restore test. Masking rewrites matched fields like card numbers and phone numbers in query results.