November 5, 2009 at 5:51 am
I'm looking for more arguments about 1) DBAs retaining backup/restore responsibility ( as opposed to a System/network team member who is only somewhat engaged ) and 2) the downside to tools that don't create native sql backup files, in this case the Commvault sql agent.
I'm arguing against adoption of this. For one thing it locks you into the use of their GUI and you couldn't use any normal sql commands or tools to restore the files -- the files go direct to the Commvault Nearline device, and then to tape so it does save space on our SAN. It would also break log shipping which we have in place on some databases.
November 5, 2009 at 6:28 am
The problems with any backup tool is that if it breaks or you lose your license, you have all these backups you may not be able to restore if the software doesn't have a free conversion tool.
I don't use Commvault, but I do use Litespeed. Litespeed has a tool with which you can uncompress (and return to native SQL format) a backup. I've used it several times and I'm pretty sure if something happens to Litespeed, we will still be able to use the tool.
Responsibility-wise, a good backup & disaster recovery plan is always the responsibility of the DBA. The DBA should be making regular backups of the database (which ever plan or tool is used). Beyond that, the network backup team should be responsible for taking backups of the share drive where the SQL backups reside. This way you can keep SQL backups for longer, take advantage of tape backups & off-site backups, and still retain space on your local server for only the needed most recent backups.
November 5, 2009 at 6:50 am
My thoughts exactly Brandie. I'm recommending that I be allowed to test the Commvault GUI/backup product for a while, but that the responsibility should remain with someone who is familiar with sql server and dedicated to it's viability, not a network tech who is multitasking a number of responsibilities.
I'd love to have something like LiteSpeed but at the moment the only tool in the budget is a performance tool. I need to see if the Commvault agent can handle log shipping also, since that's in place on some databases and having another product do backups would probably break the native sql log shipping.
November 5, 2009 at 7:01 am
If you're the network tech, why are you responsible for the log shipping? I would think that it (and testing backup software) would be the responsibility of the DBA team.
Unless these are "production" DBAs who are only allowed to touch the databases themselves and have no power outside of that?
EDIT: I suppose the real question is, what kind of DBAs do you have in your organization?
There are different types of DBAs and not all of them have the broad responsbilities I'm used to having.
November 5, 2009 at 7:31 am
I'm not the network tech. I'm a production support person who has been filling in as the "DBA" for years. We are approaching the time where two of us will have a more formal DBA role in the production area ( probably not too much in the database design realm). I was saying that the junior network tech should not be the person who runs the Commvault backup tool or is in any way responsible for backup/restore of sql server data.
I've sent my arguments in to management, proposing that I test the Commvault tool but that my preference was to stay with native sql backups. Hopefully I'll have enough ammunition to win the argument.
November 5, 2009 at 7:44 am
Ah, I misunderstood your post.
Good luck with the battle.
November 5, 2009 at 8:19 am
Looks like log shipping may be possible with Commvault, but seems messy with agent installs etc. http://documentation.commvault.com/commvault/release_7_0_0/books_online_1/english_us/features/disaster_recovery/cs/cs_sql_separate.htm
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply