Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase

COMMVAULT and backing up SQL Server O\S Level Files Expand / Collapse
Posted Thursday, August 7, 2014 2:14 PM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, September 29, 2016 1:59 PM
Points: 376, Visits: 503
We are running SQL Server 2012 on Windows 2008 Server. The DBAs have been asked to identify files that should be backed up to COMMVAULT. (I am not sure of the purpose for COMMVAULT yet, for example, will these backups be used in case there is a hardware failure, software upgrade problem, etc.) We have a Disaster Recovery Solution (redundant servers in another location using Equalogic to replicate backups from production SANs to Disaster Recovery SANs.)

My question is what type of files should we backup to COMMVAULT? I am thinking the C: drive, registry, sql server software directory, sql server backup file (.bak), etc.

Can the SQL Server online database files (.mdf and .trn) be backed up? Do you have to stop the SQL Server Services in order to back up these files (the data and log files)?

Also, has anyone used COMMVAULT? Does it communicate with SQL Server? For example, via an API?

Just doing some early research.

Thanks, Kevin

Post #1600875
Posted Friday, August 8, 2014 11:31 AM


Group: General Forum Members
Last Login: Today @ 11:10 AM
Points: 122, Visits: 1,176
I think the request is to identify where your SQL DB Backup files are located (hopefully you do backup your Databases). To backup the .mdf .ldf etc files SQL will have to be stopped as they are in use.
Post #1601288
Posted Monday, August 11, 2014 12:45 PM



Group: General Forum Members
Last Login: Thursday, December 1, 2016 2:17 PM
Points: 1,772, Visits: 10,711
I would suggest having the Commvault admins configure it to skip your MDF / LDF / NDFs, and only back up "normal" files. Additionally, you can likely have them set things up so your BAK / TRN / DIFs get backed up more frequently than the other files.

Where I work, we do use Commvault, and it can "speak" to SQL for backups. The nice part is, it uses an Agent on the SQL server (OS level, not in SQL) to run a normal "BACKUP DATABASE..." command in SQL. The backup gets routed to a "virtual device" which funnels it across the network to the Commvault back-end.

Downside to this method is the usual, if your network has a flaky moment, you could have problems with the backup, although CV will "auto-resume" the backup. Not sure if it completely restarts though.

I have had to restore some backups from CV, it has checkboxes for all the usual options (overwrite, recovery / no recovery, point-in-time, etc) and works reasonably well. Not as fast as a restore from a local file, and (that I'm aware of) you can't restore from CV to a MDF / LDF without it being attached to SQL, nor can you get a BAK out of CV...

Post #1602023
Posted Wednesday, August 13, 2014 11:49 AM



Group: General Forum Members
Last Login: Today @ 5:04 AM
Points: 1,532, Visits: 3,644
It all depends on your disaster recovery strategy and if these servers are database servers only or serve as the application code server as well.

We are just beginning to implement COMMVAULT here. We have it backup the live SQL Server databases then Step2 is to backup closed files on the server.

Post #1602916
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse