Building a Resilient SQL Server Refresh and DR Strategy with Persistent Topology Tagging

The Pure Storage Advanced Services team helps customers solve a variety of challenges. Here’s a look at how the team developed a custom automation solution for SQL database refreshes and disaster recovery.

Building a Resilient SQL Server Refresh Topology Tagging

Summary

By tagging FlashArray volumes with SQL topology metadata, the Pure Storage Advanced Services team created a solution that enables autonomous database refreshes and resilient disaster/ransomware recovery, even without access to the original source systems.

image_pdfimage_print

In my role on the Advanced Services team at Pure Storage, I specialize in delivering custom automation solutions tailored to our customers’ operational goals. A consistent need across engagements is enabling data refresh solutions to be more autonomous, predictable, and recoverable. Recently, a particularly nuanced customer use case led us to evolve our tooling into something that not only supported SQL database refreshes but also laid the groundwork for true disaster/ransomware recovery automation.

The Problem: Storage Is Blind to Database Topology

FlashArray™ excels at capturing, protecting, and replicating data with incredible efficiency. However, at the block level, the array has no innate understanding of what lives inside a volume. For traditional backup or refresh workflows, this limitation can be easily worked around because production environments are intact and referenceable. But what if the production server is gone?

This is exactly the scenario one of our customers was preparing for. Not only did they want to streamline regular database refreshes from production to dev/test environments, but they also wanted a way to automatically recover those same databases at a disaster recovery (DR) site—without access to the original source system. Additionally, they needed a resilient strategy to recover from potential ransomware events, where corrupted or encrypted databases could leave them without a clean recovery point or intact topology.

Our Solution: SQL Topology Polling + Volume Tagging

To support both refresh and DR use cases, I designed a service that continuously inventories SQL Server instances and records their full database topology. This polling service can run at whatever frequency matches the rate of environmental change—hourly, daily, weekly—to ensure we always have a current snapshot of what databases exist, where they’re mounted, and what volumes store their data and log files.

This topology metadata is then encoded as FlashArray volume tags under a custom created namespace we called masterinfo. Each volume receives key-value tags that describe:

  • The hosting server and mount path
  • Associated databases
  • Full file paths (MDF, NDF, LDF)

By embedding this topology directly on the volumes themselves, we decouple recovery from any central SQL inventory or CMDB. The metadata travels with the volume—no matter where it lands.

Not only does this model enable fast and intelligent disaster recovery, but it also supports historical restore scenarios. Pure Storage snapshots preserve volume tags exactly as they were at the time of capture, effectively tattooing each snapshot with the topology details of that moment. This gives customers the ability to restore a database exactly as it appeared days, weeks, or even months ago, consistent with its original volume and file layout.

This capability is crucial not just for DR but also for protecting against ransomware attacks. In the event of a ransomware event that encrypts or corrupts databases, these tattooed tags allow customers to precisely recover the last known good state of their database infrastructure—including file locations, volumes, and mappings—without relying on potentially compromised systems. This enables a clean, reliable rollback to a trusted recovery point, significantly reducing time to restore and ensuring confidence in data integrity.

Real-world Example: masterinfo Tags on a Source Server

Here’s a real snippet from a source server ads-win-sql-01a showing how database topology is recorded via masterinfo tags.

KeyValueNamespace
databasesMultiFileDB, MultiFileDB2masterinfo
multifiledbfile0m:\data\multifiledb_primary.mdfmasterinfo
multifiledbfile1m:\data\multifiledb_ndf_m.ndfmasterinfo
multifiledb2file0m:\data\multifiledb2_primary.mdfmasterinfo
multifiledb2file1m:\data\multifiledb2_ndf_m.ndfmasterinfo
sourceserverads-win-sql-01amasterinfo
sourcemountm:masterinfo
KeyValueNamespace
multifiledbfile0l:\logs\multifiledb_log.ldfmasterinfo
multifiledb2file0l:\logs\multifiledb2_log.ldfmasterinfo
databasesMultiFileDB, MultiFileDB2masterinfo
sourceserverads-win-sql-01amasterinfo
sourcemountl:masterinfo

Together, these two volumes (one for data, one for logs) contain the complete topology needed to recover MultiFileDB and MultiFileDB2 in any environment. This is a simple example, but the solution is designed to scale and inventory many databases, sitting across many files, spread across many volumes in a single pass.

Enabling Repeated Use with targetinfo

For the recovery side, we layered in a complementary tagging schema into a custom namespace called targetinfo. When a recovery operation is performed (such as mounting replicated volumes to a new host), this metadata is written to indicate which server received the data and where it was mounted.

Example targetinfo tags might look like:

KeyValueNamespace
targetserverads-win-sql-01btargetinfo
targetmountm:\ads-win-sql-01a\ydrivetargetinfo

With this dual-namespace tagging model, we know exactly which volumes from a given source server were restored to a given target server. This enables:

  • Detection of whether a given refresh is a new attach or an overwrite
  • Automation of SQL attach/detach workflows
  • Near-instant recovery of databases with known structure
  • Restoration of historical database states using snapshot-preserved tag metadata
  • Confident recovery from ransomware by leveraging unaltered topology stored with the snapshot

Furthermore, this architecture supports hosting multiple named copies of the same database on a single target system. By providing a TargetName parameter (e.g., CodyTest), the targetinfo tag dynamically reflects the customized path, such as:

KeyValueNamespace
targetserverads-win-sql-01btargetinfo
targetmountm:\ads-win-sql-01a\ydrive_CodyTesttargetinfo

This flexibility makes it possible to stand up multiple variants of a production environment side by side on the same server—ideal for sandboxing, development, or QA purposes. Moreover, by embedding the source server name in the mount path, environments can retain duplicate drive letters from multiple origins without conflict, enabling ultimate design freedom for recovery topologies.

Summary: Metadata That Moves with Your Data

By embedding SQL topology metadata directly onto FlashArray volumes, we give our customers a portable, self-contained, and self-maintained recovery reference. This capability becomes invaluable when automating DR procedures where the original SQL Server is gone and topology can’t be inferred.

Even more powerfully, Pure Storage snapshots retain this metadata across time. The result is a resilient, consistent, and highly flexible recovery mechanism that works just as well for routine refreshes as it does for complex DR, ransomware response, and point-in-time restores. With the snapshot-preserved tags, customers gain the ability to recover environments with fidelity to their historical structure, supporting compliance, investigation, and rollback use cases with confidence.

This entire solution is a powerful example of the automation potential built into the FlashArray platform, especially when combined with the expertise of Pure Storage Advanced Services. Whether you’re looking to solve this exact challenge or tackle an entirely different automation use case, our team is here to help you architect and implement innovative, scalable solutions tailored to your goals.