yessen (9/8/2010)Well my sysadmin uses backup-exec software to save the mdf and ldf files every day, which is not the full backup of the database. If lets say everything crashes, will I be able to recover within 15 minutes of time if I have mdf and ldf daily copy and unbroken chain of log backups?

There's a good chance you won't be able to recover anything with that 'backup' strategy. SQL locks those files while it's running which means they are not accessible. While some backup software can read through file locks, the common result of doing that is backed up database files that will not attach or are corrupt when you go to recover.

Without a full backup (the result of BACKUP DATABASE ... TO DISK), log backups are completely useless (if they'll even run at all)

Stop backing up the mdf and ldf (unless you're using a SAN-based snapshot backup that's integrated with SQL) and put a proper backup plan in place - full and log backups at regular intervals. Let the sysadmin copy those backup files elsewhere for retention and tell him to exclude all the sql database files from the backup tool.

At the risk of sounding a "me too" (but taking that risk if it saves your bacon someday):I've found the usual commercial network backup software applications (Backup Exec, Yosemite) to be extremely unreliable for backing up SQL databases. As Gail Shaw pointed out -- and hers is some of the most thorough and experienced advice you'll get on this entire website -- SQL Server locks the files and interferes with commercial backup software. I've encountered service errors in the Windows event log, un-backed-up files, and even worse: aborted backup jobs.

All of the commercial packages have some kind of add-on or module that claims to allow you to perform live backups of SQL Server. I've never had any luck with them. I won't bet the integrity and security of my company's digital lifeblood on software I don't understand and cannot make work.

Again, to echo Gail's suggestion: test and restore and test some more. If it works, it works. If not, use SQL to back up your databases to disk, then use BackupExec to back up those SQL backup files to tape.

Here are few steps by which you can drive out your SQL database from recovery mode and perform action on it.First step is to stop the SQL ServicesThen change the location of log files Start the Server services and makes databases offlinePlace the log file in previous location Now bring the SQL database OnlineWithin few clock pulse rate you can access SQL database and back to work.

Elliswhite (5/12/2014)Here are few steps by which you can drive out your SQL database from recovery mode and perform action on it.First step is to stop the SQL ServicesThen change the location of log files Start the Server services and makes databases offlinePlace the log file in previous location Now bring the SQL database OnlineWithin few clock pulse rate you can access SQL database and back to work.

Excellent waste of time, won't do much else.

If you were to follow that recommendation, then when SQL restarts it will mark the databases as recovery pending, because of the missing log. Take it offline, replace the log and bring it back online and SQL will run recovery on the database, from the very beginning. So if you were to do that after the DB had been in recovery for 4 hours, after doing that it will be back at the beginning of recovery, with 4+ hours to go. It definitely won't come online immediately.

Please refrain from posting advice on database recovery if you're not familiar with how SQL behaves.