November 10, 2009 at 10:34 pm
Hi,
We have 5 sql servers runs on windows 2003/SQL 2000/SQL 2005 environments. We do have our own maintenance plans. We do push the backups to SAN and then to tapes.
One of the vendor somewhat convinced our IT manager to install Symantec Backup Exec on our SQL servers to take backup. I told them No. but i want to hear the gotcha on the agents installed on SQL server. Our business is 24 hrs and heavy OLTP application.
Or, is it good to have the agents installed? will it help me in day today maintenance?
Thanks in advance.
November 19, 2009 at 9:09 pm
You have to decide which you want to do. Issue with direct to tape, one it is slower than direct to local disk. Two, if you have a tape failure your backup will abort. Third, if there is a network failure or even a minor hiccup the backup will fail (same as doing a direct to disk backup over the network.
Direct to local disk is faster, allows you greater flexibilty in moving the backup files to other media wether off-site electronic store, SAN, or tape.
Also you need to consider who becomes responsible for testing the backups, restores, how quickly can the tapes be retrieved. And I'm sure that others may have more to add to this as this question has been asked numerous times on SSC.
November 19, 2009 at 9:20 pm
Not a real fan of the BE SQL agent. Backup Exec is fine for doing the operating system and file systems. I have seen it cause performance woes.
I would rather backup to disk and then backup the SQL Backups to tape. Doing this adds a level of comfort and allows me to still control and test the SQL backups.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
November 19, 2009 at 9:39 pm
I don't know how sophisticated the product is now, but when I first started working in one shop they had a couple of critical servers set up using this, I asked that we use native and was told not enough disk space. put my missgivings in a mail to all stake holders. It wasn't until the box died, the raid was hosed and it turned out that the backup was hard coded into some config file that heads rolled. New database(s) where not added or caught in the config, so critical DBs where not backed up. Spent the weekend settting DB(s) from suspect to emergency bcp-ing stuff out and scavenging QA\DEV\Stage data to get it back working. Suffice to say new hardware and disk space was purchased asap, the straight to tape agent removed and the windows lead who championed the method strangley departing. My two cents.
Andrew
November 19, 2009 at 9:43 pm
I'll second Andrew's experiences. It's been a few years (6-7), but I worked in one place that had it and ran into it twice while consulting. In all three cases I had issues restoring a database back through the agent and data was lost.
Tell the salesman to keep it and tell your manager it's not worth the risk. Do your backups to disk (for Lynn's reasons) and let Backup Exec pick up the files like any other files on a file server.
November 20, 2009 at 1:04 am
Thank you all.
November 20, 2009 at 1:20 am
Steve Jones - Editor (11/19/2009)
I'll second Andrew's experiences. It's been a few years (6-7), but I worked in one place that had it and ran into it twice while consulting. In all three cases I had issues restoring a database back through the agent and data was lost.Tell the salesman to keep it and tell your manager it's not worth the risk. Do your backups to disk (for Lynn's reasons) and let Backup Exec pick up the files like any other files on a file server.
The experience is very nice piece of the knowledge power, so I'm planing to make a backup strategy with Symantec Backup Exec 12 and here I find little experience that will be useful info for implementing Symantec Backup Exec.
Thanks for info Steve!
:hehe:
November 20, 2009 at 8:30 am
You're welcome, Dugi. It's been a long time, but Backup Exec has off my list for those old reasons. The restore process is relatively simple now and I see no need to use the agent.
November 22, 2009 at 1:07 am
I use Backup Exec for many of our customers, and have so from version 9.6 straight through to 12.5 (current) so I feel the need to put in my two cents worth on this one. I like using Backup Exec for backing up SQL Express databases, as well as Windows servers, virtual servers, and Exchange. Using it to backup large, busy, full versions of SQL takes too much time to setup and seems like double duty when you're doing all other DBA maintenance tasks in SQL Server. Also, having Backup Exec licensed for a single drive means you can only run one backup job at a time. This could be a show stopper for some places.
That being said, I feel the need to defend Backup Exec just a little. You can back up to disk with Backup Exec, no need to go straight to tape. You can configure 'Backup to Disk' devices in Backup Exec and use a Disk to Disk to Tape method. As far as how the SQL Agent performs, I'm not 100% positive, but I think the SQL Agent uses SQL Server to do all the work. Just makes the interface more Windows System Admin friendly. You can configure it to leave behind copies of the SQL backups on the server. And you can perform Full, Diff, Trans Log, and Copy Only backups.
The one problem I have gotten myself into is backing up databases using both SQL and Backup Exec. Since neither was doing a Copy Only backup (it was a SQL 2000 database) my transaction log backups made by SQL followed a Full backup by Backup Exec, which ran a few hours after the Full Backup done by SQL. That caused a few moments of confusion and forced me to have to locate and load the correct tape to restore the full backup from so my backup files would be in sequence.
All in all though, I have to agree with the others on this post, for the most part. I think a place that pays to have a DBA on staff should leave the database backups to the DBA. Let the Backup Exec jobs backup the SQL backup files and save yourself the cost of those SQL Agents.
Phew, that was a lot of words.
Steve
SQL Managed
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply