Doing a Test Restore Without Affecting the Original Server that was Backed Up

[Philip_D]

I'm currently in the process of preparing for a test restore of some backups of a very, very, VERY important server.  None of us really know exactly how this is going to work since we've never backed up MS SQL with BackupExec, but that's not really the point.  The point is, I want to make absolutely, 100% sure that the test restore doesn't touch or even pretend to touch the original server.  If something from the backup got restored onto the original server, it would be an absolute disaster, with much emphasis on the word "disaster."

So, my question is, simply, is there any way, other than pulling the network cable out of the server or shutting it down entirely to assure that BackupExec can't touch a server?  I mean, obviously we're going to try our best to make sure our restore job's redirection settings are correct, but we're trying to be overly cautious in this endeavor.  I was hoping that you could use vxmon.exe to make the remote agent "hide" the server from the BE media server, but I couldn't find anything like that.

Other info:  Backup Exec 10d with a 10d remote agent, both on Server 2003 R2.

Any helpful suggestions would be appreciated.

[CraigV]

Hi,

What are you looking at restoring?
My suggestion would be to make sure you have enough disk space locally on your local backup server, and create a backup-to-disk folder.
If it's files or Exchange, you are able to redirect your files to this disk, or duplicate your Exchange backup to this B2D folder (see this to get the steps on how to duplicate a backup: https://www-secure.symantec.com/connect/articles/restoring-exchange-or-individual-mailboxesitems-using-backup-exec-howto).
Once these files are on your local backup server, you can then verify that your restores are in working order. Same with Exchange. It would simply create a copy of your Exchange backup in that B2D folder, and nowhere else.
As for SQL, it's a bit tricky. I've only done this once, and as I was using AOFO, I was unable to redirect to another SQL server. At the same time, I wasn't able to redirect the restores to disk either, because of AOFO.
Just run through the options available on each section (Files, Exchange and SQL) and you will notice you're able to do this.
There should be no need to stop services, or switch servers off if you're redirecting correctly.
Just make SURE you're selecting the option to redirect...otherwise you're overwriting your data on the live server.

Laters!

[Philip_D]

I'm looking at restoring files/system state and a SQL database.  The thing with File Redirection is that it leaves room open for mistakes.  If we accidentally select the wrong option or something similar, we may end up making the evening news if that server gets borked.  If there's a way to completely block a server from being affected by Backup Exec, that could be avoided.  Dealing with this server is making me extremely nervous and I don't want to have to rely on checking and double-checking my selections, because it's possible to check something 50 times and not notice an error.

[Scott_Meltzer]

To be quite honest, your best bet would be to create a testing scenario.   Find two spare servers, set them up on a completely separate network.  

Install Backup Exec on one server and connect it to your tape drive.   Inventory the tapes and catalog the media.

Install SQL on the second server, set it up and name it exactly the same as the "live" server.

Once you're done with that, you can restore data to your heart's content without causing any problems for the live server.

[Ken_Putnam]

Aside from Scott''s suggestion of a Test Network, the only way I know of to be absolutely certain the original database is not overwritten would be to either disconnect it from the network or shut down the SQL Server service during the restore

[Philip_D]

Well, thanks for the suggestions guys.  I know it probably sounds pretty stupid, but this test restore is REALLY freaking me out to the point where it caused me to come into work this morning with a sinking feeling in my stomach.

[Scott_Meltzer]

No prob, I think we've all been there before.   Coming here to ask questions and doing your research in advance puts you in a good spot already.   Now that you've done about as much checking as you can do, whichever route you choose to take should work out well.

Impulsively doing things (i.e. restores, installs..etc) without researching the consequences usually doesn't end well.

[Ken_Putnam]

No prob, I think we've all been there before

as the Subject Line  says, Been there, Done that.  In fact I've got several T-Shirts to prove it   |8^)