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.

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.

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.

We've tried CommVault SQL Server agent backups, but decided to go back to the SQL Server native backups which backed up later as .bak files using CommVault.The main reason was that it's too hard to build disaster recovery strategy with CommVault backups. Other reasons:- backups don't start at the same time (with CommVault backup model that our backup guys provided backup could start at 9 PM or 3 AM next day)- possibility of human error when restored by non-DBA (as in last Indianrock's post)- possibility of extra backup that can break recovery strategy when differential backups used- additional CommVault licenses on all servers where database restore required- we didn't have enough people trained well on CommVault, so if primary backup person wasn't available it was not easy for other guys to restore the database, so we ended up with granting most of the permissions on CommVault to DBA (on Database servers group)- also, I didn't get good answer from our backup guys on my question: "What if CommVault server will fail? How long will it take you to recover/rebuild it?".

I had been worked on CommVault a while, and as a DBA, I think CommVault is working well for SQL 2005, but not for 2000, and no advantage for SQL 2008 since SQL 2008 can compress backup itself.

For the Dev refresh requirement, you may want to create CommVault script, and then create job on SQL, and then grant permission for developer to kick out job. This is complicate process, but can be done. CommVault "online help"(big red button on CommVault Concole) will be the only resource you can use, and their support team is useless on this issue.Basically, you will have one command file and one input file on hand, which can be edited, and you can do point to time restore on different server.The Cons are you have to have a CommVault user account to run this, and destination database name can't be changed.

I also do not think you can do object level restores with the Commvault product. If you just need to restore one table you first have to restore the entire database. Our network administrators are trying to get us to switch to Commvault. We are quite happy with our Red Gate SQL Backup product which was designed specifically for SQL backups - not some add on product which was created to sell more Commvault licenses. Oh yeah - and deduplication of my SQL backups makes me nervous. If I do a full backup each night - I want a full backup.

So far every comment above I find no fault in our experience and would highlight that we do NOT allow Commvault to perform anything but file backups and rely solely on SQL for native .bak backups etc. Our only issue is timing with VM snapshots from time to time where IO is frozen.

One side issue [bit off topic] is we are experimenting with Commvault for Oracle and to tell you the truth it has some nice features but getting it to work was an entire learning experience layered on the even simple DR mode.

I want things simple reliable and up to very complex in the toolbox: SQL Maintenance plans and backup/restores and migrations in a very large [over 100 servers with over 60 dbs each] in active-active yada yada many styled environment means: Simple, quick, reliable...stick with the one vendor who controls the engine.

Commvalult for us is great for massively large file backups but wouldn't want to go there for dr recovery, at night, in the rain, flood waters rising etc