The Debate Over Crash Consistent SnapShots

Last week I posted a blog: Protecting Consistency Groups Against Human Error.  I decided to see what other people were saying, so I did a little browsing around message boards, user groups, and forums.  Back in 2010, W. Curtis Preston of Backup Central got into a lively debate with Scott Waterhouse of EMC, with Curtis stating emphatically, “Crash Consistent Backups Aren’t Good Enough,” and with Scott responding that they work, but ” wouldn’t it be ideal if you could do better.”

There’s plenty of  concern about the ability to reliably recover applications from crash-consistent copies of data. Of course, it’s different for every application and every environment. Here’s some advice from an EMC message board on how to ensure recovery using RecoverPoint with Oracle:

Many customers and field personnel use RecoverPoint to constantly and successfully access and bring up both application and crash-consistent copies of Oracle every day.

If the Oracle database is setup correctly in RecoverPoint in terms of consistency groups and ensuring that the target volumes are only accessible to ONE mount host and the other host-level best practices are followed, then I would expect you to have no issues.

Click here for the full discussion.

There’s also a helpful discussion by Mike Rothouse on recovering Oracle data from NetApp storage using NetApp’s crash-consistent SnapShot.

If a database has all of its files (control files, data files, online redo logs, and archived logs) contained within a single NetApp volume, then the task is straightforward. A Snapshot copy of that single volume will provide a crash-consistent copy.

Click here for the full discussion.

My key observations are:

1. If you depend on crash-consistent copies of data, then it may work some of the  time for some of your applications, but it won’t work all of the time for all of your applications.

2. Best practices for recovering from crash-consistent SnapShots restrict your options for data placement and volume management.

3. Applications, systems, and IT processes are in constant flux, so if you need to set up consistency groups “correctly” in order to ensure recovery, you are creating an inherent human-factor risk.

I don’t know about you, but with the pace of change, the cost of training, and the strain on staffing in today’s IT shops, I would opt for solutions that work the same way across all applications, automatically adapt to changes in the environment, and reduce the risk of human error.