The first episode of The Security Podcast of Silicon Valley aired on May 6, 2021, with Jon McLachlan hosting alone. His guest was Anand Ganesh, the founding software architect at Hammerspace, a company building what it then called storageless data: one namespace for your files, wherever the bytes happen to sit, managed through metadata. Most of the half hour went to what that design does for security, from permissions and recovery to encryption keys and deletion.
“in Hammerspace, a file is a file is a file. There’s only one file.”
Anand Ganesh, at 6:24
Hammerspace lists 2018 as its founding year and Redwood City, California, as its home (LinkedIn). Its co-founder and chief executive, David Flynn, founded Fusion-io, the flash memory company that SanDisk acquired in 2014 (Hammerspace, Wikipedia). Today the company calls its product a data platform for AI, one that unifies unstructured data across data centers, clouds and edge sites into a global namespace without copying or migrating it (Hammerspace). The word also has a life in cartoons. Hammerspace is “an imaginary extradimensional and instantly accessible storage area,” the place characters pull hammers and anvils from (Wikipedia). The company’s metadata server, fittingly, is called the Anvil.
Jon was then running Peacemakr, the company he co-founded in 2019 (LinkedIn), and Anand tied the conversation back to it twice, once on bringing your own keys and once on encrypting data inside the application. Five years on, most of what he described is still the shape of the problem: data spread across many systems, permissions copied by hand, recovery that depends on which box you snapshotted, and keys held by someone other than you.
This page is the rest of it: a section for each part of the conversation with the sources beside it, twelve figures, twenty-seven clips from the tape, the full transcript, and four tools: a quiz, a scorecard for how much of your data a recovery and a deletion would really reach, a calculator for what keeping copies in step costs you, and a timeline from a 1943 cartoon to Hammerspace’s validated cryptography.
Storageless data
Jon started at the beginning and asked what storageless data means. Anand borrowed the idea from compute.
“the intent is to evoke in the mind of the listener the same benefits that they have probably experienced and know about with the serverless compute, which is that at the end of the day, you don’t care about where the compute resource resides”
Anand Ganesh, at 0:41
Serverless computing is a cloud model where the customer doesn’t provision, deploy or manage the hardware or software underneath, only the code or the data (Wikipedia). Storageless data applies the same promise to files: you say what you want to happen to them, and the platform decides where they live.
“we are building technology that allows you to serve data on any site, on any infrastructure”
Anand Ganesh, at 1:04
From there, he said, you orchestrate your data “just using intent at a file granular level.”
Where Hammerspace sits
Anand placed the product against the storage most listeners already run. On one side, file storage: network-attached storage from vendors like NetApp or Isilon. On the other, object storage in AWS, Azure and Google Cloud, or on premises with a product like Scality. Hammerspace sits on top of all of it.
“Hammerspace is really a platform that allows you to disaggregate metadata and data.”
Anand Ganesh, at 1:40
That one sentence is the whole design. The file system’s metadata (names, folders, permissions, tags) lives in one place, and the data itself can live on any of those systems underneath.
The Anvil and the DSX
The platform has two parts.
“One is what we call the Anvil, and the other one is the DSX. And the Anvil is our metadata server, and DSX is really the data services component.”
Anand Ganesh, at 1:53
A question Anand said he gets a lot is whether a layer like this adds a hop. His answer was that it stays out of the way.
“there are technologies that’ll sit in the I/O path, but we sort of sit on the side, if you will, where we just allow your clients to talk directly to the data server.”
Anand Ganesh, at 2:22
The trick is an open standard. Version 4.1 of the Network File System protocol, published in 2010, added parallel NFS, which separates the file system’s metadata from the location of the file’s data, so a client asks one metadata server where the data is and then reads and writes it on the data servers directly (Wikipedia). The flavor Anand named, the pNFS Flex Files layout, is RFC 8435, published in August 2018 by two authors listed at Hammerspace, and it lets pNFS use storage devices that need “only a limited degree of interaction with the metadata server” (RFC Editor).
“It’s built on an open protocol, the pNFS Flex Files protocol. There’s an RFC for it. And so you don’t have to install anything proprietary on your Linux clients. They just talk pNFS.”
Anand Ganesh, at 2:31
Jon liked the simplicity and the open standard, and turned to security: with an abstraction layer and someone else managing the service, what do you gain?
Upside-down management
Anand started with the trappings of traditional storage, where the unit of control is the volume and not the file.
“So, when you manage your data through the storage layer, you’re sort of doing upside-down management.”
Anand Ganesh, at 3:22
The directives sit at the volume level, the work is prescriptive, and it’s seldom self-service. A storage administrator does it for the people who use the data, and has to learn the quirks of each vendor’s system along the way.
“even if it’s an open spec like NFSv3, which is three decades old, every vendor will have a certain difference to how they implement the protocol.”
Anand Ganesh, at 4:07
NFS version 3 is RFC 1813, from June 1995 (Wikipedia), so the spec was a little over a quarter century old when this was recorded.
Hammerspace flips it, and drives the data through the metadata.
“The metadata layer not just contains your POSIX metadata, but also stuff that you may tag onto it, or you may derive from running some sort of analysis on that data or processing the data, right?”
Anand Ganesh, at 4:42
POSIX metadata is the familiar part: owners, groups, permissions, timestamps. The tags and the derived metadata are what make it useful for security, because once they sit next to every file, a rule can act on them. Anand’s word for those rules was objectives.
“And so you can completely orchestrate the movement of data, or the locking down of access to that data, using metadata.”
Anand Ganesh, at 4:54
Hammerspace’s own documentation now calls them Service Level Objectives, declarative policies the metadata database enforces automatically across data placement, replication and access controls (Hammerspace).
Every copy needs its own lock
Then the first traditional storage problem, permissions.
“you have your permissions model, and you have to make sure you manage and lock down your permissions. And that’s obviously prone to human error, like anything that is done manually.”
Anand Ganesh, at 5:08
Copying the data makes it worse. Each new copy for a new location or project lands on storage provisioned for it, and its permissions have to be set again, correctly, over there.
“And think about this at the multi-site global level. Like, you have data between, let’s say, Australia, Europe and the United States, and you’re doing this across time zones and whatnot, which becomes a complete nightmare.”
Anand Ganesh, at 5:35
The calculator below runs that arithmetic on your own numbers.
Quarantine loses the lineage
The second problem shows up when something goes wrong. Say a scan finds a file with proprietary information out in the open, unencrypted. The usual fix is to move it somewhere safe.
“a lot of the remediation workflows cause you to move the data to a quarantine server. Now you’ve made the problem even worse, because you’ve lost lineage”
Anand Ganesh, at 6:02
The file now sits on a different system under a different export. Jon echoed the word, and Anand finished the thought.
“Yeah, you’ve lost ownership. Like, you don’t know who owns the file anymore.”
Anand Ganesh, at 6:15
Data lineage is the process of “tracking how data is generated, transformed, transmitted and used across systems over time” (Wikipedia). Breaking it in the middle of an incident is the worst time, because lineage is how you answer who had the file and where it went.
One file, rendered everywhere
Anand’s answer to both problems was the line in this page’s title. In Hammerspace there is one file, rendered on whichever sites need it and created on the infrastructure there so it can be read locally.
“But all your management for permissions and the objectives you set on it and whatnot can be done in one site.”
Anand Ganesh, at 6:37
Jon summed it up as one place for security, management and access policies.
“no matter who is accessing that data, what client they’re accessing that data from, going to be governed by the same set of rules.”
Jon McLachlan, at 7:08
Bring your own keys
Then Anand turned to something he said Jon would appreciate, given Peacemakr.
“You usually cannot do sort of BYOK, bring your own keys, with traditional storage.”
Anand Ganesh, at 7:25
The reason he gave is data mobility. A platform that can move data from one infrastructure to another without disruption, in the same data center or across the world, can also encrypt it on the way, with keys that come from the customer.
“We can encrypt your data using the keys that are, you know, from your environment, from your key management systems. And that gives you a completely different level of control and power.”
Anand Ganesh, at 7:43
Jon asked what storage that covers. Any and all, Anand said: AWS, Google, Azure, your own object storage, your own on-premises systems. Jon’s summary was that it gives you “very robust encryption at rest across that entire ecosystem of available storage.” Key management is the part most storage products keep for themselves, which is why the point mattered. Whoever holds the key decides who can read the data.
What data protection means in storage
Jon pointed out that data protection means something specific in the storage world, and different from what security people mean by it. Anand agreed.
“In the storage community, data protection is really, you know, how do you recover your data easily under different failure circumstances, right?”
Anand Ganesh, at 9:01
In that vocabulary, data protection is snapshots, backups, disaster recovery and replication between availability zones. Encryption with your own keys counts as security, not data protection. Jon put it as availability, backups and recovery times.
Share-level snapshots
In Hammerspace you export data to clients, SMB or NFS, through a share, and you can snapshot the share. Anand painted the picture before explaining why it matters.
“And your share is really just a container for the metadata. It’s just containing, imagine the namespace, the permissions, any metadata that you’ve tagged on the files and whatnot.”
Anand Ganesh, at 10:16
The data behind that share can be anywhere. Some of it on a NetApp volume, some on an Isilon, some on Pure Storage, some in AWS, some in NetApp StorageGRID.
“And we have share-level snapshots. You can take a snapshot of the share, which means you’re taking a sort of a point-in-time snapshot of all this data across all these storage systems.”
Anand Ganesh, at 10:56
A snapshot is “the state of a system at a particular point in time” (Wikipedia). On traditional storage each system takes its own, on its own schedule, so a consistent recovery point across all of them takes coordination. A snapshot of the share is one point in time for everything under it.
The second half of the idea is reuse. Once Hammerspace supports a storage system, Anand said, every data service works on it.
Backup versus snapshot
Backup is harder when metadata and data live apart, because you have to decide what you’re backing up. Anand drew the line this way.
“snapshot is really something that you can sort of go back point in time for your metadata and data.”
Anand Ganesh, at 11:40
A snapshot can also be the start of a new share. A backup, in Hammerspace’s terms, is for reinstalling the Anvil and the DSX, the platform itself. It can’t bring back a storage volume you’ve lost, because the data still has to sit on some storage. Snapshots plus replication between availability zones protect the data, and the backup protects the estate.
Jon played it back.
“So backup is more for just the metadata, all of the data about the data, so to speak.”
Jon McLachlan, at 12:42
Hammerspace’s current white paper on the subject lists five ways the metadata itself is protected: mirroring inside the Anvil, synchronous mirroring between Anvils in a cluster, asynchronous replication between clusters, periodic checkpoints of the metadata database, and an export of the metadata to JSON that can rebuild the file system without the platform (Hammerspace).
Undelete, and ransomware
Then a feature Jon called convenient.
“And we have features like undelete. Like, if you delete a file, it’ll still be available for a certain amount of time. It’s configurable in the product.”
Anand Ganesh, at 13:04
Jon said that would help with ransomware attacks. Anand added the more common case, users.
“So the end user basically just, if they fat-finger something, they delete a bunch of files, you can just go into the undelete location under the share and sort of bring back the files.”
Anand Ganesh, at 13:21
Undeletion is a feature for “restoring computer files which have been removed from a file system” (Wikipedia). The security point is who can use it. When the user can restore their own files, a mistake or a small incident doesn’t queue behind the storage team, and the storage team keeps its time for the restores only they can do. Hammerspace’s 2026 announcement of validated cryptography lists its ransomware resilience as “Immutable snapshots, clones and WORM capabilities to enable rapid recovery” (Hammerspace), where write once read many means data that “cannot be modified” once written (Wikipedia).
The mobility replay log
Moving data creates its own backup problem. A backup of the metadata records where each file’s data was at that moment, and the objectives keep moving the data afterward. Restore the old metadata and it can point at data that isn’t there anymore.
“So we have something called a mobility replay log that, to figure out where the data moves, so that when you go back in time in metadata, you can sort of go back in time in data and figure out where the data is now compared to where it was when the backup was taken.”
Anand Ganesh, at 14:01
Jon heard a familiar tool in it.
“Yeah, it almost sounds like Git, but for the abstract representation of data.”
Jon McLachlan, at 14:31
Git keeps the history of every change so you can move to any earlier state. The replay log does a version of that for data placement, so a restore lands on the data where it actually is.
Active-active is the disaster recovery
The last point in the data protection part was the one the companion post on ransomware recovery leans on. Hammerspace runs on multiple sites at once, and all of them are live.
“it’s all active-active, it’s not active-passive, your global file system sort of becomes a DR, it becomes your DR solution, right?”
Anand Ganesh, at 14:46
So losing a site doesn’t start a failover. Nobody converts a passive site to active or reverses the direction of replication.
“So one site goes down, boom, you just mount from another site and continue. You’re online and you’re up and you’re running.”
Anand Ganesh, at 15:12
Disaster recovery planning usually means rehearsing exactly the steps Anand listed, because they’re slow and easy to get wrong under pressure. The current white paper spells out the replicated design: metadata replicated between sites at intervals “typically measured in seconds,” and sites that get disconnected “continue to function normally” until they reconnect (Hammerspace).
Jon credited the architecture, and Anand agreed.
“You’re precisely right. Precisely.”
Anand Ganesh, at 15:28
Functions that look at your data
Jon changed topics to confidentiality and privacy. Anand’s answer started from the same idea as the storage: if the platform can send data to a storage container, it can send data to a processor.
“So we have support on the Hammerspace platform for what, you know, generally in the industry we call it Lambda functions, where you can plug in a certain piece of compute that can look at your data and derive additional metadata from it.”
Anand Ganesh, at 16:23
AWS Lambda, introduced in 2014, “executes code in response to events” (Wikipedia). In Hammerspace the trigger is an objective, and the function’s output is metadata. A data loss prevention tool, for example, could scan files and flag the ones breaching confidentiality or privacy, like credit card numbers left out in the open.
“The first couple of technologies that we’ve integrated with are antivirus scanning and image recognition.”
Anand Ganesh, at 17:00
The antivirus scan writes back whether the file is a threat and what it found. Image recognition writes back labels. A DLP tool can say whether the file holds data covered by laws like HIPAA or SOX.
Then the objective does the enforcement, with no separate workflow.
“you can put objectives further on that derived metadata to say, if the file is found to be a threat, or if this image contains material that is inappropriate or whatnot, prevent access to the content of that file, right?”
Anand Ganesh, at 18:08
That closes the loop from the quarantine problem. The file isn’t moved anywhere. Its metadata changes, and access to its content stops, in place, with its lineage intact. In March 2026 Hammerspace and Secuvy announced an integration that lets the two “continuously discover, classify, catalog, and control” unstructured data in one global namespace, warning that “when data is duplicated across systems, governance breaks down” (Hammerspace). It’s the same idea five years later.
Keys from your own HSM
Anand came back to bring your own keys, this time with the plumbing.
“get access to your key management system or your on-premises hardware security module, get the keys, encrypt the data so that while it’s sitting on your storage container at rest, it’s protected.”
Anand Ganesh, at 18:55
A hardware security module is “a physical computing device that safeguards and manages secrets” (Wikipedia). Jon played it back as keys from an HSM, encryption in the Hammerspace layer, and a DLP tool still running through the functions, and Anand confirmed it. The key management layer was built to be generic, he said, so a cloud key management service from AWS or Google, or your own HSM, plugs into the same place, and a simple password option was under consideration for people who wanted basic security without those systems.
“it is going in as plain text on one side and it’s getting spit out as ciphertext on the other side before it sits on your storage layer.”
Anand Ganesh, at 20:37
In March 2026 Hammerspace announced FIPS 140-3 validated cryptography for encrypting data in flight and at rest, with integration into the platform “planned for an upcoming release by the end of 2026” (Hammerspace). FIPS 140-3 is the U.S. government standard for approving cryptographic modules, first published on March 22, 2019 (Wikipedia).
Up the stack
Jon zoomed out to how data security has moved over the years.
“First, there’s TLS, just protecting our data as it moves across the network. And now there’s all of this really great work with encrypting at rest, so protecting our data with encryption as it rests on a persistence layer.”
Jon McLachlan, at 20:52
Transport Layer Security covers data in transit. Encryption at rest covers the disk. The next step, Jon said, is the application.
“And if we continue that trend, we go up the stack. Like, eventually we’ll see full end-to-end encryption, where we’re inside applications, encrypting perhaps data inside applications.”
Jon McLachlan, at 21:26
Anand agreed, and said that’s why he liked what Jon was building at Peacemakr.
“I think the holy grail is really making sure that the data is not present in plain text anywhere between the app that is working with the data and where it’s at rest on the storage layer.”
Anand Ganesh, at 21:43
End-to-end encryption is usually discussed for messaging. Anand was describing the same idea for stored data, where only the application that uses the data ever sees it in the clear.
A losing battle
His reason was the data breaches that had happened at public cloud vendors. The data sits under layers of systems, and every one of them has to be configured right, all the time.
“But that is, in my opinion, just a losing battle, because how many of these systems will you protect, right?”
Anand Ganesh, at 22:25
Server-side encryption doesn’t fix that, in his view, because a break in the permissions model gets the attacker data that’s decrypted for them automatically.
“It should only be decrypted by the keys that are securely in your pocket.”
Anand Ganesh, at 22:53
Jon took the compliment for Peacemakr and added a layer of his own.
“Though I do think of security in terms of layers”
Jon McLachlan, at 23:24
A solid encryption layer at rest, across a distributed system with its keys managed, is one of those layers, and application encryption is the next step up. His phrase for the whole effort: “a journey, not a destination.”
The open bucket
Jon gave an example of the kind of breach Anand meant, at a technology company providing healthcare and patient records management services.
“They had a Microsoft Azure bucket. It was open to the internet, had 100,000 or so files in it, just readable from the internet.”
Jon McLachlan, at 24:08
The fix he pointed to wasn’t a better bucket setting.
“If there was an application that was referencing that data that had encrypted everything, right? There’s your protection right there.”
Jon McLachlan, at 24:17
Anand’s answer was that there wouldn’t have been an exposure. A Microsoft Azure storage container left readable is a misconfiguration in exactly the kind of system on top of the data that Anand said can’t all be kept right. Encryption that the application controls turns that mistake into a pile of ciphertext.
Who do you have to trust?
Then Jon widened it from mistakes to people.
“That’s just one example of a misconfiguration. But if you have an insider threat, do we trust the vendors that are providing us these services?”
Jon McLachlan, at 24:31
An insider threat comes from “people within the organization, such as employees, former employees, contractors or business associates” (Wikipedia), and for data in someone else’s cloud the insiders include the provider’s. Jon asked the question about AWS, and about Hammerspace itself.
“we shouldn’t be forced into a position where we have to trust other people’s systems in order to be able to build interesting services that are secure.”
Jon McLachlan, at 24:46
Bringing your own keys was his answer for the storage layer, and Anand put it in one line.
“Exactly, because it’s your key, and you know that if you block access to the HSM, nobody can access your data through Hammerspace, right?”
Anand Ganesh, at 25:06
Delete what decrypts it
Jon saw a second use for the same keys.
“And that’s actually a nice way to delete data, too, right?”
Jon McLachlan, at 25:18
If the key reaches the end of its rotation and gets thrown away under your key lifecycle policy, the data still sitting in Hammerspace’s distributed systems can’t be read by anyone, Hammerspace included.
“Yeah, you’ve logically deleted your data.”
Anand Ganesh, at 25:42
That’s crypto-shredding, the practice of “rendering encrypted data unusable by deliberately deleting or overwriting the encryption keys” (Wikipedia). Anand said some customers had asked about it, because retention rules cut both ways. Laws make you keep some data for a set time, a legal hold can stretch that out, and once the time is up the data is a liability.
Hammerspace’s version works at the level of the file.
“if your IV or your salt that you’re using for encryption sits with the metadata layer, you rm the file from the namespace and you have lost, you’ve made it impossible for somebody to go and decrypt your content, right?”
Anand Ganesh, at 26:16
An initialization vector and a salt are the extra random inputs a cipher or a key derivation uses alongside the key. How much removing them protects depends on the cipher mode and on how the keys are derived, which the episode doesn’t go into, so treat this as the design idea and ask your vendor for the details. The reason it matters is the storage underneath.
“And our deletion of data on the storage layer is lazy, because we sometimes will run a background job to go and whack things that are not referenced in the namespace anymore”
Anand Ganesh, at 26:44
With deduplication and data sharing, the bytes of a deleted file can outlive the delete. Tying the delete to the decryption closes that gap.
“as soon as you remove it from the namespace, you’ve lost all capability to decrypt what’s on your storage.”
Anand Ganesh, at 26:59
Jon called it an important feature that often gets overlooked, especially in financial services, where firms must keep records for a set period, after which the records turn into a liability.
“I like how easy it is to securely delete data in that system.”
Jon McLachlan, at 27:06
Any site, any infrastructure
Jon closed by asking what comes next for Hammerspace. Anand’s answer came from the moment. People were working from home and spread across the planet, and he expected that to last beyond the pandemic.
“it’s super important that your data is available where you are.”
Anand Ganesh, at 28:12
The global file system is the answer to that, with objectives doing the delivery, like new data sent overnight to colleagues at another site in a follow-the-sun workflow, where work is handed to the next time zone at the end of each day (Wikipedia). The namespace itself, he added, is decoupled.
“It’s decoupled, which means if one of your sites goes down, all the other sites continue to work as is, as if they were not replicated.”
Anand Ganesh, at 29:01
His summary of the goal fit in four words.
“So, any site, any infrastructure is what we’re aiming for”
Anand Ganesh, at 29:19
What happened after the tape
When we recorded. This was the first episode of the show, recorded during the pandemic Anand mentioned and published on May 6, 2021, when remote work was the daily routine for many listeners.
The AI data platform. By 2026 Hammerspace described itself as a data platform for AI. In March 2026 it launched an AI Data Platform built on an NVIDIA reference design, and David Flynn’s line on the launch was that it works on data where it already is, “without forcing enterprises into a copy-first AI silo” (X). The argument against copies that Anand made about permissions in 2021 became the argument against copying data into AI storage.
@Hammerspace_Inc Launches AI Data Platform Based on @nvidia Reference Design, Enabling AI Anywhere
Hammerspace (@Hammerspace_Inc) · March 16, 2026
The Hammerspace AIDP meets enterprises where they are by allowing them to start making their existing data AI-ready using the infrastructure they already own, without deploying a separate AI storage system. By uniquely leveraging data in place, Hammerspace eliminates the need to purchase massive amounts of new flash just to house AI data.
The security features. The March 31, 2026 announcement of FIPS 140-3 validated cryptography lists encryption in flight and at rest, immutable snapshots, centralized policy enforcement across the global namespace, and “Consistent access policies across file and object data, spanning NFS, SMB and S3” (Hammerspace). Most of the list is the episode’s agenda, five years on.
The metadata, protected. Hammerspace’s white paper on protecting data and metadata, last updated May 28, 2026, describes the backup half of the episode in detail, from synchronous mirroring between Anvils to an export that rebuilds the file system without the platform (Hammerspace).
The company. In April 2026 Hammerspace reported year-to-date bookings of nearly 14 times its full-year 2025 bookings, and in October it hired a sales leader for the Americas (Hammerspace). Those are the company’s own figures.
The part of the conversation that aged best is the plainest. Every copy of a file is another place to get the permissions wrong, another system to recover, and another place the bytes outlive a delete. One file, governed in one place and encrypted with a key you hold, is the version of that problem you can actually manage.
Did you catch it? A six-question quiz
Six questions from the episode. Each answer links the moment in the transcript.
Quiz · six questions
Did you catch it?
Pick an answer for each. The explanation shows once you choose.
-
What are the two parts of the Hammerspace platform?
- The Anvil and the DSX
- The hammer and the forge
- The vault and the gateway
a. "One is what we call the Anvil, and the other one is the DSX." Transcript, 1:53.
-
Why doesn't Hammerspace add a hop to every read and write?
- It caches all of your data
- It compresses the traffic
- It sits on the side, and clients talk to the storage directly
c. "we sort of sit on the side, if you will, where we just allow your clients to talk directly to the data server." Transcript, 2:25.
-
What does moving a flagged file to a quarantine server cost you, in Anand's telling?
- Disk space
- Its lineage and its ownership
- Its encryption
b. "Now you've made the problem even worse, because you've lost lineage" Transcript, 6:07.
-
Why doesn't losing a site start a failover?
- Every site is active, so you mount from another one
- The backups restore overnight
- Replication reverses on its own
a. "So one site goes down, boom, you just mount from another site and continue." Transcript, 15:12.
-
What do the first functions Hammerspace integrated with write back to a file?
- A compressed copy
- Metadata, like a threat verdict or image labels
- A new encryption key
b. "The first couple of technologies that we've integrated with are antivirus scanning and image recognition." Transcript, 17:00.
-
How does removing a file from the namespace delete it, even before the storage cleans up?
- It overwrites every block at once
- It tells the storage administrator
- What's needed to decrypt it lives in the metadata
c. "as soon as you remove it from the namespace, you've lost all capability to decrypt what's on your storage." Transcript, 26:59.
Is your data one file or many?
Anand’s argument was that every copy is another place to secure, recover and delete. Eight questions on how many places your data really lives.
Scorecard · eight questions
Is your data one file or many?
Answer for your most important data as it's run today. If two answers fit, pick the lower one.
-
Can you take one recovery point that's consistent across every storage system your data lives on?
- No
- Per system, lined up by hand
- Yes, one snapshot or one tested procedure
"you're taking a sort of a point-in-time snapshot of all this data across all these storage systems." See Share-level snapshots.
-
Who holds the keys that encrypt your data at rest?
- The storage or cloud provider
- We do, for some systems
- We do, from our own key service or HSM, for all of it
"You usually cannot do sort of BYOK, bring your own keys, with traditional storage." See Bring your own keys.
-
When a site goes down, how do people get back to their files?
- We restore from backup
- We run a failover runbook
- They mount from another live site
"So one site goes down, boom, you just mount from another site and continue." See Active-active is the disaster recovery.
-
Can people restore a file they deleted by mistake without opening a ticket?
- No
- With help from IT
- Yes, it's self-service
"you can just go into the undelete location under the share and sort of bring back the files." See Undelete, and ransomware.
-
How many places do you set permissions for the same data?
- Once per copy, by hand
- A few places, kept in step by scripts
- One place for every copy
"you have your permissions model, and you have to make sure you manage and lock down your permissions." See Every copy needs its own lock.
-
When a scan finds sensitive data out in the open, what happens to the file?
- Nothing automatic
- It gets moved to a quarantine server
- Access is blocked in place, lineage intact
"Now you've made the problem even worse, because you've lost lineage" See Quarantine loses the lineage.
-
Do your scanners write their results where a policy can act on them?
- No
- Into a separate console someone reads
- Into metadata a rule enforces
"you can plug in a certain piece of compute that can look at your data and derive additional metadata from it." See Functions that look at your data.
-
When retention ends, can you show the data is unreadable everywhere, copies and leftovers included?
- No
- For some systems
- Yes, because we destroy what decrypts it
"as soon as you remove it from the namespace, you've lost all capability to decrypt what's on your storage." See Delete what decrypts it.
Your data lives in many places and each one is run on its own. Pick one important dataset, map every copy, and put its permissions and its keys in one place first.
Some of it is governed in one place. Extend the same recovery point and the same keys to the systems still run by hand, and test a restore that touches all of them.
Most of your data is governed, recovered and encrypted as one. Keep proving it with restore drills across every system and a deletion you can show reached every copy.
How many hours do your copies cost?
What it takes to keep permissions in step when every dataset lives in more than one place. Change the numbers to your own.
Calculator
How many hours do your copies cost?
Four estimates: how many datasets carry their own permissions, how many copies of each you keep, how often their permissions change, and the minutes one change takes on one copy.
Keeping 600 permission edits a month in step across every copy takes 100 h. With one namespace and one set of permissions it would be 33 h, so the extra copies cost 67 h a month.
The defaults are examples, not measurements. Three copies echoes Anand's Australia, Europe and the United States in Every copy needs its own lock, and the rest are round numbers. The hours don't count the cost of getting one copy wrong, which is the part Anand worried about. Hammerspace sells the single-namespace approach, so time your own changes before you decide.
From a cartoon to FIPS 140-3
Everything on this page sits on one timeline, from a 1943 cartoon to Hammerspace’s validated cryptography. Filter it by thread.
Timeline · 1943 to 2026
From a cartoon to FIPS 140-3
Filter by thread. Dates are from the public record except where marked as part of this show.
- What's Buzzin' Buzzard?
Tex Avery's vulture pulls a kitchen's worth of appliances out of thin air, long before anyone called that hammerspace (Wikipedia).
- NFSv3
RFC 1813 publishes version 3 of the Network File System (Wikipedia, on this show).
- Fusion-io
David Flynn and Rick White found the flash memory company, first named Canvas Technologies (Wikipedia).
- pNFS
NFS version 4.1, RFC 5661, adds parallel access that separates the metadata from the data (Wikipedia, on this show).
- SanDisk
SanDisk announces its plan to buy Fusion-io (Wikipedia).
- AWS Lambda
Amazon introduces functions that run code in response to events (Wikipedia, on this show).
- Hammerspace
The company lists 2018 as its founding year (LinkedIn).
- RFC 8435
The pNFS Flexible File Layout, by two authors at Hammerspace (RFC Editor, on this show).
- Peacemakr
Jon co-founds Peacemakr (LinkedIn, on this show).
- FIPS 140-3
The U.S. government standard for cryptographic modules is first published, superseding FIPS 140-2 (Wikipedia).
- Episode 1
Jon and Anand's conversation, recorded during the pandemic, airs as the show's first episode (transcript, on this show).
- The companion post
Our post on immutable backups and ransomware recovery draws on the episode (YSecurity).
- Secuvy
An integration to discover, classify and control data without duplicating it (Hammerspace, on this show).
- AI Data Platform
Hammerspace launches a data platform for AI built on an NVIDIA reference design (X, on this show).
- Validated cryptography
FIPS 140-3 validation, with integration into the platform planned by the end of 2026 (Hammerspace, on this show).
- Bookings
Year-to-date bookings of nearly 14 times full-year 2025, by the company's count (Hammerspace).
- The white paper
Hammerspace's paper on protecting data and metadata is last updated (Hammerspace, on this show).
- Americas sales
Hammerspace names a new sales leader for the Americas (Hammerspace).
What to do this week
Five things, in the order Anand’s argument suggests.
- Map where one dataset really lives. Pick your most important one, list every copy on every system and site, and count the places its permissions are set. The calculator above shows what each extra copy costs to keep in step.
- Restore from one point in time, across all of it. Take a recovery point and bring the whole dataset back, end to end, on every system it touches. Time it, and write down what had to be lined up by hand.
- Find out who holds your keys. For each place that dataset sits, note whether the provider or you control the key that encrypts it at rest, and move the important ones to a key service or HSM you run.
- Block in place instead of moving to quarantine. Pick one scanner, antivirus or DLP, and wire its verdict to a rule that stops access to the file where it is, so its owner and history stay attached.
- Prove one deletion reached every copy. Write down how you’d make retired data unreadable everywhere, copies and storage leftovers included, and try it on something small. The scorecard above shows where else you stand. If you’d like a hand with any of it, our vCISO team can help, and you can book 15 minutes with us.