Pure Storage and Cohesity
You link pure storage and cohesity by pairing array snapshots with backup storage jobs. This setup sends block or file data from your fast disks to secondary storage. Many storage teams start by creating a shared service account on both platforms. They often give this account broad admin rights so backup jobs do not fail. When teams grant wide permissions, any user or script with that key can delete snapshots. A mistake in one script can wipe out primary volumes and backup copies together. How
Storage: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You link pure storage and cohesity by pairing array snapshots with backup storage jobs. This setup sends block or file data from your fast disks to secondary storage. Many storage teams start by creating a shared service account on both platforms. They often give this account broad admin rights so backup jobs do not fail. When teams grant wide permissions, any user or script with that key can delete snapshots. A mistake in one script can wipe out primary volumes and backup copies together.
How pure storage and cohesity work together
Pure Storage runs fast flash arrays for primary apps and databases. Cohesity manages secondary data, backups, and long-term archives on its own cluster. When you pair them, the backup cluster talks to the flash array API. The backup tool asks the flash array to take a quick snapshot. Then it reads that snapshot data over the network and stores a copy.
To make this work, admins set up network routes between both storage systems. Next, they create a dedicated role on the flash array for the backup tool. This role needs rights to create volumes, take snapshots, and read data blocks. On the backup side, admins register the flash array as a source. They enter the array address and save the API token in the backup settings.
During a restore, the flow runs in reverse. The backup cluster pushes volume data back to the flash array over the network. Teams can also mount backup volumes directly to test old data copies. This native setup relies on static keys or directory groups to check identity.
What native storage roles solve and what they miss
Native roles on both platforms control who can log in to each console. You can map directory groups to storage admin, ops, or read-only roles. You can also turn on storage lock features to stop snapshot deletion for set days. These controls help separate daily backup watchers from full system admins.
Still, native roles only check who logs in at the start of a session. They do not check single commands or API calls while a session runs. Once an admin logs into the array CLI or API, the role grants full power. The system cannot pause a single risky volume drop for a peer check.
Shared API keys for backup scripts create another gap for the team. Engineers often run custom scripts to mount test clones from backup snapshots. Those scripts need keys stored on build servers or laptops. If a developer pulls production data into a test volume, raw data travels with it. Native storage roles do not rewrite emails, phone numbers, or card numbers inside mounted databases. Audit logs show that a service account ran a job, not which human triggered it.
Storage: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to tighten day-to-day storage and backup operations
Start by replacing full admin accounts on your backup links with custom roles. Grant the backup user only the rights needed to snapshot and transfer volumes. Rotate the API tokens used between both platforms on a fixed schedule.
Next, separate the roles that manage primary disks from the roles that manage backups. If one account gets stolen, the attacker cannot wipe both primary and secondary copies. Turn on retention locks on both platforms so no account can shorten snapshot timers.
Finally, look at how engineers query the databases that sit on those storage volumes. Storage snapshots protect against disk loss, not bad queries or leaked table rows. You need controls at the database and command level to track human actions.
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
How does Cohesity pull data from Pure Storage arrays?
The backup cluster connects to the flash array API to trigger a local snapshot. It then reads the changed blocks over the storage network and writes them to backup nodes.
What permissions does the backup account need on the flash array?
The account needs storage admin rights to create snapshots, read volumes, and map hosts. It should not have full array admin rights that allow changing user roles or system settings.
Can storage snapshots stop an engineer from leaking database rows?
No, storage snapshots only copy and restore full blocks or files for recovery. To rewrite emails or card numbers in query results, you need controls at the database layer.