November 6, 2009 at 12:22 pm
As we seem to move ever closer to replacing native sql tools/backups with Commvault, I was asked to provide restore times for many of our production databases. As I thought through that, it occured to me that if commvault held the backup ( albeit proprietary ) on the NearLine device, rather than tape, the restore is direct to database, rather than restoring a native sql bak, dif or trn and THEN restoring that with native sql to a database. So might be faster.
I don't know what the capacity of the nearline is. I think typically commvault here backed up the native sql backups once a day where my backups include weekly full, nightly differential and every 15 minute incrementals -- to disk. I also have log shipping in place on one server, so it's pretty tricky to compare things. And then there is how to test without breaking the existing setup until you're ready to dump it.
One question: do my differentials and incrementals determine which full or diff they are "working from" by looking in msdb? Or does sql actually look on the disk to find the file? If it looks on disk then a test full backup with commvault ( to nearline) will cause my subsequent normal incremental ( tlog ) backups to fail.
November 6, 2009 at 3:05 pm
Indianrock (11/6/2009)
One question: do my differentials and incrementals determine which full or diff they are "working from" by looking in msdb? Or does sql actually look on the disk to find the file? If it looks on disk then a test full backup with commvault ( to nearline) will cause my subsequent normal incremental ( tlog ) backups to fail.
Ok answered my own question there, it's looking in msdb.backupfile and/or msdb.backupset But if the backup file your differential or tlog backup job is looking for isn't in those tables it won't run. Also, if it is in those tables but the correct file is missing from disk you can do the differential backup or tlog backup, but they won't restore.
I just found out we have two commvault sql agent licenses for the two main prod sql servers, but you can't restore those files to a database on any other sql server that doesn't have the agent installed.
February 3, 2010 at 4:01 pm
Just found this thread. My understanding ( for Commvault ) is that the backups are not native sql backups and you can't be doing native sql backups if you have a chain of full, differential,incremental backups running from the 3rd party tool. You'd break the chain.
Aside from having a barely-interested systems person running the Commvault GUI, my objection is that various people copy and restore production backups to DEV sql servers regularly. They won't be able to do that unless you install the iDataAgent on the DEV servers and expand access to the Commvault GUI.
Viewing 3 posts - 31 through 32 (of 32 total)
You must be logged in to reply to this topic. Login to reply