More info on Shadow Copy in NT Backup vs. VSS/SIME

I have been neck deep in this topic for a couple weeks, so it is great that Nino Bilic (http://blogs.msdn.com/exchange/archive/2004/06/25/166104.aspx) wrote about this.  It supports my assumptions, but I would also like to add the issues around VSS and 3rd party products like SIME from EMC and their usefulness in production.  I spent a while thinking and documenting the reasons for DR scenarios and what type of recovery would be best.  Granted, VSS/SIME would work in all situations, but to work, the pain of recovery is too high in many cases.  Below is the post by Nino on his Blog and my research on the topic also.

---

 

My post on backups did not go into VSS backups and Exchange. Here are a few things about using VSS and Exchange, seeing that NTBackup comes with some "generic" shadow copy capabilities - a clarification of that functionality is in order:

 

- You physically can back up Exchange database files while online using NTBackup's generic shadow copy capabilities (W2K3/XPSP1 versions of NTBackup). This is not an "Exchange-aware" backup - NTBackup grabs the files like it does any other open file by using shadow copy. Therefore, this is NOT the recommended way to back Exchange up. It is essentially the same thing that you would get if you were using the "open file agent" from a 3rd party backup software. Additionally, if this type of backup is performed, you would have to make sure that the backup contains all drives where Exchange data lives on in order to have chance of successful restore.

 

- You can back up Exchange databases while online using NTBackup's Exchange-aware streaming backup API module (Online backup).

 

- Whether you do the backup with generic shadow copy capabilities or via the streaming API, the database will be "crash consistent" - meaning, it is marked as being in "Dirty Shutdown" state and must have log files replayed into it after restoration before it can be mounted. This "Dirty shutdown" state can be seen if you dump the database header using ESEUTIL /mh command. When databases do not require any logs to start, they are marked as being in "Clean shutdown" state. Please note here that if you restore a full online backup of the database and let the database go through the "recovery" (meaning the database replays the logs that were restored plus possibly some logs that were already on the disk) - the database will get into the "Clean shutdown" state without user intervention. That is why the previous post said that Online restores "just work".

 

- Backing up Exchange databases via the generic shadow copy capabilities that do not use the VSS framework that is provided in W2K3 is not supported or recommended. Yes, it can work, but it depends on you also capturing/preserving the right log files. You should exclude Exchange databases and logs from ordinary file backup to keep the backup from bloating and do a separate streaming API backup of Exchange, if NTBackup is your only backup solution. There's no time advantage in doing a generic shadow copy backup of the Exchange database, because NTBackup streams the file anyway even though it's a shadow copy, and you don't get checksum validation, preservation of necessary log files, etc.

 

- Exchange-aware VSS/shadow copy backups are available, but not with NTBackup - you must purchase a third party solution, and you must have special hardware capable of "snapping" the entire database backup very quickly (within ~20 seconds). Exchange does special things with the database to make it easier to backup reliably when you use an Exchange-aware solution (for example, every single physical database page is checksumed to make sure that we are backing up good information). When you do a garden variety shadow copy with NTBackup, the backup is streamed to tape or disk over a relatively long period of time, and Exchange has no idea that it is being backed up.

 

I hope this clarifies the difference between "generic" shadow copy functionality that NTBackup now comes with and the "full" VSS backup solution, as there is a big difference!

 

Nino Bilic

---

EMC SnapView Integration Module for Exchange 2003 (SIME 2003)

EMC Maintains a Snapping or Cloning technology for Exchange Server 2003 that utilizes Microsoft VSS technology.  The SIME solution completes a backup of sorts in the following basic process:

·         Checks the event logs on the host server to determine if any known database errors have been logged

·         If the above is ok, then ask VSS to acquiesce the Storage Group on the MetaLUN and Snapshot or clone the MetaLUN to an alternate location on the SAN.

·         Asks VSS to thaw the Storage Group and continue normal processing

·         Scans the databases that have been cloned by running ESEUTIL and checking for database consistency.

Recommended Usage

It is recommended to only use the SIME clone copy of the MetaLUN in the following disaster scenarios:

·         Entire Storage Group Failure / Corruption that is less than 4 hours old

·         Entire MetaLUN failure

·         Entire SAN failure

Windows Server 2003 Backup

Exchange Server 2003 can natively be backed up using the Windows Server 2003 Backup solution.  This provides to disk or to tape backups. 

·         The backup software first contacts the Exchange System Attendant to ask it to start an online backup

·         The System Attendant acquiesces the databases and begins streaming the database information to the backup utility, which then streams it to an alternate disk location

·         Once the online backup has completed, the System Attendant thaws the databases and plays in logs that were used during the backup.

Recommended Usage

It is recommended to use the Windows Server 2003 Backup solution in the following disaster scenarios:

·         Single or Multiple Store Failure / Corruption

·         Single User Date Restore

·         Short term / Long Term Corruption (or possibly move users to a new Store and then re-create damaged database, then move users back)