February 6, 2010 at 9:40 am
I'm pretty sure if you have a log chain in your commvault backups ( full, differential, incremental/Tlog backups) you don't want to also backup with Management Studio or any other "native" approach. I need to know if commvault writes sql backup files to it's own storage device in a proprietary format that cannot be used by native tools for restores.
This will have a large impact on our development team. Among the concerns is who has access to the commvault GUI and will have to do all of the backup/ restore work. Commvault does offer us the potential advantage of removing hundreds of GBs of backup files from our SAN as well possibly faster backups than native sql.
I went to the Commvault user forums I could find. One had no recent posts on the sql IdataAgent ( none in the last 6 months), the other had no forum dedicated to this topic.
February 6, 2010 at 10:44 am
I have not used this agent before, but having used various third-party tools for backups my guess would be that the format is proprietary and can only be restored using their tools.
This puts all of the responsibility on the group that supports CommVault - and removes that same responsibility from the DBA's and developers. If you have a good relationship with that team, and define the SLA's appropriately it really shouldn't be a problem.
Where it becomes a problem is when that relationship doesn't works and/or that other group cannot meet the defined SLA's. Then you'll start to see the DBA's and deelopers building up their own set of backups and keeping them online and available so they don't have to wait for the other group.
If you have a requirement to have those backups available - and that cannot be done in a timely enough matter, then maybe that is not the right solution. Just remember, you also have the option of performing COPY_ONLY backups for moving data from prod to test to dev, etc...
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
February 6, 2010 at 4:55 pm
Thanks, I'd forgotten about the copy_only backups. Based on what I've found in the way of Commvault forums dealing with sql server, it doesn't appear to be widely used.
February 6, 2010 at 6:58 pm
Indianrock (2/6/2010)
Thanks, I'd forgotten about the copy_only backups. Based on what I've found in the way of Commvault forums dealing with sql server, it doesn't appear to be widely used.
Yeah, I have not found them to be widely used either. The general consensus is to backup to disk using native tools (or compression tools like Hyperbac, Litespeed, etc...) and then use CommVault to put those backups on tape.
The advantage is that you can keep a version online and available - while making sure you have your offline copies saved on tape for your long term and disaster recovery storage.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
February 7, 2010 at 11:58 am
I'll chime in as well. DO NOT USE Agents. Some work, some don't, but I've had issues with a few and it's not worth it. The convenience of their doing the restore is not worth the risk that their agent will have some issue.
Back up to disk, and then use any tape software you want to grab those files. Most (all?) of the third party compression utilities for backups allow you to use a command line utility and uncompress the backup to native format, so SSMS can do a restore.
February 8, 2010 at 9:25 am
For our SAP environment we are utilizing CommVault 8 with the SQL idata agent installed on the SQL machine.
The systems (SQL servers) are all running 2008 enterprise.
The CommVault 'system' is better than our previous method of maintaining backups but it can seriously jam you up if you run into an issue with configuration / management / space...
It has been a real learning process for me in particular using this software...we (the DBA's) are in a position where we are not 'administrators' of the system but are power users so we still have to rely on another group for changes and guidance.
We are still working out some bugs in our process and the system in general but like I said it is the lesser of two evils in our environment.
Currently we are backing up close to 14 Terabytes across all servers (production and non-production) weekly...which is tough to keep up on.
February 8, 2010 at 10:03 am
Well like they say, the trick is whether your backups will restore. I think we only have two Idata Agent licenses so we might need to use the copy_only sql backup to satisfy the needs of our development group.
Do Idata Agent sql backups complete in less time than native sql backups? Are all of yours kept on a commvault near-line device, or otherwise not taking up space on your production disks? Those last two are the main reason our Systems Team is considering Commvault for sql backups.
Lastly, can you restore from commvault to a native sql bak file if desired?
February 8, 2010 at 10:29 am
The hardware we have running our SAP implementation far surpasses anything else on our legacy systems so to try to compare wouldn't be fair.
I can tell you that we can get anywhere from 80 to close to 300 gb/hr throughput on a backup. Which is nice when you are backing up 1/2 tb db's in under 2 hours.
The restore process appears fine if it is on disc, however I believe if we had to pull something from tape it would be a quite lengthy process...
I am not sure regarding your last question, The only way we have been able to do backup and restores (at least the only access we have been granted) has been to do the backup in CommVault and restore to another server). If the files are on disc vs. tape then the process is pretty slick and pretty fast IMO. I recently had to restore a db from tape, and it was a very slow process.
As far as are retention policy on disc we are still working on that, currently we are trying to have 2 cycles on disc (14 days) for production.
February 8, 2010 at 11:39 am
"The only way we have been able to do backup and restores (at least the only access we have been granted) has been to do the backup in CommVault and restore to another server). "
What happens normally when you restore, does it restore directly to a sql database, or to a file that must then be restored to become a database? One would think there would be a Commvault option to restore a Microsoft Tape Format standard sql BAK file. However, as mentioned above, there is the COPY_ONLY method of making a standard sql backup file without breaking the log chain created by commvault backups.
February 8, 2010 at 11:47 am
In our current process / product when you restore a database to the same server or another server you are prompted with a source and destination server, I haven't seen an option to 'dump' that backup to a file location and then use code outside of CommVault to utilize that backup file.
The caveat is you need to have a license on both the source and destination in order to perform the restore on the other server via CommVault.
The restore process is painless, I haven't had to get very selective with the options (P.I.T.), our restore process has been mainly for refreshing test systems.
February 8, 2010 at 11:55 am
We won't have a commvault SQL Idata Agent license on any dev boxes, so to get copies of the production DB there we'll have to jump through other hoops. From what you said, commvault restores from it's storage device directly to database.
February 8, 2010 at 1:22 pm
One of the advantages of using the Commvault Idata Agent ( or agents like it ) would be if you no longer had to use space on your production disk hardware for sql backup files. ( netapp in our case) However, since we won't have an agent license on any of our DEV sql servers and those DEV sql servers are at our office, not at the Raging Wire server facility like our prod hardware, I would have to do a native SQL "copy_only" backup somewhere, possibly over a link to our office that isn't super-fast. Or perhaps do that copy_only backup to one of the prod sql servers that had space ( several hundred Gigs)
Or we would have to restore a commvault backup to a database on one of our prod sql servers, detach that and copy it to a DEV sql server at our office. I still have not gotten a definitive answer as to whether commvault can write out a Microsoft Tape Format standard sql BAK file.
May 4, 2010 at 7:02 am
How can we compare CommValut with Litespeed. we are trying to migrate from Litespped to Commvalut hoping that will improve backup-restore time and also backup compression, does it make any sense ?
May 16, 2010 at 8:17 pm
Can some one please flush out some drawbacks of CommValut IDataAgent ?
May 17, 2010 at 12:28 pm
The two main reasons I don't like it are 1) now that our Systems team handles backups/restores with the Commvault product, you have folks who are not Database Professionals attempting to master another tool in their "spare" time. And these guys don't even want to open Management Studio so they are separating themselves from Sql Server itself. I've already seen some problems from this. For example, during a conversion we switched from Full Recovery to Simple and the commvault "wizardry" automatically started a differential backup -- I guess it presumed this is what we wanted although the database was quite busy and it wasn't want we wanted.
2) It inserts a layer between the user and SQL server. The commvault commands show up in the sql log, but can be misleading -- after resuming full recovery in the scenario above, I saw log backups resume after the post-conversion full backup, but we found out the next day Commvault would not in fact restore those transaction log backups. So we went all day Monday without log backups running.
Some of this is just a training issue.
Viewing 15 posts - 1 through 15 (of 25 total)
You must be logged in to reply to this topic. Login to reply