Backup Exec SQL Agent Debate

[pgaliardo]

I've seen posts on this subject before, but I'm trying to gather as many facts and experiences as possible.
We always used Backup Exec with the SQL Agent to backup our SQL 2000 databases.
We recently upgraded to BE 10.0d and SQL 2005 64 bit. Long story short, we can't get the BE 10 SQL Agent to see our databases. Veritas has been no help. What I am doing is running native SQL Backups to disk, then backing up the .bak files to tape with Veritas. I have enough space to do SQL backups and I keep them for a week before overwriting. If I need to go back further, I have the .bak files on tape.
My thinking is that this is actually a better solution, because I think a restore would be faster from the disk using SQL Backup and Restore.
We are currently debating on whether or not to even renew our Veritas SQL Agent License when it is up for renewal.
What are the pros and cons to what I am doing and how does everyone else manage their SQL backups?
Thanks in advance for any advice.

 

[mrdenny]

Currently we do it both ways, to disk and to tape.

Personally I prefeer going directly to tape and bypassing the disk. Most places when they backup to disk, backup to the same disk that the database sits on. They then backup to tape when time permits. This defeats the purpose of backing up at all as you've got a large window when the backup can be lost (the time between the SQL backup and the tape backup).

The amount of time to restore from tape will depend on the number of tape drives you have, and how long it takes for the robot to get the tape into that drive.

At a previous place restoring from tape took the same amount of time as restoring from disk. This was because we had a large number of tape drives and during the day there was usually a tape drive free to use for restores.

As long as a tape backup solution is scalled correctly you shouldn't have any problems backing up directly to tape. You will start running into problems when you don't have enough drives to backup to and your backups have to wait for a tape drive.

Denny
MCSA (2003) / MCDBA (SQL 2000) / MCTS (SQL 2005) / MCITP Database Administrator (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

 

[pgaliardo]

Thanks for that Mrdenny. My bigger concern is not so much whether to tape or disk, but whether you use 3rd Party Backup, specifically, Backup Exec with the SQL Agent of if you use native SQL Backup. I do a SQL Backup to disk every night and then that disk is backed up to tape a few hours later. This all came up as a result of the Backup Exec Agent not working. So I am debating as to whether I really need the agent.

Thanks.

 

[mrdenny]

We use the agent here on some or our servers to backup.

Keep in mind that the agents are still using the T/SQL BACKUP DATABASE command.

What they do is create a virtual backup device in SQL which points to the tape drive on the changer. It then issues a backup database command using the backup device that it just created.

Denny
MCSA (2003) / MCDBA (SQL 2000) / MCTS (SQL 2005) / MCITP Database Administrator (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

 

[hammamet]

This is a little alarming as we're looking to upgrade to V10.0d, specifically because V9.0 can't backup SQL2005 but we have too many databases to back them up to disk and then to tape. Have you resolved the issue with not seeing the databases?

 

[pgaliardo]

Not yet and it's getting frustrating. I have a case open with Symantec and they keep e-mailing every couple of weeks asking if it's resolved, as if by magic it will resolve itself. I tell them the issue is still open and that's the last I hear from them for another few weeks.

 

[Steffi1013]

Has this ever been resolved? We are getting ready to go to V10 because we are upgrading to SQL2K5 very soon.

 

[pgaliardo]

Not resolved. I've resorted to just backing up to disk via SQL Backup and then backing up the .bak files with Backup Exec. Let me clarify that this is happening on SQL 2005 64 Bit on a Windows 2003 64 bit cluster. I don't think there is a problem with doing a simple SQL 2005 backup. The problem lies either with the 64 bit, cluster or a combination of both. Symantec has been NO help.

Thanks.

 

[SQLBill]

I believe that no one should ever use a third-party agent to backup SQL Server - unless it is absolutely necessary. Backup to disk using SQL Server commands, then copy the backup file to tape.

Why? Because vendors do not have the ability to keep up with product releases. Ask you vendor how long it takes to support a new version. Veritas told me that it takes them 6 to 18 months to support new versions (even just service pack updates) of SQL Server. Their agent MAY continue to work with new versions, but they can't guarantee it for a few months. Vendors need time to check the code and test it. I have never dealt with any vendor that said they could support their product with the latest version of another vendor's product the moment it came out.

Do you want to have to hold off updating SQL Server until Symantec (Veritas) confirms their Agent will work with the new version?

-SQLBill

Posting advice: FAQ481-4875

 

[Catadmin]

Good point, SQLBill.

Here's another point to consider on this issue. We use Litespeed to compact our SQL Backups at work. It saves us harddrive space and makes moving backups across the network really easy.

The problem? It integrates so tightly with SQL Server that a server without Litespeed on it can't read the backup files to do restores. Okay, Litespeed does have a command line utility to uncompress the backup, which then makes the backup readable by SQL Server. However, if anything ever happened to our Litespeed utility and Imceda refused to help us out (or went under as many software companies are prone to do), we'd be screwed.

How's that for panic-inducing? @=)



Catadmin - MCDBA, MCSA
"No, no. Yes. No, I tried that. Yes, both ways. No, I don't know. No again. Are there any more questions?"
-- Xena, "Been There, Done That"

 

[pgaliardo]

Great points everyone. I had a trial version of a backup product by Redgate. It was lightning fast and compressed the files, but as of yet, we have not bought it. I don't know, I just feel safer with native SQL backups, partly because of some of the reasons Catadmin brings up.

 

[Catadmin]

Just an FYI to add to my earlier comment.

To be completely fair, my company actually hasn't had any serious problems with Imceda. They are fairly nice and their tech support is pretty decent. They also track all known issues with Litespeed on their website via Knowledge Base kind of database. I don't want anyone to think I'm dissing them or their product.

The only situation I ran into was with one particular Tech who wasn't actually listening to what I was telling her when I called with a problem. This was quickly resolved when I asked to speak with a supervisor and it turned out the whole mess was just a communications issue.

Other than that, though, Imceda does look to be here for the long haul, their product is very good, and it's saved us a lot of time and HD space.



Catadmin - MCDBA, MCSA
"No, no. Yes. No, I tried that. Yes, both ways. No, I don't know. No again. Are there any more questions?"
-- Xena, "Been There, Done That"

 

[mrdenny]

These days storage is cheeper than all the Lightspeed licenses. They've tried to sell me on there software several times. Normal BACKUP DATABASE commands are just fine. I can only imagine what they would charge me to license all 50 SQL Servers.

Denny
MCSA (2003) / MCDBA (SQL 2000) / MCTS (SQL 2005) / MCITP Database Administrator (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com