How to test a backup on W2K?

[haironfire 0]

I need some advice on testing a backup on a W2K system. We have 2 Dell Poweredge 2650 servers, one as a file server and one as a DNS server. We also have a Powervault NAS device where the backups are supposed to go.

 

From what I read the only way to definitively test a backup is to restore it and check out the restore. I can't take either of our servers down for this project, so I am limited to whatever testing I can do short of that. Any suggestions?

 

What is the usual protocol for testing backups? I can't imagine that every small shop out there has a full testing environment and time to do test restores on every backup. So where/how do you draw the line?

[adamvjackson 0]

Personally, I just back up the data. The configuration I know how to re-create, in addition to the server roles. Keep in mind, I am responsible for 5 Windows servers, 2 Linux servers, and one AIX server.

 

One of the Windows Servers is actually a Dell P/E 2650 as well

 

I'm sure that's not best practice, but all of the server hardware is so dissimilar.

[haironfire 0]

You don't test the backup?

 

(Not editorializing, just want to be clear)

 

btw, with such a diverse production environment how do you ever test anything?

[adamvjackson 0]

I check the CRCs/verify the data backup, that's really all that's mission-critical here.

 

As for testing, I have a seperate DC and about 3 test clients that I can test some new software/services on before deploying. Great? No, but so far it's been ok. Most all of the data is just SQL databases, and I have tape, SAN, and an off-site backups done of those databases.

[ScinteX 0]

BrightStor ARCserve has a very detailed log... its that detailed it gets a bit.. yawn... boring

 

On the Bright side (ho ho) it hasnt failed us once- even when doing disaster recovery on 49 Win2K servers, 6 Nt 4.0 boxes and various other bits and bobs. Same applies for regular backups and restores.

 

It isnt actually that pricey considering it is (i suppose) an industry standard.

 

I guess my point here is that by all means do something like an annual disaster recovery routine just to prove that your methods are still valid and work. Of course this can mean the odd bit of downtime. However, assuming the worst, another box is well worth it since if the restore fails then u r stuck considering you've just done it on a production server!

 

I feel a bit useless here since ive only every worked in big organisations.. ...which can have its faults.

 

We have a contract with a 3rd party that deals with the real bad stuff. So thats anything from a fried CPU on a production box all the way to fire, flood etc. With that is bundled remote working so that we can all work from a completely different location using the 3rd party's servers.

 

Scaling this down to a shop- maybe you can rent an identical server to restore to? That would prove the concept. Then maybe you can find a company that you can pay to get you out of the poop if something does go wrong. A failover plan could be as simple as renting a server..... or it could be more formal depending on the suits' preferences.

 

 

 

Regards,

 

Scin