Home > Storage > PowerFlex > White Papers > Microsoft SQL Server Data Protection using Dell PowerFlex Snapshots > Use Case 4: Enterprise data protection using PowerFlex snapshot policies
Modern enterprise applications are often integrated by different components like front end services and application logic, message queues like RabbitMQ or Apache Kafka, a combination of SQL and NOSQL databases, external data that is tied to the database indexing, and more. These components work together and are critical for business operations. Data loss or system fault in any of these components may lead to interrupted business operations.
Maintaining uninterrupted IT operations under the constant threat of equipment failures, ransomware and site outages requires new business continuity measures – particularly as the number, types and locations of data storage devices that are involved grows, and their importance escalates.
Backup of each such database component separately protects the components, but rarely preserves the point of consistency across databases, message queues, and external data. Even if the business can recover each component separately after a disaster, they cannot regain normal operations until the enterprise point of consistency is regained, which can take additional hours to resolve while the business is down.
Storage snapshot policies are an effective business continuity measure that help business to quickly recover from any disaster, while maintaining an enterprise point of consistency for storage volumes across applications, databases, message queues and external data. This use case describes how the PowerFlex snapshot policy is helpful in creating enterprise consistency across a set of PowerFlex volumes and how to set up a protection policy.
The following steps describe the implementation of the snapshot policy using the PowerFlex UI.
Figure 20. Creating a snapshot policy
2. In the wizard, enter the policy name, interval, and desired retention period as per the business need. First the rule is created that defines the interval between the snapshots and the retention to keep the number of snapshots.
Figure 21. Snapshot policy wizard
In the above example, the name of the policy is Hourly_Weekly_snapshot that takes the snapshot every 60 minutes and keep 24 of them, making sure that the snapshot is available of every hour for the past 24 hours.
The rule can also be created in a multilevel retention structure to retain the snapshots in minutes/hours/days or weeks. The above policy also describes another level of retention to keep one daily copy of the snapshot for a week.
3. After creating the policy, to add the source volumes, select the policy, then click More Actions and Assign volumes.
Figure 22. Assign Volumes to the snapshot policy
In this example, different application volumes are selected for an hourly snapshot with the different retention levels considering enterprise point of consistency.
This approach helps organizations to streamline the data protection process and guarantees faster recovery from the disaster. Organization may create multiple snapshot policies for different application volumes as per the SLAs defined for it.
The following image shows the newly created snapshot policy once the wizard is finished.
Figure 23. Policy state
Alternatively, the same policy that is described above can be created by using the following CLI command:
scli --add_snapshot_policy --snapshot_policy_name Hourly_Weekly_snapshot snapshot_creation_cadence 60 -- number_of_snapshots_per_retention_level 24,7
Note: The snapshot_creation_cadence is set in minutes.
Add the source volumes to the policy by running the following CLI command:
scli --add_source_volume_to_snapshot_policy --snapshot_policy_name Hourly_Weekly_snapshot --source_vol_name SQL_Server_log WFSC_quorum kafka_partition1 kafka_partition2 kafka_partition3 mongo_shard_1 mongo_shard_2 mongo_shard_3 mongo_shard_4