ActiveCluster for File Veeam Backup
Hello everyone :-) we recently got a Flasharray with the new "ActiveCluster for File" feature, which is pretty nice. We are trying to switch to Veeam. We are using VMware. I therfore created a Linux based Veeam Backup & Replication Server as well as linux based proxies in our vCenter. Backing up VMs via the hot-add transport mode works without any issues. The issue that we are facing is, how do we backup the NFS shares created from the "ActiveCluster for File"? Because Veeam sees the VMDKs from the VMs in the vCenter but doesen't see the NFS mounts from Everpure in the guest OS of the VM. My questions and thoughts are: Is it possible to create an physical Linux based on Veeam proxy and connected it to the Everpure FlashArray? According to this link, Everpure doesn't support the storage snapshot Integration feature https://helpcenter.veeam.com/docs/vbr/userguide/storage_system_requirements.html?ver=13 This is the Plugin I wanted to use with the physical proxy which is connected to the FlashArray https://www.veeam.com/kb4129 I can add the NFS Share into Veeam and create backjobs but how does it technically work? It uses the VBR Server as an proxy.. But is that the right way? How can I create Veeam backup jobs for NFS mounts (which are mounted on VMs in the vCenter, which Veeam doesn't see) provided by ActiveCluster for File ? How does a Veeam file share backup work technically and how should the recommended backup design be in this scenario? Thank you!Calling all public servants!
Did you know Evepure has a Public Sector community? Come talk shop with fellow federal, state and local govies, education leaders, and partners who get it. We're talking long procurement and CR-driven buying cycles, figuring out where AI actually fits when your data is spread across different systems, all amid election cycles and shifting political priorities. purecommunity.purestorage.com/group/public-sector If you're a customer or partner, would love to see you there! Leave a comment if you're interested and we'll get you set up.
Get rid of stressful infrastructure headaches. Everpure Fusion handles your data, autonomously.
It happens! It's 11:45 PM on a Friday. An alert fires and storage latency has spiked across a production workload. The operator digs in and traces it back to an automated tiering policy that quietly moved a hot dataset to a slower tier because it looked idle based on a 24-hour access window, right before a scheduled batch job that runs every weekend. Nobody changed anything. The policy did exactly what it was configured to do. But nobody remembers configuring it that way, the documentation hasn't been touched in two years, and the monitoring dashboard shows storage as "healthy" because utilization is fine. It's just in the wrong place. The operator overrides the tier, performance recovers, and spends the next hour writing an incident report for a problem that shouldn't exist. A system that was supposed to make life easier made a decision with no context, no warning, and no visibility into why. That's the anger that doesn't go away quickly. It's not just frustration at the incident. It's the feeling that the tools are working against you instead of with you. The core problem in that story was a system making decisions with no context, no warning, and no visibility. Everpure Fusion attacks each of those problems: Unified visibility across the entire fleet: Everpure Fusion provides a global dataset as a single source of truth for discovery, management, and configuration of storage arrays so the operator isn't piecing together what happened across multiple dashboards, multiple arrays, multiple tickets after the fact. They see the full picture in one place, before things go wrong. Intelligent workload placement: Rather than static policies quietly acting on stale access patterns, Everpure Fusion uses AI-guided placement to boost performance and efficiency for every workload. It understands workload behavior, not just utilization snapshots, the kind of context that would have caught a batch job pattern before tiering the dataset down. Policy-driven governance with real control: Automated orchestration cuts manual tasks and speeds service delivery, while unified controls simplify audits, reduce risk, and prove compliance fast. Policies are visible, documented, and governable. Not buried configs nobody remembers setting. Built into the platform, not bolted on: Evepure Fusion is now simply a part of Purity, meaning it is not an add-on you have to install or buy, but rather a core piece of the Purity operating system. The operator doesn't have to manage another tool. The intelligence is already there. The operator in that story didn't need more alerts. They needed a system that understood context, made decisions transparently, and gave them control without requiring them to be online at midnight to maintain it. That's exactly the gap Everpure Fusion is designed to close - with One Fleet, Zero Complexity. Why policy-driven storage operations matter Everpure Fusion is built as the core of Everpure intelligent control plane that manages all arrays including FlashArray, FlashBlade, and cloud as a unified fleet, with one topology, one API, and one operational framework regardless of protocol or local - datacenter, cloud or edge. That uniformity is what makes policy enforcement reliable at scale. Everpure Fusion introduces workload-based provisioning through presets, which are predefined policy-driven templates for specific workload types, encoding protection policies, replication, and SafeMode retention from the moment a workload is provisioned, not patched in after an incident. Admins no longer need to pre-plan and tune deployments manually, which reduces the risk of non-compliance and improves resiliency by ensuring workloads are provisioned correctly from the beginning. The result is infrastructure that enforces your intent, not just your last manual action. Intelligent placement, rebalancing, and fleet-scale capacity control If you manage storage at scale, you've probably seen this scenario play out more than once. One array is buried, running hot, and screaming for relief. Three aisles over, another array is sitting at 40% utilization, doing almost nothing. And somewhere in between, your team is scrambling to provision capacity, kick off an emergency migration, and explain to stakeholders why an SLA was missed on a workload that, in hindsight, never should have been placed there in the first place. This is not a people problem. It is a tooling problem. And it is remarkably common. Everpure Fusion starts solving this problem at the moment of provisioning. When a new workload lands, most storage systems do a simple capacity check and place it wherever space is available. Everpure Fusion does something fundamentally different. The placement engine evaluates every array in the fleet simultaneously, looking at IOPS headroom, throughput capacity, and physical utilization before making a decision. The goal is not just to find somewhere to put the workload. It is to find the right home for it, one where it can live comfortably for the long term without creating a bottleneck down the road. Think of it as placing workloads with intention rather than convenience. Of course, environments do not stay static. Workloads grow, usage patterns shift, and an array that looked healthy six months ago can become a problem today. Everpure Fusion accounts for this with continuous rebalancing built directly into its operation. When an array starts trending toward overload, Everpure Fusion detects it and begins orchestrating data movement across the fleet automatically. No manual intervention required. No application downtime. Data migrates in the background while workloads keep running, and arrays that were sitting underutilized suddenly become productive members of your infrastructure. At fleet scale, now supporting up to 64 arrays, this turns capacity management from a constant firefight into something that largely runs itself. What makes this possible without disruption is how Everpure Fusion executes the move under the hood. It leverages ActiveCluster to stretch the volume across both the source and target arrays simultaneously, creating a synchronous mirror in place. Once the stretch is established, volumes are connected on the target array and hosts auto-discover the new target paths through standard multipathing. The target then validates that path usage is healthy and confirmed before any cutover begins. Only after that validation is complete are the volumes disconnected from the source, ensuring there is zero gap in access at any point in the sequence. Everpure Fusion then unstretches from the source array to complete the rebalance and release its capacity. The result is a seamless, non-disruptive migration that the application never sees. What truly sets Everpure Fusion apart from a standard load balancer is what happens under the hood. Powered by Pure1 AI and up to 30 days of historical workload data, Everpure Fusion does not just look at what is happening right now. It looks at what is about to happen. Say you have a workload that runs a heavy batch job every Saturday night. Everpure Fusion knows that. It has seen the pattern. So when the placement engine is evaluating tier assignments, it will never recommend moving that workload to a lower-performance tier just because it looks quiet on a Tuesday afternoon. It understands what Tuesday quiet actually means in context. And if that workload somehow ends up on the wrong tier, perhaps through a manual change or a migration gone sideways, Everpure Fusion will proactively raise a violation before the weekend arrives. Not after the SLA is missed. Before. The cumulative effect is that customers can operate their fleets closer to full utilization without the anxiety that normally comes with it. Underused hardware gets activated, incremental purchases get deferred, and the reactive, always-behind-the-curve model of capacity management starts to look like a problem from a previous era. And Everpure Fusion does not stop at the infrastructure layer. Through its integration with Pure1 Application Intelligence, Everpure Fusion gains deeper visibility into the nature of the workloads themselves, not just how they behave, but what they actually are. That additional context means smarter decisions at every level, from initial placement to long-term tier management, grounded in a more complete picture of what your environment is really doing. Workload rebalance and mobility will be available towards the end of 2026. Compliance as part of the control plane Most storage compliance workflows follow the same pattern: an audit is announced, someone pulls reports from three different tools, cross-references configuration against a spreadsheet of expected settings, and spends two weeks proving that workloads are protected the way they're supposed to be. Then the audit ends and nothing changes until the next one. That model breaks at fleet scale. When you're managing dozens of arrays across multiple sites and protocols, manual audits don't just slow you down — they leave gaps that only get discovered at the worst possible time. Everpure Fusion Compliance is built into the control plane, not bolted on after provisioning. Because Everpure Fusion presets encode protection policies, replication requirements, SafeMode retention, and QoS settings at deployment time, Everpure Fusion always knows what every workload's intended configuration is. Drift detection is continuous — not periodic. When a workload deviates from its preset, Everpure Fusion instantly surfaces the violation — visible in the UI, queryable via API or CLI, and accessible to AI agents through an MCP server. Remediation can be triggered directly through the same interfaces, without pulling in a separate tool or writing a custom script. Fleet-wide compliance dashboards give storage admins a live view of posture across every array, with exportable audit-ready reports that don't require manual assembly. The shift is meaningful: compliance becomes a property of how the fleet operates, not a project that interrupts how the team works. Everpure Fusion Compliance will be available towards the end of 2026. From dashboards and scripts to natural-language fleet operations You know the drill. A latency spike hits production. You open three dashboards, run a handful of CLI queries, dig through alert logs, and piece together enough context to understand what happened — and by then, you've already spent 45 minutes on a problem that should have taken five. The issue isn't the tools. It's that the context your fleet holds is trapped across systems that don't talk to each other. Everpure Fusion MCP Server changes that. Built on the open Model Context Protocol standard, it connects any MCP-compatible AI assistant — Claude, ChatGPT, Copilot, or internal agents — directly to live Everpure Fusion fleet state. Arrays, workloads, capacity, performance metrics, alert history, configuration, and placement data are normalized into clean, structured JSON and made available to AI in real time, pulled directly from Everpure Fusion and Purity REST APIs. The result: instead of navigating dashboards and stitching together CLI output, you ask a question. "Which arrays are approaching capacity?" "What's driving latency on this workload?" "Which workloads are drifting from their preset?" Everpure Fusion MCP Server answers from live fleet context, not stale snapshots. This is the on-ramp to agentic storage operations. Everpure Fusion already enforces policy and placement across the fleet. Pure1 adds AI-driven analytics and recommendations on top. Together, they give infrastructure operators the foundation to move from reactive troubleshooting to intent-driven, increasingly autonomous fleet management. Using topology groups to encode real infrastructure boundaries If your Everpure Fusion fleet's topology model lives in a color-coded spreadsheet, three wikis, and the institutional memory of one senior admin who never takes vacation — this is for you. Everpure Fusion, built into Purity for FlashArray and FlashBlade, introduces Topology Groups: fleet-scoped objects that let you describe your arrays in the same language your architecture diagrams already use — regions, availability zones, datacenters, rows, racks. No more provisioning a Everpure Fusion workload and hoping it lands in the right building. A Everpure Fusion Topology Group is a hierarchical, tree-structured object. Groups nest up to 10 levels deep (global → us-east → az-us-east-1a → dc01 → row3 → rack12), each array belongs to exactly one parent, and cycles are rejected at write time. Critically, they encode placement semantics — not access control. RBAC stays in Pure1 Resource Groups; topology stays in Everpure Fusion topology. Once modeled, Everpure Fusion presets reference groups using <group>.arrays notation. Everpure Fusion intersects the preset's allowed arrays with the group's membership at placement time. If there's no overlap, Everpure Fusion provisioning fails fast with a clear error — not silently in the wrong zone. The Everpure Fusion CLI shorthand makes automation clean: purevol list --context az-us-east-1a.arrays Everpure Fusion membership changes propagate automatically across the fleet. You stop maintaining a second source of truth outside the control plane. Stop treating topology as tribal knowledge. With Everpure Fusion, make it a first-class part of the intelligent control plane. Extending the model to Kubernetes and virtualization Most infrastructure operators are managing two parallel storage worlds right now: traditional VMs and databases on one side, Kubernetes-based containerized workloads on the other. Separate toolchains. Separate provisioning workflows. Separate everything. Everpure Fusion changes that. Through the Portworx Fusion Controller, Everpure Fusion extends its policy and placement control plane directly into Kubernetes — without forcing developers to change their existing workflows. Everpure Fusion auto-discovers your FlashArray and FlashBlade fleet, then exposes Everpure Fusion presets as native Kubernetes StorageClasses. That means when a developer requests a persistent volume, Everpure Fusion's placement engine resolves it against your existing policy constraints — storage class, protection policy, topology group, replication requirements — the same way it does for any other Everpure Fusion workload. No separate control plane for modern environments. No array-by-array configuration for each cluster. New arrays added to the fleet are automatically discovered and configured, so the operational model stays consistent as infrastructure grows. For VMware environments, Everpure Fusion extends the same operational model through the Everpure Fusion vSphere plugin, connecting storage management directly into virtualization workflows instead of running it as a separate administrative domain. The result: one control plane, one set of policies, one placement engine — spanning VMs, containers, and databases across the fleet. That is fewer parallel stacks to operate, less configuration drift between environments, and a more scalable path to consistent storage operations across the full infrastructure stack. Everpure Fusion as the storage admin foundation for autonomous operations The through-line across everything covered in this blog is simple: Everpure Fusion gives infrastructure operators a unified, policy-driven control plane that enforces intent consistently — across provisioning, placement, compliance, topology, and now Kubernetes and virtualization. That foundation matters because autonomous storage operations do not start with AI. They start with structure. Topology groups encode where workloads belong. Presets encode how they should be configured. Everpure Fusion presets exposed as StorageClasses ensure Kubernetes environments follow the same rules as everything else. When that structure is in place, AI can recommend, optimize, and eventually act — because the context is already clean, trusted, and machine-readable. For storage admins, the shift is real: less time resolving incidents caused by placement decisions nobody remembers making, more time defining the intent that governs the fleet. Everpure Fusion is that foundation — built into Purity, not bolted on. Want to learn more about Everpure Fusion? Check out the following links to dive deeper: Join the Everpure Fusion Mastery Program to build expertise, complete hands-on activities and earn rewards. Sign up for a Fusion test drive to try it out on your own time. Check out more about Fusion product details. Watch our cool new Fusion demo videos. Read Everpure Fusion Datasheet"Where’s Waldo?", But for your Data
This past Saturday, my wife and I sat at my son’s college graduation ceremony doing what every proud parent does after running out of tears and tissues: staring at the giant screen, scanning a crowd of thousands, and playing a very emotional, very expensive version of Where’s Waldo? The camera pulled back and showed the graduating class. Thousands of caps. Thousands of gowns. Thousands of people who had just survived exams, group projects, late-night studying, bad cafeteria decisions, emotional phone calls home, and whatever personal version of “I’ll start the paper tomorrow” they subscribed to. Somewhere in that sea of mostly identical academic robes was my son. I knew he was there. We had dropped him off at college years earlier, paid tuition, bought supplies, endured move-in day, survived the separation anxiety, worried about him, cheered for him, and occasionally pretended to be calmer than we actually were. I knew exactly why we were in that room. But on that screen, in that moment, he was just one face among thousands. So I started searching for him. Every parent around me was probably doing some version of the same thing. We were not looking at a graduating class in the abstract. We were looking for our graduate. Everyone else on that screen mattered deeply to someone, but to us they were mostly context without identity: a massive, moving, emotional dataset with almost no metadata attached. That was the strange thing about the picture. It showed us everything and told us almost nothing. There were thousands of people on the screen, but unless you already knew who you were looking for, you did not really know what you were looking at. Somewhere between the pride, the camera angle, and my increasingly poor performance at parental facial recognition, my brain did what my brain unfortunately does. It connected a very human moment to the way enterprises think about data. Because this is exactly the problem most organizations have with their data. They know it is there. They know there is a lot of it. They know some of it is incredibly valuable, some of it is probably risky, and some of it is duplicated, outdated, forgotten, regulated, misplaced, or being accessed by people and systems nobody has thought about in years. But knowing there is a crowd is not the same thing as knowing who is in it. That is the part we do not talk about enough. For years, data management conversations were mostly about where the data lived, how it was protected, how fast it could be accessed, and how much it cost to keep it all running. Those things still matter. They will always matter. But they are no longer enough. The new question is not simply, “Where is the data?” The better question is, “What is this data, who does it belong to, why does it exist, who is using it, where has it moved, what risk does it carry, and should this AI model, business process, analyst, application, or employee be touching it at all?” That is a very different conversation, and that is why 1touch matters. Not because the industry needed one more product logo, one more acronym, or one more keynote phrase that sounds important until everyone quietly admits they are not exactly sure what it means. 1touch matters because it is aimed directly at the problem of not knowing. The lie of visibility Most organizations believe they have visibility into their data because they have tools that can show them infrastructure. They can show arrays, volumes, file systems, buckets, databases, dashboards, latency charts, replication status, backup jobs, snapshots, anomalies, alerts, and the occasional red icon that ruins someone’s morning. All of that is useful. None of it guarantees understanding. An IT team can tell you a volume is 87 percent full, but that does not mean they know it contains expired customer records, old HR exports, forgotten underwriting files, production data copied into a test environment, or a spreadsheet with 40,000 Social Security numbers created in 2018 by someone who left the company three reorganizations ago. A security team can tell you an alert fired, but that does not mean they know whether it represents real exposure, a false positive, or just another noisy event in a pile nobody has enough hours to investigate. A data team can point to a lake, a warehouse, a catalog, and a governance process, but that does not mean the data is clean, trusted, current, properly classified, or safe to feed into an AI workflow. This is the uncomfortable truth: enterprise data visibility has often meant visibility into containers, not contents. We could see the auditorium. We could count the very uncomfortable seats. But we still could not tell which graduate was my son. The graduation screen was not useless. It showed scale. It proved the event was real. It helped me understand the crowd. But until I could identify the person I cared about, the picture was incomplete. Enterprise data estates work the same way. The problem is not that organizations have no tools. They often have too many. The problem is that many tools see the surface of the environment but miss the identity, relationship, movement, and meaning of the data inside it. That gap was inconvenient in the old world. In the AI world, it is dangerous. AI does not forgive ignorance Before generative AI entered every boardroom conversation, the consequences of not knowing your data were already serious: compliance exposure, bloated infrastructure costs, security blind spots, slow audits, manual discovery, painful legal requests, cloud migration delays, and business users waiting weeks for access to information because nobody could confidently say what was safe to use. Then AI showed up and made the problem louder. AI feeds on data. Lots of it. Structured data, unstructured data, documents, emails, transcripts, PDFs, customer records, logs, knowledge bases, support case histories, SaaS exports, file shares, objects, and anything else that might help a model answer a question, summarize a situation, automate a workflow, or make a decision. That sounds exciting until you remember that most enterprises do not fully know what is in all of those places. And AI is not magic. If the input is wrong, the output inherits that problem. Sometimes the model hallucinates. Sometimes it exposes something it should not. Sometimes it makes a recommendation based on data that was never supposed to leave a specific jurisdiction. Sometimes it answers confidently from a document that was obsolete three policies ago. Sometimes it gives the right answer to the wrong person, which may be the scariest version of all because the technology can look like it is working while quietly violating the trust model of the business. That is why “AI-ready data” cannot simply mean “we pointed a model at a repository.” That is not readiness. That is hope with an API call. AI-ready data needs context. It needs classification, identity, policy, and confidence. It needs a way to distinguish between a harmless document, a restricted record, a regulated attribute, an exposed credential, and a data fragment that only becomes sensitive when connected to other fragments somewhere else. A number or a name by itself may not mean much. A location, transaction, or timestamp by itself may not mean much either. But connect the number to the name, the name to the patient record, the patient record to a geography, the geography to a regulation, the regulation to a storage location, and the storage location to an access path, and suddenly you are not looking at random data anymore. You are looking at risk. Or value. Often both. This is where 1touch becomes important, because its value is not just identifying patterns and sticking labels on files. Its value is in discovering, classifying, and contextualizing data across environments so organizations can understand not only what exists, but what it means. That distinction matters. The difference between labeling and knowing At graduation, every student had the same basic label: graduate. That label was accurate, but it was wildly insufficient. One graduate may be heading to medical school. Another may be joining a startup. Another may be the first person in their family to earn a degree. Another may have worked two jobs to get there. Another may have changed majors three times and somehow still finished on time, which frankly deserves its own medal. The label tells you the category. The context tells you the story. Data works the same way. A traditional tool might identify something that looks like a credit card number, Social Security number, email address, medical code, account number, or passport field. That is useful, but it can also create noise. Strings of digits appear everywhere. Test data looks real. Real data looks fake. A file name can lie. A folder path can be misleading. A database column called “ID” might be harmless, or it might be the key to everything. Context is what turns a guess into intelligence. 1touch approaches this problem by looking at the broader semantic environment around the data. It is not just asking, “Does this pattern match something sensitive?” It is asking, “What surrounds it? What system did it come from? Who accesses it? Where does it move? What other data is connected to it? What business process does it support? What regulatory meaning does it carry?” That matters because in the real world, data risk rarely lives in a single isolated field. It lives in relationships. The same way my son was not immediately identifiable to the room because he was wearing a cap and gown like everyone else, sensitive enterprise data is often not obvious because it is dressed like everything else. It sits in file shares, databases, cloud repositories, SaaS platforms, mainframes, archives, exports, and forgotten project folders. It blends into the crowd. The old approach was to scan the crowd every so often and hope you recognized enough faces. The newer requirement is continuous understanding: discovering data where it lives, watching how it moves, connecting fragments across systems, and building a living map of identity, access, classification, and risk. Not a once-a-year inventory. Not a spreadsheet. Not a governance theater exercise where everyone nods in a meeting and then goes back to copying production data into development because the test system “needed something realistic.” A living map. That is the real promise. Why this matters The value of 1touch can be easy to undersell if we describe it only as sensitive data discovery or Data Security Posture Management (DSPM). Those descriptions may be accurate, but they are not the business problem. A prospect is not waking up hoping to buy a classification engine. They are waking up with pressure from the board, auditors, regulators, cyber insurers, application owners, AI initiatives, cloud migration teams, and business leaders who want faster access to “clean” data without increasing risk. And for those of us who have been around this industry long enough to have a few emotional support scars, this problem is not new. We were talking about lifecycle data management and data classification projects 20 years ago. Kazeon, StoredIQ, and others were all trying to help customers understand what was hiding inside their unstructured data environments before the phrase “dark data” became a fashionable way to describe a very unfashionable mess. I personally used Kazeon back in 2006, before EMC acquired it and eventually killed it. The idea was right. The experience was painful. I remember a project where it took almost two months to scan the environment, process the results, and prepare the report. We finally sat down with the customer, proudly showed them the findings from roughly 5TB of unstructured data, and waited for the moment where they would appreciate all the classification goodness we had brought into their lives. Instead, the customer looked at us and asked the only question that mattered: “Where is the rest of my 55TB?” There are moments in a technical meeting when the room temperature changes without the thermostat being involved. This was one of them. Apparently the tool did not have permissions to scan the rest of the environment. So after two months of work, the result was technically accurate and practically incomplete, which is the most dangerous kind of confidence. We had a report. We had charts. We had findings. What we did not have was the whole truth. That is why this matters now. The enterprise data problem did not begin with AI. AI simply made the consequences of incomplete understanding much harder to ignore. Twenty years ago, a bad classification project meant a frustrated customer, an awkward meeting, and a lot of manual cleanup. Today, the same kind of blind spot can contaminate an AI pipeline, expose regulated data, break a sovereignty policy, delay a migration, or give executives a false sense of security. For existing customers, the value is even more strategic. They already trust the platform to store, protect, move, and serve their data. The next logical question is whether it can help them understand the data as well. That is the bridge 1touch helps build. That is important because customers are tired of stitching together disconnected tools where one product sees storage, another sees identity, another sees security events, another sees data catalogs, another sees cloud posture, and another sees compliance workflows. Everyone sees something, but nobody sees enough. Customers do not need more fragmented visibility. They need connected context. Most importantly, it helps us explain why the conversation has moved from where data sits to what the data actually means. Back to the screen Eventually, during the ceremony, I found my son. Definitely when his name was announced and he walked across that stage. But the moment stayed with me because it was such a simple reminder: seeing a crowd is not the same as knowing the people in it. Every person on that screen had a story, a history, a family somewhere in the stands trying to yell the loudest, and a future that was about to begin. From a distance, they looked identical. Up close, they were anything but. Enterprise data is like that too. From a dashboard, it can look like capacity, files, objects, tables, volumes, buckets, repositories, shares, records, and logs. But inside that data are customer identities, patient histories, citizens tax records, contracts, intellectual property, employee information, business secrets, stale copies, duplicate exports, forgotten archives, useful insights, hidden risks, and the raw material for the next generation of AI-driven business processes. The organizations that win will not be the ones that simply store the most data. They will be the ones that know what their data means. That is why 1touch matters. Because the future of data management is not just finding Waldo. It is understanding the entire crowd. Appreciate you reading. Dmitry Gorbatov © 2025 Dmitry Gorbatov | #dmitrywashereNFS over TLS on FlashArray (Purity//FA 6.10.6)
Purity//FA 6.10.6 introduces NFS over TLS for FlashArray File Services: an in-transit encryption layer that wraps NFSv3 and NFSv4.1 RPC traffic in a TLS 1.3 session as defined by RFC 9289 - Towards Remote Procedure Call Encryption By Default. Server authentication is mandatory, and mutual TLS (mTLS) is available as an optional second factor. This post is a technical feature description plus a minimum viable configuration walkthrough. It assumes you are already comfortable with FlashArray File Services (file servers, exports, policies) and Linux NFS clients. What the feature actually is Transport encryption for NFS - NFSv3 and NFSv4.1 RPC traffic is carried inside a TLS 1.3 record layer over TCP/2049. No NFS-level changes; applications and mount paths stay the same. Server authentication - the FlashArray presents an X.509 certificate; the client validates it against its own trust store. Server certificates must include the file-server VIF in the SAN. Optional mTLS - the array can require and verify a client certificate against a configured trusted CA (single certificate or a certificate group). Per-server policy - TLS configuration is a first-class tls policy attached to a specific file server, not a global toggle. End-to-end data path NFS over TLS data path. tlshd on the client performs the TLS handshake against the FlashArray; the resulting session encrypts all consequent NFS traffic on established connection. Building blocks on the FlashArray The feature is exposed as a new tls policy type that ties together three existing concepts: certificates (imported or self-signed), the tls-policy object, and a file server. The policy holds the appliance certificate, the TLS version/cipher constraints, the protocols TLS is enforced for, and (optionally) the trusted CA used to authenticate clients. TLS versions and cipher suites NFS over TLS on FlashArray negotiates TLS 1.3 for the NFS data path. The tls-policy object accepts --minimum-tls-version values of 1.2 or 1.3 , but that minimum is a floor, not a contract - for NFS the negotiated version will always be 1.3. The default TLS 1.3 cipher set is: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 (mandatory per RFC 8446) On clients with AES-NI, TLS_AES_256_GCM_SHA384 is the natural choice. TLS_CHACHA20_POLY1305_SHA256 is the cipher to prefer on clients without AES hardware acceleration. NFS protocol versions and mount options Both NFSv3 and NFSv4.1 are supported. The Linux client opts into TLS at mount time via the xprtsec option, mediated by tlshd : Option Meaning xprtsec=tls One-way TLS, server authentication only xprtsec=mtls Mutual TLS - client also presents a certificate vers=4.1 / vers=3 NFS protocol version Prerequisites FlashArray: Purity//FA 6.10.6 or later, with at least one configured file server. Client OS: a recent Linux distribution with NFS-over-TLS support (e.g. Rocky Linux 10), including nfs-utils , tlshd and openssl (for certificate handling). Certificates: a server certificate signed by a CA the client trusts; if there is no proper DNS record set up, the certificate must include the file-server IP Address in its subjectAltName . For mTLS, a client certificate signed by a CA the array trusts. Configuration walkthrough This is the minimum sequence to land an encrypted NFS mount. Replace IPs, names and certificate paths to taste. If you don't yet have a CA to issue the server (and, for mTLS, client) certificate from, see the test-CA appendix at the end of this post. 1. FlashArray - import the appliance certificate # on the FlashArray CLI - interactive paste of key, then certificate purecert imported create nfs-server-cert --key # for mTLS only: import the CA used to sign client certificates purecert imported create nfs-client-ca 2. FlashArray - create a TLS policy Server-auth-only policy: purepolicy tls create nfs-tls-policy \ --appliance-certificate nfs-server-cert \ --tls-enforced-for nfs mTLS variant - require the client to present a certificate and verify it against a trusted CA (the trusted CA argument accepts either a single certificate or a certificate_group ): purepolicy tls create nfs-mtls-policy \ --appliance-certificate nfs-server-cert \ --tls-enforced-for nfs \ --client-certificates-required \ --client-certificate-trust-verify-enabled \ --trusted-client-ca-certificate nfs-client-ca Optional version / cipher tuning: purepolicy tls setattr nfs-tls-policy --minimum-tls-version 1.3 purepolicy tls setattr nfs-tls-policy \ --enabled-tls-ciphers TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256 purepolicy tls list --effective 3. FlashArray - attach the policy to a file server pureserver list purepolicy tls add nfs-tls-policy --server your-file-server purepolicy tls list --member Once the policy is attached, the file server starts requiring TLS for any new NFS connection on that VIF. Existing un-encrypted sessions are not renegotiated or dropped on policy change - clients must remount or restart their NFS service to pick up the new requirements. The same caveat applies when removing or rotating the trusted client CA. 4. FlashArray - create the export (unchanged from regular NFS) purefs create your-filesystem puredir create your-filesystem:your-managed-dir purepolicy nfs create your-nfs-policy purepolicy nfs rule add your-nfs-policy \ --client "*" --no-root-squash --rw --version nfsv3,nfsv4 puredir export create your-export \ --dir your-filesystem:your-managed-dir \ --policy your-nfs-policy \ --server your-file-server The export must live on the same file server that the TLS policy is attached to (note the --server argument). 5. Linux client - install and configure tlshd dnf install -y nfs-utils ktls-utils systemctl enable --now tlshd mkdir -p /etc/pki/nfs cp ca.crt /etc/pki/nfs/ca.crt chmod 644 /etc/pki/nfs/ca.crt Minimal /etc/tlshd.conf for server-only TLS: [debug] loglevel=1 tls=1 nl=0 [authenticate] [authenticate.client] x509.truststore=/etc/pki/nfs/ca.crt [authenticate.server] For mTLS, add the client identity: [authenticate.client] x509.certificate=/etc/pki/nfs/client.crt x509.private_key=/etc/pki/nfs/client.key x509.truststore=/etc/pki/nfs/ca.crt Restart tlshd after any change: systemctl restart tlshd . 6. Mount # server authentication only mount -t nfs -o vers=4.1,xprtsec=tls,rw \ 10.0.0.100:/your-export /mnt/nfs-tls # mutual TLS mount -t nfs -o vers=4.1,xprtsec=mtls,rw \ 10.0.0.100:/your-export /mnt/nfs-mtls # verify mount | grep xprtsec What the wire actually looks like Connection bring-up: AUTH_TLS probe per RFC 9289 → TLS 1.3 handshake brokered by tlshd → encrypted NFS traffic on the same TCP connection. Operational notes Policy changes are not retroactive. Tightening a policy (turning TLS on, switching to mTLS, removing a cipher in use) does not drop or renegotiate existing connections. Affected clients need to remount or restart NFS. Same applies to CA removal/expiry. Server certificate must carry the VIF in SAN. Without a matching subjectAltName entry the client refuses the certificate; common symptom is a mount failure with Protocol not supported and tlshd logging a verification error. NFSv4.1 connection reuse amortises the handshake cost across many operations; NFSv3 mounts re-do the handshake more often, so the relative cost is higher on connection churn. Troubleshooting cheat sheet Symptom Likely cause First thing to check mount.nfs: Connection refused Policy enforces TLS, client mounts plain NFS, or tlshd not running systemctl status tlshd ; add xprtsec=tls access denied by server while mounting mTLS client cert missing/untrusted, or export rule mismatch journalctl -u tlshd -n 100 ; puredir export list Protocol not supported Server certificate SAN does not include the mounted IP, or CA not trusted openssl x509 -in server.crt -text -noout | grep -A1 "Subject Alternative Name" Useful diagnostics on the client: journalctl -u tlshd -f sysctl -w sunrpc.rpc_debug=0x7fff sunrpc.nfs_debug=0x7fff tcpdump -i any -nn -v 'host <file-server-ip> and port 2049' -w /tmp/nfs-tls.pcap # remember to restore: sysctl -w sunrpc.rpc_debug=0 sunrpc.nfs_debug=0 Appendix: a throwaway CA for testing For lab and PoC work it is much more useful to stand up a tiny local CA than to hand out self-signed certs. The workflow mirrors what you would do with a real PKI - the array trusts a CA, that CA signs the appliance certificate, and (for mTLS) the same or a different CA signs each client certificate. Anything below is for non-production use; do not reuse these keys anywhere you care about. Set a couple of variables to keep the commands short: mkdir -p ~/nfs-tls-ca && cd ~/nfs-tls-ca VIP=10.0.0.100 # file-server VIP the client will mount FQDN=nfs.lab.example.com # optional DNS name for the same VIP CLIENT_CN=client01.lab.example.com # only needed for mTLS 1. Root CA # 4096-bit RSA root, valid 10 years openssl genrsa -out ca.key 4096 openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \ -subj "/CN=NFS-TLS Lab Root CA/O=Lab" \ -out ca.crt # inspect openssl x509 -in ca.crt -noout -subject -issuer -dates 2. Appliance (server) certificate The server certificate must include the file-server VIP in subjectAltName ; without it the client refuses the certificate during handshake. Add the FQDN as well if you have DNS for it. openssl genrsa -out server.key 2048 openssl req -new -key server.key \ -subj "/CN=${FQDN}/O=Lab" \ -addext "subjectAltName=DNS:${FQDN},IP:${VIP}" \ -out server.csr cat > server.ext <<EOF basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth subjectAltName = DNS:${FQDN},IP:${VIP} EOF openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -out server.crt -days 825 -sha256 -extfile server.ext # verify the chain and the SAN openssl verify -CAfile ca.crt server.crt openssl x509 -in server.crt -noout -ext subjectAltName Import this pair into the FlashArray as nfs-server-cert and reference it from the TLS policy as --appliance-certificate : # key first, then certificate, when prompted purecert imported create nfs-server-cert --key 3. Client certificate (mTLS only) openssl genrsa -out client.key 2048 openssl req -new -key client.key \ -subj "/CN=${CLIENT_CN}/O=Lab" \ -out client.csr cat > client.ext <<EOF basicConstraints = CA:FALSE keyUsage = digitalSignature extendedKeyUsage = clientAuth EOF openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -out client.crt -days 825 -sha256 -extfile client.ext openssl verify -CAfile ca.crt client.crt 4. What goes where File Goes to Used as server.key + server.crt FlashArray ( purecert imported create nfs-server-cert ) TLS policy --appliance-certificate ca.crt (for mTLS) FlashArray ( purecert imported create nfs-client-ca ) TLS policy --trusted-client-ca-certificate ca.crt NFS client ( /etc/pki/nfs/ca.crt ) tlshd truststore ( x509.truststore ) client.key + client.crt (for mTLS) NFS client ( /etc/pki/nfs/ ) tlshd client identity ( x509.private_key , x509.certificate ) From here, finish with the Configuration walkthrough steps above: create the TLS policy, attach it to the file server, create the export, configure tlshd , mount with xprtsec=tls or xprtsec=mtls . References RFC 9289 - Towards Remote Procedure Call Encryption By Default RFC 8446 - TLS 1.3 tlshd(8) and tlshd.conf(5) manual pages Everpure FlashArray File Services administration guide (Purity//FA 6.10.6)
