Application aware data protection and/or storage moves well beyond the capability of knowing how to quiesce the application so that the changes of a consistent copy of the environment is made. Protection of applications like Exchange, SQL and Oracle are almost useless when the last known good copy is last nights backup. The replay of transaction logs alone, if they survived the data failure, could take a very long time, let alone how long the base restore would take.
A more granular approach that either thins out the amount of data moved, as is the case with block level incremental (BLI) backups or utilizes on-board snapshots is preferable here, so the frequent capture of the data can be made. If an Exchange environment can be protected every 15 minutes with minimal data movement, the work to reapply transaction logs will be minimal. With these techniques, snapshots or BLI data growth is minimal.
As we discuss in an earlier entry "The Problem with Snapshots", the advantage of the off-primary storage solutions, i.e. not snapshots, is that if there is a failure on your primary storage, your protected copy does not fail along with it. In many cases these off-primary solutions can even allow you to start operating immediately off the protected copy while you rebuild and recover the fallen host or storage. The ability to recover in place, without having to move data in these key applications becomes more critical as capacities increase and recovery windows decrease.
Going further these solutions need to understand what application they are protecting at a very granular level; messages within Exchange or objects within SQL or Sharepoint. For example you should be able to use one of these tools on Exchange to mount the backup image of the environment for the ability to search for the data needed and instantly restore mailboxes or individual messages directly from the snapshot or disk backup that the tool created.
They should also provide the ability to quickly determine if the backup set itself is valid by doing some sort of corruption detection. We've all seen the studies indicating that almost 50% of recovery attempts initially fail. The wrong time to learn that your backup copy of your Exchange environment is corrupt is when you attempt to recover it. Having that knowledge prior to you actually needing that backup copy can allow you to either take another backup, again with these tools there is little impact, or at least you know not to waste time recovering bad data.
Optimal performance of these mission critical applications is always going to grab headlines but when the server is down, the storage has failed or a user's mailbox is corrupted, all the talk of optimal is quickly traded for "just get me back to work at any speed".
Track us on Twitter: http://twitter.com/storageswiss.
Subscribe to our RSS feed.
George Crump is founder of Storage Switzerland, an analyst firm focused on the virtualization and storage marketplaces. It provides strategic consulting and analysis to storage users, suppliers, and integrators. An industry veteran of more than 25 years, Crump has held engineering and sales positions at various IT industry manufacturers and integrators. Prior to Storage Switzerland, he was CTO at one of the nation's largest integrators.