Backup Exex 8.6 and SQL Server

[SQLBill]

I just found out the hard way that BE8.6 has a known (by Veritas) bug when backing up SQL Server. Check your 'build' of Veritas BE 8.6. If it is build 3808, your tapes WILL NOT work for restoring the SQL Server database(s). You MUST have build 3878 and HOTFIX 4. But it's not retroactive, in other words once you apply the proper build and HOTFIX, your tapes prior to that still won't work. If you really need the data from those tapes, you need to contact Veritas and see if they can recover it for you.

So, I learned the hard way....hopefully anyone else using these two products together can learn from my mess.

-SQLBill

 

[SQLBill]

Has anyone else had this happen? Did you have Veritas recover your tape(s)? If so, what was the process (did you have to send them the tape(s), did they send you a recovery program, or did someone from Veritas come out to your site and do the recovery)?

-SQLBill

 

[sgifargis]

I have had that happen but, is it worth it at that point when you need the information "yesterday,"
I just took the SQL backups(non-veritas) and converted them over to SQL database's. I lost a days work but that was recovered but scripts I had running for transaction logs..
You need to do more data redundancy than rely on just tapes....

I really doubt that they will recover it for no - or little cost to you.....

But keep us posted

 

[polymath5]

Thanks for the info! I'm guessing you are talking about the backups with the SQL agent and not just BENT 8.6?

I don't use the agent at all. I let SQL do it's normal backup and then backup the BAK file to tape.

If I need to restore the db for some reason, I have the BAK file on disk, so it's a MUCH faster restore than trying to pull off of tape. And it works every time.

I've never seen a reason for using the agent. Perhaps someone can let me know if I'm missing something? =============
Mens et Manus
=============

 

[SQLBill]

Correct, this is just for backups using the BE 8.6 SQL Agent. I was in the process of switching methods and beginning to do backups via native SQL Server backup commands and then copy that .bak file to tape. However, as I was just seeing how it works and which was quicker, I never got a backup of all the databases. Plus since I had a hardware failure, all of my files on the disk appeared to be corrupt.

However, I did find that one of my 'test' backups to disk may not be corrupt. I started restoring it (192+ GB) and it's going on 12 hours of restore. I'm not sure how to tell the progress of the restore so I don't know if it's close to done, got a long ways to go, or getting messed up.

BTW-Veritas' recovery method is: they send you a non-disclosure agreement (NDA), you sign it and send it back, they sign it and send it back to you. You send them the tape(s) and tell them your hardware configuration. They build a server similar to yours and recover the tape(s) which might take days.

-SQLBill

 

[polymath5]

Thanks very much for posting the details on Veritas' recovery method. What the hell could be in a NDA about restoring your data? (I know you can say )

Unless it's something like you can't tell anyone that Veritas couldn't do it...

It does sound like a good service when you need it. I would hate to have to rebuild a database your size! =============
Mens et Manus
=============

 

[SQLBill]

The NDA is to protect you NOT Veritas. It's their agreement to not disclose any information they might see while recovering your data. Remember, they have your tape so they can do what they need to do.

-SQLBill

 

[chriscallan]

Is this issue exist for SQL 7.0 as well?

 

[SQLBill]

No, according to Veritas' site, it's only between BE 8.6 load 3808 or 3878 and SQL Server 2000. You must have build 3878 and HOTFIX 4 applied.

-Bill

 

[polymath5]

Well that makes a lot more sense (smacking head). You get a star from me for the heads up on the need for the hotfix/build tip! =============
Mens et Manus
=============

 

[SQLBill]

By the way, the information on this problem and the HOTFIX is on Veritas' web site. It's in TECHNOTE ID: 246346. And I should have added that this affects clustered MS SQL 2000 databases. There's a list of conditions that will affect this.

-SQLBill

 

[jamkey]

Before anyone panics in reading this thread, these are the conditions for this defect to arise and require tapes to be sent into Veritas for recovery (as per the technote):

-- SQL and Backup Exec were installed on multi-processor servers.
-- SQL was installed as a cluster aware application.
-- Backup Exec was installed either as a cluster aware application or on an individual node on the cluster (a non-cluster aware installation).
-- SQL and Backup Exec were both active on the same node at the same time the backup was performed.
-- Uncle Gus let one loose in response to a full moon at the time of the backup...

OK, so I added that last one for effect... But you get the idea. Its not as if this effects every customer with 8.6 & SQL, or for that matter every customer with 8.6 & SQL 2000, or for that matter every customer with 8.6 & SQL2k as a Cluster aware istall, or for that matter... I'll stop. Point being, DON'T PANIC! Even if you meet all these conditions and can't implement the patch right away due to change control policies, simply insure that BE is not active on same node that SQL is active on during backups, or use SQL enterprise manager (EM) dumps for the time being.

Also, polymath5 asked why the SQL agent would be necessary as opposed to using the SQL EM dump. Well, one reason might be if the database is more than a few gigs, such as 100+GB. Of course if its preferred to keep over 100+ GB of hard drive space handy for SQL dumps, then more power to ya! But then I got one word for ya... or a few... Natural/Terrorist Disaster. Dumps to hard drive don't help too much when the whole building is gone.... or underwater... or in flames. But tapes taken off-site do.

 

[polymath5]

Hi Jamkey,

Thanks very much for pointing out the specifics of the problem. That makes it a lot clearer, especially the last one

I think you missed the part where I said I backed up the dumps to tape.

In fact I do have the spare HD space available. Hard drive space is cheap, compared to data and down time. I dump to the local HD and to another server. Both server dumps get backed up to different tapes for redundency. These tapes are taken off-site daily. So I keep the dumps locally which are much faster to restore than the BE agent backup on tape. And if I need to restore a previous tape, no problem as it's still faster to restore the dump from tape and restore from that, than from the BE agent on tape.

I use Double-Take (Great Product) for online offsite backup to a redundant SQL server box and to a offsite BDC though a dedicated point to point T1.

We keep a couple of workstations offsite that are updated as our client configurations are updated. So if we do have a disaster, I go to our hardened off-site location, take the servers and workstations to an alternate spot and I'm up and running. The workstations would be ghosted to as many workstations we would need under emergency conditions.

I test this DR strategy at least twice a year and so far it's worked well, though the testing is sure a pain in the ass!

So as far as the few words go: Got it covered. =============
Mens et Manus
=============