Most organizations database applications are the most critical data in the organization. Protecting those databases with database snapshots provide a mechanism to meet the Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO) requirements these organizations need. While database snapshots are only part of a data protection strategy, they are useful in solving a variety of problems. The challenge is creating the tactics of how to use snapshots to develop a database data protection strategy. Let’s break down database snapshots within the Dell EMC Unity & SC Series Storage lines.
Create a Strategy
Understanding business requirements is always the best place to start. Because this is a discussion of data protection rather than high availability, we aren’t considering clustering solutions. The focus of this post is about managing data versions and protecting ourselves from data loss resulting from either human error, a virus or ransomware event, or hardware failure resulting in corruption. In any of those scenarios, a rapid recovery will get the business back operationally. Since the database application is so vital to the company, organizations are usually willing to spend some more money to protect that data versus less essential applications. Adding snapshots will use some storage space which increases the cost of ownership but at the same time brings tremendous value.
Aside from data protection database snapshots can also serve other purposes. If the application leveraging the database is an in-house application there may be a need to provide test copies of the database to developers. Compliance and auditing is another typical use case where a company is required to produce a copy of its data subject to inspection and verification; A secondary copy of the database can facilitate this requirement as well.
When to use a database snapshot
Snapshots are “Point-in-Time” or “PIT” copies of the database. If using a storage array such as a Dell EMC Unity or SC-Series, the array will create a PIT copy utilizing any additional space. This newly created snapshot is a “thin” copy because pointers managed by the array will keep track of changed blocks. Snapshots are read-only copies of the database but if a read/write copy is required a Thin Clone can be created permitting users to write new data to the PIT. Since databases are made up of multiple files and performance is critical to these applications, the different files of a database should reside on different LUNs. The LUNs supporting these files should be placed together in a consistency group and snapshot together to maintain data consistency. There will be pre-snapshot and post-snapshot scripts run before and after the snapshot to ensure the creation of a consistent PIT.
From a data protection perspective the snapshot schedule could be created to protect multiple scenarios. This schedule should make up a sparse retention strategy and could look something like:
- Snapshot every hour retained for 8 hours
- Snapshot every 4 hours retained for 24 hours
- Snapshot every 24 hours retained for 120 hours and replicated
The purpose of the hourly snapshot is to protect from data loss that could come from a user error or ransomware event. In case administrators discover they need to recover the database, the snapshot can be applied to the production volume immediately and the application brought back online. Snapshot frequency greater than one hour are possible but could be problematic for the application since the snapshot intrudes on application operation. A snapshot every four hours protects the environment from a problem not immediately discovered or to provide a reasonably recent copy for dev/test functions. Daily snapshots are used as backups in the event of a data loss and replicated to a DR site.
If you are interested in automating the creation, replication, and deletion of snapshots and thin clones consider using Dell EMC AppSync. A license is included with the array and features the ability to make and manage multiple versions of PIT database copies in a GUI. AppSync simplifies the process of managing snapshots and thin clones as well as automating the creation without the use of scripts.
Summary
If you own an enterprise storage array and are using only database backups, we encourage you to look into incorporating snapshots into your data protection strategy. They will use some disk space, and some custom work may be required, but the power and flexibility they provide for both data protection uses and other application are invaluable. They should be part of your data protection strategy and more.
Please feel free to reach out to learn more or further discuss leveraging snapshots.
