2009-10-02 09:52 AM
Currently we're running Exchange 2007 on a 2 node cluster
with all the databases on our netapp filer. We're backing up the Exchange servers using Commvault and snapping the databases hourly with the Netapp.
Once a day were backing up the snaps using a Commvault NDMP.
What would be the recommended why to backup my exchange environment?
Is our current backup strategy effective or flawed in a way we haven't thought of yet?
2009-10-02 10:40 AM
Have you taken a look at our SnapManager for Exchange program as of yet?
SnapManager for Exchange allows you to:
Execute fast backups without taking Exchange Server databases or mailboxes offline. Use our Snapshot™ technology to store more than 250 copies of data to get fast, granular recovery. Restore from a wide range of options such as full content, individual, storage group, individual database, and virtual disk recovery.
And that's just for starters.
Here's a link to the landing page regarding the product:
I think it would be worth your time to take a look at the information on the site.
Technical Systems Engineer
2009-10-02 11:02 AM
Streaming backup, using the Exchange streaming API, is supported in Exchange 2007. (example, NTBACKUP). A streaming backup will backup X megabytes per second, and so the length of time to backup/restore is linear to the data set size. (bigger databases will take longer). Streaming backup is deprecated in Exchange 2010.
Microsoft's VSS framework allows an application to be snapshot (or volume shadow copy in Microsoft terms) aware. For information on how this works see the Microsoft Exchange best practices for VSS document here: http://technet.microsoft.com/en-us/library/aa996004.aspx
In order to perform a supported VSS backup, you would need a backup application that is VSS aware, the writer (in this case the Exchange writer), and a provider. NetApp's requestor is SnapManager for Exchange. NetApp's provider is SnapDrive. With these products you can take snapshots of the production database, and run an integrity checksum against that backup. Verification of a VSS backup is a Microsoft support requirement. See: http://support.microsoft.com/default.aspx/kb/822896.
My question to you is, are you performing a streaming online backup with CommVault? If so, and you take a snapshot of the volume that is the target of that backup, you are ok. However if you need to restore that backup, it will have to stream back to the primary NetApp storage that houses the Exchange transaction logs and databases.
How are you snapping the databases (do you mean the live production LUNs?) with NetApp? If you are doing this outside of the Microsoft VSS framework it is not supported.
Exchange Server 2007 best practices: http://www.netapp.com/us/library/technical-reports/tr-3578.html
SnapManager 5.0 for Microsoft Exchange Best Practices http://www.netapp.com/us/library/technical-reports/tr-3730.html
2009-10-02 11:23 AM
We're currently leveraging Snapmanager for exchange to perform the hourly snapping of the exchange databases and logs.
My concern is do those snaps contain all the information required for a disaster recovery restore. I believe they do, because I ran a snap, backed it up using commvault.
Then I deleted a mailbox database. I restored the database and everything was well again.
I guess I'm trying to confirm that snapmanager for exchange is aware enough to be able to backup all necessary exchange files necessary for a restore.
2009-10-02 11:37 AM
SnapManager for Exchange is definitely backing up all of the Exchange data. What it is not backing up is the server or system state. In Exchange 2007 with database portability, most customers use a standby mailbox servers and let SME move the users in AD automatically. Some customers who have legacy Outlook clients prefer instead to not use database portability. In that case the entire design of your topology has to revolve around clustering (for an Exchange CMS).
In a DR scenario you can do a couple of things:
1) restore a backup of the server and system state, bring up the restored server, use SnapManager to restore the Exchange data (logs/db).
2) install windows on new hardware, restore system state, bring up the restored server, use SnapManager to restore the Exchange data (logs/db).
3) Have a standby server or VM with the mailbox role installed (or do these things first), use SnapManager to restore the Exchange data (logs/db) by choosing the option that this target is not the original server. In this case SnapManager will send the appropriate command via powershell to move the users in active directory to the new server.
If you only have an issue with the Exchange data, a simple SME restore to the original location will suffice.
2009-10-02 02:27 PM
Just a few more thoughts....given SnapManager for Exchange (SME) functioning successfully, you can.....
2010-06-05 05:56 AM
Quick question about restoring to the Primary storage.
I am currently working on a ndmp backup issue where I restore the LUNs and they are blank. We are backing them up via ndmp on the passive side and using Microsoft CCR replication to the passive side of the MS cluster. Have 2 NetApp clusters a 3140 ( the normal active locaiton) and the 3020 (passive CCR target). If we make the passive side the active side and use the ndmp backup taken on the active side does that count as primary storage? Or do we need to restore to the original active node? I was thinking that the passive side, now configured to the active side, would count for the primary storage.
The other thing to note is that we are running two instances of SME since we are replicated via the MS CCR. One instance is on the active and one on the passive. We are working with the passive side to do the recovery.
Any suggestions would be appreciated.
2010-06-07 03:28 PM
I believe your issue is a NDMP issue, which the restore LUN from NDMP is empty. I also don't think restoring to different host other than the original one is relevant here, the restored LUN should not be empty.