> How to > Backup Utility > SQL Server disaster recovery plan

SQL Server disaster recovery plan

Updated on Dec 14, 2017 by Brithny to Backup Utility

Summary:
SQL Server disaster recovery plan to recover SQL Server from SQL Server backup using SQL backup software. Free download EaseUS Todo Backup Advanced Server supporting SQL Server 2008(R2)/2005/2016.

After completing the process of installing and configuring Microsoft SQL Server, have you taken the time to develop a contingency plan to cover unforeseen catastrophes that might threaten your database in the future? Disaster recovery is all-too-often ignored until it's too late. Busy database administrators can easily push this task onto the back burner with promises to themselves that they'll "take care of backups right after I finish this big project." However, take a moment and consider the value of your data to your organization? What would be the result if an hour's worth of database changes were lost? A day's worth? What about a complete loss of the database?

Backup SQL Server with SQL backup software and have a SQL disaster recovery when needed.

SQL Server backup software

MS SQL backup software - EaseUS Todo Backup Advanced Server provides MS SQL backup and recovery solution to create backups and restore the database from SQL backups. With this backup software, you can backup SQL database with full backup, differential backup, transaction log backup. Backup schedule to backup SQL Server daily, weekly or monthly also allows automatic backup of the database. Database backups can be saved to the local hard drive or removable data storage device or tape. See Backup SQL to tape or Backup SQL Server to hard drive) For more information, see how to backup and recover SQL Server database?

SQL Server disaster recovery plan

Disaster Recovery Planning for SQL Server

The following is an example for sites that do not operate on a 24-hour basis (that is, sites that have available maintenance windows): To prepare for disaster, do the following every day (or whenever the maintenance window is):

Shut down SQL Server.
Copy all database device files, preferably to another computer in another building (but beware of network load), and also to a tape device (with the server down, the device files can be copied just like any other files).
Maintain system logs in a secure fashion. Record the directory where all SQL Server files are located, especially the Master.dat file. Keep records of all service packs installed for both Windows NT Server and SQL Server. Keep records of Net-libraries used, the security mode, and the SA password.
Maintain a base functionality script for quickly assessing minimal capability (see the note at the end of this article).
To minimize the amount of data lost during the day, perform database and transaction log dumps while the system is live. See the SQL Server Books Online for more information on dump, load, and recovery procedures.
Assess the following disaster recovery steps ahead of time on another server, and amend the steps as necessary.

To recover after a disaster has occurred, do the following after acquiring suitable replacement hardware:

  • Install Windows NT Server and load the appropriate service pack. Verify that appropriate domain functionality exists. For example, verify that file sharing works properly.
  • Install SQL Server and load the appropriate service pack. Place the master database device in the same directory as it was initially installed. Also select the same Net-library, security mode, and SA password as before.
  • Confirm that SQL Server is running properly. If the Windows NT Server name was changed, use sp_dropserver and sp_addserver to match the Windows NT Server name.
  • Stop SQL Server.
  • Move all of the database device files back to their original locations, including the Master.dat file.
  • Restart the SQL Server.
  • If any database or transaction logs are available after this time, load them.
  • Verify the availability of the system. Run a functionality script to ensure adequate operation. Ideally, before the users are released onto the system, time should be provided to run DBCC CHECKDB and NEWALLOC on each database, and DBCC TEXTALL and TEXTALLOC on those databases and tables containing TEXT fields. This is to ensure that the migration process did not alter the files in an undesirable fashion.