SME / Restore from tape archive?

[rmharwood]

We're in the process of getting SME fully up and running. We think we have successfully configured it for backups and restores from snapshots on disk.

Currently our longer term backup process still revolves around tape storage. We keep up to 7 days worth of snapshots on disk and take a weekly NDMP dump of the LUNs inside the latest snapshots. The SME admin manual explains how to perform an archive but does not go into any details about restoring from archive.

Has anyone successfully performed a restore from a LUN snapshot on tape? I got as far as recovering the LUNs (the store and the transaction logs) back to the filer and presented to the host (through Snapdrive) but that's about it. Can SME be used at this point or is all the information it needs for the restore lost already? If SME can't be used, what is the typical procedure? (I'm not at all familiar with Exchange 2007 to be able to make any guesses from this point...)

Many thanks for any insights.

Richard

[pascalduk]

Yesterday I opened a case with netapp support with the same question: how to restore an archived backup for Exchange 2007? In my case the archive is a snapvault destination and not tape, but that should not be much of a difference. The only documentation I could find was KB3990, but that does not work for Exchange 2007.

I will post the answer here when I get from support. But if someone else already knows how to do it ....

[rmharwood]

Good to know, thank you. We will be moving towards using SnapVault in the future also so this would be useful!

Cheers.

[pascalduk]

Response from support:

"For the configuration you specified, the way that would be done without impacting the users would be to restore it to a recovery storage group.  This is a setting that would be selected in restore wizard.  You’d select it to restore to a recovery storage group, then you’d select a database(i.e. LUN) you want to restore from the SnapVault and SnapMirror enabled storage systems from the listed Archived backups, and, and that should do what you have described."

I can't test it right now, hopefully in about 2 weeks.

[rmharwood]

We ended up opening a support case and it's been escalated because we can't get it working. We can restore the LUN(s) from tape, connect them to the Exchange server using SnapDrive, point SME at the SnapInfo directory (like the manual says) but the restore does not successfully complete. Usually it gives a VSS error, sometimes other errors.... very frustrating.

I'll update this once we know anything further.

Richard

[pascalduk]

Oh, that is interesting ....

I have not had the time to test it myself, so I am curious about your experience.

[scottfawcett]

I am trying the exact same thing.  However, when I mount the NDMP restore luns I don't have anything present in the LUN.  I have information present when I do a df or a lun show but nothing when I explore the directory.  It doesn't matter if it is mounted via snapdrive or manually.  I have tried using disk part to clear the hidden and readonly flags on the disk, volume and partition.  I have also cloned the lun to see if that would repair the partition.  The odd thing is that I can see the luns in device manager but if I online them they ask to be formatted.  If I do the disk part work below then I get the blank lun.

I got the following steps from support to try and they didn't work:

https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb41190

The platform is a replicating via MS CCR and we are running the SME backups on the passive side.  One thing we suggested to do by support was to stagger the database backup times from the log backup times to allow the database commits to be stored in the logs.  That might help with your VSS issues.

Is anyone else seeing these type of mount issues when they mount up an ndmp restore?  I am backing up the /vol/<vol name>/.snapshot/exchsnap__<server name>__recent  snapshot.  Is there a flag I need to flip?  Thoughts are welcome.

exch 2007

SD 6.2

SME 5

Thanks,

-S

[scottfawcett]

Update on this:

Found the issue.  Apparently when you back the volume up with NDMP you can get a backup that has data written to it but still not be a good backup.  We reran the NDMP backup process from scratch and that fixed the issue.

-S