Planning SQL Server Storage Layout for Snapshot Recovery
Two of the most important things you need to consider when thinking about snapshots are your snapshot recovery goals, and your database instance deployment model. To take full advantage of volume snapshots, your SQL Server environment should be planned with snapshot usage in mind. Your instance deployment model (physical vs. virtual), storage presentation (vVols, VMFS, iSCSI, etc.), and snapshot recovery scope all have a direct impact on storage and database layout. Making these decisions up front helps you ensure that snapshot operations align with recovery objectives, avoid unintended side effects, and remain manageable over time. In this post we'll walk through the different recovery goals folks might have, how those goals are impacted by technology choices, and what changes you might need to make to reach your goals. If you are introducing snapshots into an existing environment things can be a little less flexible, but this post can help you better understand the challenges you might run into. Snapshot recovery scope Below is a summary of some possible recovery goals along with the impact your technology choices can have as well as the impact on how you plan database storage layout. Instance-level recovery is easiest to implement but most coarse-grained; single-database recovery is the most flexible but requires the most careful volume design and operational discipline. Note: tempdb should NOT be included in volume snapshots. It is recreated automatically on startup, and not meant for recovery. The following figure summarizes the possible recovery scopes and how database volumes can be organized for each. Instance-level recovery With instance-level recovery you are looking to recover an entire SQL Server instance at a point in time (all user databases that live on the snapped volumes). This could be part of a data protection plan for an instance that hosts a single application or part of a workflow to snapshot a production system for use in a dev/test workflows. This could even be a temporary workflow for migrating an existing server or adding an HA/DR replica. Special considerations System databases (master, msdb, model) can be either included with the snapped volumes for true instance-level rollback, or kept separate and protected via regular backups, depending on your recovery strategy. If you plan to use instance-level snapshots to create an HA/DR replica, it would be best to leave system databases out of your snapshots. Potential layouts Physical / In-guest / vVols: Shared volumes for all user database data and logs. Best practices and performance will likely mean there are separate log vs. data volumes, and often multiple data volumes. These will need to be a part of the same Everpure volume protection group. Shared-datastore virtualized (VMFS, CSV, AHV): 1 datastore per SQL Server instance, with many VMDKs/VHDXs Impact on volume layout/recovery Very simple to implement and operate. All databases on those volumes/datastores share the same snapshot schedule and rollback behavior. A single database cannot be safely recovered without affecting the others on the same volumes. Application / DB-group recovery In some scenarios you might have groups of related databases that need to be recovered together, but the whole instance should not be recovered as a unit. Maybe the instance hosts different applications with different SLAs, or you just need the flexibility to recover applications separately. Whatever the reason, in this situation you need to keep groups of databases in sync and recoverable to the same point in time. Potential layouts Physical / In-guest / vVols: Application data and log volumes will need to be a part of the same application-specific protection group. For a given instance you will end up with multiple protection groups, one per unit of recovery needed. Shared-datastore virtualized (VMFS, CSV, AHV): VMDKs/VHDXs for each app grouped together on a datastore; other workloads use different datastores. Everpure volumes are created at the datastore level, so applications must also be separated at the datastore level. Impact on volume layout/recovery Databases related to a specific application need to be kept together on the same set of volumes; unrelated databases need to be kept separate Protection groups should be defined so that all volumes that contain files for that app’s databases are snapped together Single-database recovery In cases where you are managing single instances with many databases you often need to recover at the database level. Common situations where this type of recovery is desirable are multi-tenant systems where each customer or user has a dedicated database, highly consolidated environments where large numbers of unrelated databases are housed on the same instance. These cases could both come up in production, but are also very common in dev/test environments. Special considerations For single-database recovery it is possible to run into limits along your storage stack depending on how many databases you have and how they are distributed around your environment. When going down this route it's important to understand limitations around: Volume count (and drive letters) supported by Windows Volume and protection group counts supported by Purity Volume limits per host supported by Purity Potential layouts Physical / In-guest / vVols: Per-database volumes for data and log (or at least for each high-value database), grouped into per-database protection groups. Shared-datastore virtualized (VMFS, CSV, AHV): Shared-datastores are not ideal for this recovery goal as the whole datastore has to be recovered at once. Per-database datastores could work, but would add management complexity. Grouping databases by aggregate size or throughput characteristics could reduce this complexity, but will still present challenges for recovery. Impact on volume layout/recovery All files for the given database must live on volumes that are included in the same protection group. This gives the most recovery flexibility, but increases the number of volumes, mount points, and protection groups (and potentially datastores) to manage. In shared-datastore models, single-DB recovery typically requires cloning the datastore volume and extracting only the virtual disks for that database using vendor-specific tooling; this is significantly more complex than in-guest or vVol layouts. Overall Each recovery goal has its own challenges and trade-offs, but they all share a few core requirements. Keep the recovery unit together: All data and log volumes for a given recovery scope (instance, application, or single database) should reside in the same protection group. This ensures that snapshots capture a consistent point in time and that you can safely roll forward or roll back without orphaning files. Be intentional about what you exclude Since tempdb holds transient data, is recreated on startup, and cannot be used in application consistent snapshots, it is typically placed on its own volume(s) outside of snapshot protection groups. Also because of it's high change rate, a snapshot including tempdb can quickly consume capacity. System databases (master, msdb, model) are usually protected with traditional SQL backups and kept separate from user database protection groups, unless you have very specific reasons to include them. Plan for growth and change: Whatever layout you choose, it has to survive new databases, additional volumes, and changing workloads. Making sure new volumes are consistently added to the correct protection group (manually, via automation, or through Everpure Fusion presets) is key to continuing to meet your recovery goals over time. Read more about Fusion presets on the Everpure support portal. With proper planning, volume snapshots can be a powerful new tool in your toolbox. They can simplify day-to-day operations, make complex recovery scenarios more predictable, and unlock new possibilities for dev/test, reporting, and migration workflows without consuming a lot of time or additional storage.
Ask Us Everything: Everpure & Databases - From Firefighting to Forward Thinking
Databases aren’t going anywhere—in fact, they’re becoming more important than ever. In this Ask Us Everything session, Don Poorman sat down with Everpure database experts Anthony Nocentino and Ryan Arsenault to talk all things structured data. And while AI continues to dominate headlines, one theme came through clearly: AI doesn’t replace databases—it depends on them. If you’re running Oracle, SQL Server, SAP, or anything mission-critical, here’s what stood out.Boosting SQL Server Backup/Restore Performance: Threads and Parallelism
In this post, we’ll discuss day 1 tuning you can do on your database hosts to take full advantage of your new high-performance backup storage. We’ll go over a few tricks around database layout and backup configuration for maximum throughput, discuss some quirks with SMB, and finally discuss using S3 effectively.Tips for High Availability SQL Server Environments with ActiveCluster
Tip 1: Use Synchronous Replication for Zero RPO/RTO Why it matters: ActiveCluster mirrors every write across two FlashArrays before acknowledging the operation to the host. This ensures zero Recovery Point Objective (RPO) and zero Recovery Time Objective (RTO), which are critical for maintaining business continuity in SQL Server environments. Best Practice: Keep inter-site latency below 5 ms for optimal performance. While the system tolerates up to 11 ms, staying under 5 ms minimizes write latencies and transactional slowdowns. Tip 2: Group Related Volumes with Stretched Pods Why it matters: Stretched pods ensure all volumes within them are synchronously replicated as a unit, maintaining data consistency and simplifying management. This is crucial for SQL Server deployments where data, log, and tempdb volumes need to failover together. Best practice: Place all volumes related to a single SQL Server instance into the same pod. Use separate pods only for unrelated SQL Server instances or non-database workloads that have different replication, performance, or management requirements. Tip 3: Use Uniform Host Access with SCSI ALUA Optimization Why it matters: Uniform host access allows each SQL Server node to see both arrays. Combined with SCSI ALUA (Asymmetric Logical Unit Access), this setup enables the host to prefer the local array, improving latency while maintaining redundancy. Best practice: Use the Preferred Array setting in FlashArray for each host to route I/O to the closest array. This avoids redundant round-trips across WAN links, especially in multi-site or metro-cluster topologies. Install the correct MPIO drivers, validate paths, and use load-balancing policies like Round Robin or Least Queue Depth. Tip 4: Test Failover with a regular cadence Why it matters: ActiveCluster is designed for transparent failover, but you shouldn’t assume it just works. Testing failover with a regular schedule validates the full stack, from storage to SQL Server clustering and exposes misconfigurations before they cause downtime. Best practice: Simulate array failure by disconnecting one side and verifying that SQL Server remains online via the surviving array. Monitor replication and quorum health using Pure1, and ensure Windows Server Failover Clustering (WSFC) responds correctly. Tip 5: Use ActiveCluster for Seamless Storage Migration Why it matters: Storage migrations are inevitable for lifecycle refreshes, performance upgrades, or datacenter moves. ActiveCluster lets you replicate and migrate SQL Server databases with zero downtime. Best practice: Follow a 6-step phased migration: 1. Assess and plan 2. Set up environment 3. Configure ActiveCluster 4. Test replication and failover 5. Migrate by removing paths from source array 6. Validate with DBCC CHECKDB and application testing This ensures a smooth handover with no data loss or service interruption. Tip 6: Align with VMware for Virtualized SQL Server Deployments Why it matters: Many SQL Server instances run on VMware. Using ActiveCluster with vSphere VMFS or vVols brings granular control, high availability, and site-aware storage policies. Best practice: Deploy SQL Server on vVols for tighter storage integration, or use VMFS when simplicity is preferred. Stretch datastores across sites with ActiveCluster for seamless VM failover and workload mobility. Tip 7: Avoid Unsupported Topologies Why it matters: ActiveCluster is designed for two-site, synchronous setups. Misusing it across unsupported configurations like hybrid cloud sync or mixing non-uniform host access with SQL Server FCI can break failover logic and introduce data risks. Best practice: Do not use ActiveCluster between cloud and on-prem FlashArrays. Avoid non-uniform host access in SQL Server Failover Cluster Instances. Failover will not be coordinated. Instead, use ActiveDR™ or asynchronous replication for cloud or multi-site DR scenarios. Next Steps Pure Storage ActiveCluster simplifies high availability for SQL Server without extra licensing or complex configuration. If you want to go deeper, check out this whitepaper on FlashArray ActiveCluster for more details.
