New recovery Database in Exchange 2010.

Exchange 2010 uses powershell to create a Recovery Database and restore the database from backup to the Recovery database then restore individual items from the restored DB to the existing DB.

Now if I already have backup solution such as Veritas, Netbackup or commvault. Do I still need to use the New Recovery Database ?

Thank you
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

You should, with proper logs and backup be able to restore and mount a database.
With a good copy and logs, you should be able to restore to the same server.  With the server out of commission, you would use the Recovery Database and the backups to copy the items from the backup to the "new" database.

More importantly, you might want a lagged copy within a DAG so this issue is most likely averted to begin with.

Here is info for Symantec:

Here is another article on recovering a DB.

Same Server recovery from a backup:
Rodney BarnhardtServer AdministratorCommented:
It really depends on your backup product. I am not as familiar with products like Backup Exec or Netbackup since I have not used them in a few years. I did research Backup Exec, and the instructions still include manually creating the database and then directing the restore to it. I currently use Avamar. With it, there is no need to create the Recovery Database when doing granular level restores. However, we recently ran a test of restoring a database and mounting it. With Avamar, there is the option to name the Recovery Database. Therefore, Avamar can create the destination folder, the recovery database, restore the database and the logs. It will also replay the logs and mount the database.

So, I believe the answer to you question is that it depends on the product.
Kyle GreenCommented:
I use Backup Exec so I will shed light on it for you in this particular situation. We use it to fully back up all of our databases but it did require setting up agents on the Exchange servers.

We have not tested the disaster recovery since I began work at my institution and even lost 50 servers this week because IBM technicians let our XIV power down attempting to replace one of the three hot-swap power supplies, but the SAN managed to recover the exchange servers.

As for creating the database and pointing the restore, yes. For those we had to restore we first had to create the VM of the same OS and and point the restores towards it. So far no need for restoring the databases but I'm a little more than 99% sure that the previous comment is absolutely correct.

To answer your question from this angle, no you don't need the recovery database with Backup Exec 2012. Hope that helps you.
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

Ouch, XIV down is not a good situation.  Did IBM crap bricks?  
XIV is a top-tier, super-intelligent SAN, I hope you didn't lose data or incur much downtime.
Kyle GreenCommented:
We had some major corruption but I have a remote disaster recovery XIV. This is super off-topic but let me tell you the process that happened (this was on Wednesday).

They first migrated the data from module 4 to modules 1-3 and then enabled 4, disabled 1, and basically got the data to rebuild in a pattern that reminds me of sifting for "gold" at an old west attraction. Effectively the tertiary blocks that were dropped when the data was originally written were forced to take on a primary status, which recovered a very impressive amount of data with almost no corruption. Out of the 75 VMs on the XIV 23 didn't come back up right away, but after this data sifting process I got all but 10 back. The other 10 were put into a spare LUN on the remote XIV and then we reversed roles and replicated them back to the production XIV. It took FOREVER but it mostly worked. End result was 2 VMs were lost (esxi 4.1) but I had BE2012 backups and we recovered the final two from that.

The lesson here is when you're dealing with hundreds of terabytes of data, have an automatic failover solution to a remote site. We only had a manual failover in the event of physical destruction of the datacenter, but, we managed. It was painful though.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Kyle GreenCommented:
Oh and yes, IBM crapped more bricks than you could count. Had a conference call between us, IBM and VMWare that broke the 12 hour mark.
jskfanAuthor Commented:
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.