Why isn't it recommended to use BE to backup SQL2K?

[TigerDivision]

Greetings all!

We use the SQL agent for BEWS 9.1 in order to backup up our SQL2K databases. I was reading a post by SQLBill recently saying that it is not recommended to use BE to backup SQL2K databases. Why? Would like to know the reason why.

TIA
Pierre

 

[SQLBill]

Backup Exec 'may not' keep up with changes in SQL Server (updates/etc). So at any time, BE could quit working properly with SQL Server.

Case in point......I had a clustered SQL Server setup. Two nodes, active/passive, using Windows Advanced Server 2000. Backup Exec 8.6 was on the same server as SQL Server (due to lack of servers). I forget the 'build' of BE 8.6 that I had. But we were happily doing backups using BE's Agent for SQL Server. As we don't have any non-production equipment, we couldn't test our backups.

We had a crash of our server and had to rebuild them. Went to restore SQL Server databases from the tapes and 'oh - no', all kinds of errors. Finally found out that this was a known problem. If you had a specific setup (we did) and a certain build of BE 8.6 (we did), it could not backup SQL Server. We had to send our tapes to Veritas for recovery and that took 8 weeks. Luckily, since the issue was known and our vendor did not tell us about it, the vendor paid for the recovery. However, we were still out the time.

Read the fine print....Veritas does not guarantee their software will back up SQL Server (or Exchange). They can't make that guarantee as they don't know when Microsoft will make any changes to the product and Veritas needs time to incorporate any changes into their product.

It's always better to use the 'native' methods, rather than an outside parties product.

That's my opinion and why I say don't use the SQL agent.

-SQLBill

Posting advice: FAQ481-4875

 

[steveot]

I partially agree with SQL Bill. As with any software you have to keep it up to date. So assuming that the sofware was up to date Bill scenerio may have had a better outlook.

In SQLBILL scenerio he is probably a SQL person. Most people dont know what Enterprise manager is...so running a native SQL backup is sometime out of the question. Although i have seen some handy freeware and $25 shareware apps that just tap into sql and can run the sql dumps with a intelligent interface. If you really look at what Backup Exec is doing it just making the calls into sql for you.

 

[SQLBill]

Good point Steve. Yes, I should have clarified that I am a SQL Server DBA. However, if you have SQL Server, you should have a DBA for it. That person can do the backups to disk and you can copy the backups to tape.

I also agree with keeping the software up to date. In my case, we had just bought the software, installed it, were using it for a short while when the crash happened. Prior to us buying the software, the 'hotfix' came out, but we were never told about it when we purchased Backup Exec and the Agent for SQL Server. Our vendor also knew in advance that we do not have internet connection and any updates must be done by disk. They admitted after the fact that they knew about the hotfix and failed to tell us (they even had a checklist that if followed would have required them to tell us about the fix).

-SQLBill

Posting advice: FAQ481-4875

 

[justin2000]

I do agree with SQLBill, but some people not only don't have the expertise, they also do not have the disk space required to do the backup.

Take for example, I had a customer who had 3 SQL databases, all around 200gb each - he definitely had the free space on the server to let the db's grow but just wasn't enough, nor could he justify buying another 600gb of disk space just to do backups of SQL.

One thing with Veritas is that they have a notification service for any Hotfixes or other changes that come out -

http://seer.support.veritas.com/nav...scribe.asp?ddProduct=&EmailAddress=&password=

One other point, this is with Exchange 5.5.
Customer was using Backup Exec 9.1 to backup the information stores, working without issues. They did did a defrag of the databases as part of normal maintenance they do, then 1 night later he got corrupt store errors in BE. No errors were reported in the App logs, so not sure exactly at this point what it was.
Tried out NTbackup - it worked 100% everytime.
Spoke to Veritas - they were saying that the databases were corrupt in some way. the problem was ISinteg, eseutil were not coming up with any errors on the IS or Public Folder databases.
They proved the point by trying to restore a backup of Exchange made by Ntbackup - the restore would finish - but the Exchange services would not start. It was saying the logs were inconsistent.
So I had to run a ESEUTIL /P on the IS to make it consistent.

We later found out the problem was that Ntbackup was not correctly backing up the Transaction logs (it was backing up any logs). We couldn't get a straight answer out of MS regarding this problem - in some ways they denied it was their problem.