August 17, 2010 at 1:25 am
See this all depends on the value of the data... as if data is critical then you can even have 2-4 weeks of backups on your drives itself (which is more costly) rathere than putting it on tapes.
August 17, 2010 at 7:50 am
Ramji29 (8/17/2010)
See this all depends on the value of the data... as if data is critical then you can even have 2-4 weeks of backups on your drives itself (which is more costly) rathere than putting it on tapes.
Not rather than, but in addition to 🙂 - keep a few weeks on disk, and as soon as possible after they're first written to disk, get them on tape and off-site, in case you have major disk problems.
September 8, 2010 at 2:11 pm
GilaMonster (8/13/2010)
I hope it's more than once a week since you need a full backup and an entire, unbroken chain of log backups to restore to point-in-time.
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?
September 8, 2010 at 2:23 pm
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.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 8, 2010 at 2:42 pm
GilaMonster (9/8/2010)
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?unless you're using a SAN-based snapshot backup that's integrated with SQL)
The backup exec 12 website says following about those backups: "Continuous protection of SQL databases eliminates the daily backup window for SQL server and enables recovery of database transactions that have been made right up to the time of the hardware or software failure. Additionally, flexible recovery options allow IT administrators to restore SQL databases to destinations other than where they originated, directing a copy of the actual data streams being sent to media by a SQL database to a local directory for later use. The SQL Server 2008 snapshots are integrated into the Backup Exec catalog for a consolidated look at all data copies available for recovery in seconds. This agent provides SQL Server 2008 R2, 2005, and 2000 users with granular protection on 32- and 64-bit systems down to the individual database or file group."
I have also uploaded the technicalities (PDF) with SQL backups this software uses.
September 8, 2010 at 2:56 pm
Cool. So go and take one of those backup exec backups and your log backups and see if you can restore to a point in time.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 8, 2010 at 3:55 pm
While I haven't used BackupExec 12, I've had experience with 11, 10, a few other versions. I've always had issues doing restores with BackupExec, especially when I had a disaster.
As Gail mentioned, Backup Exec might work, and I hope it does for you, but I would not bet my job on it. I'd make regular full and log backups with SQL Server, or one of the non-agent based systems.
September 9, 2010 at 6:26 am
GilaMonster (9/8/2010)
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.
Rich
May 12, 2014 at 12:40 am
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 Services
Then change the location of log files
Start the Server services and makes databases offline
Place the log file in previous location
Now bring the SQL database Online
Within few clock pulse rate you can access SQL database and back to work.
SSMS Expert
May 12, 2014 at 4:33 am
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 Services
Then change the location of log files
Start the Server services and makes databases offline
Place the log file in previous location
Now bring the SQL database Online
Within 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.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 14, 2022 at 10:38 am
The EMERGENCY mode is a perused just status used to peruse information from data sets in the RECOVERY PENDING/SUSPECT mode. Basically, when a data set status is changed to SUSPECT, it becomes distant. Setting a data set in EMERGENCY mode helps access the data set and run a maintenance on it utilizing DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS command.
ALTER DATABASE database_name SET ONLINE
Prior to continuing, check assuming the data set is still in EMERGENCY mode by running the accompanying command:
SELECT name, state_desc FROM sys.databases WHERE name = Test_Database
Before to beginning the maintenance method, it means quite a bit to change the data set to SINGLE_USER mode to keep different clients from utilizing the data set.Once the database is in SINGLE_USER mode. You can repair it by excuting a DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS.
ALTER DATABASE Test_Database SET SINGLE_USER WITH ROLLBACK IMMEDIATE DBCC CHECKDB (Test_Database, REPAIR_ALLOW_DATA_LOSS)
The CHECKDB command runs successfully without any consistency errors.
Now, Switch the data in multi user mode Using this command
ALTER DATABASE Test_Database SET MULTI_USER
Refresh your database and check it one more time. I believe it will work for you. If It is not working, Please comment here.
September 12, 2022 at 4:42 am
This was removed by the editor as SPAM
September 12, 2022 at 4:44 am
This was removed by the editor as SPAM
Viewing 13 posts - 46 through 57 (of 57 total)
You must be logged in to reply to this topic. Login to reply