IT tutorials

Microsoft SQL Server 2012 : Backup and Recovery Planning - System Databases Recovery, Performing a Complete Recovery

3/12/2014 2:57:49 AM
- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

1. System Databases Recovery

The master database contains key database and security information, and the msdb database holds the schedules and jobs for SQL Server, as well as the backup history. A complete recovery plan must include the system databases.

Master Database

The master database, by default, uses the simple recovery model. Using only full backups for the master database is OK; it's not a transactional database.

Backing Up the Master Database

You back up the master database in the same manner as user databases.

Be sure to back up the master database when doing any of the following:

  • Creating or deleting databases
  • Modifying security by adding logins or changing roles
  • Modifying any server or database-configuration options

Because the msdb database holds a record of all backups, back up the master database and then the msdb database.

Recovering the Master Database

If the master database is corrupted or damaged, SQL Server won't start. Attempting to start SQL Server will have no effect. Attempting to connect to the instance with Management Studio invokes a warning that the server does not exist or that access is denied. The only solution is to first rebuild the master database using the command line setup as shown next, reapply any SQL Server updates, start SQL Server in single-user mode, and restore the master database.

1. Rebuild the master database using the command line setup:
/SQLSYSADMINACCOUNTS="<DomainName\UserName >" /SAPWD="<password>"
  • setup.exe is either from your original installation media or the “local” setup.exe as found in the 110\Setup Bootstrap\SQLServer2012 directory.
  • /QUIET switch suppresses all error messages.
  • /ACTION=REBUILDDATABASE switch rebuilds all the system databases.
  • /INSTANCENAME switch specifies the name of your SQL Server named instance. Use MSSQLServer for “<instance_name>” for default instance.
  • /SQLSYSADMINACCOUNTS switch corresponds to the currently-logged in domain user running this rebuild process. The user must be a member of the SQL instance's sysadmin server role.
  • /SAPWD switch is used to indicate a new SA password if you configured SQL Server for mixed authentication.
A new feature was added to rebuilding the system databases in the last release. The system databases used for rebuilding the local system databases no longer come from the original installation media and are located locally in the C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binn\Templates\C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012SQLServer2012 folder. The switches have changed as compared to SQL Server 2005. folder, and setup.exe is located in the

2. Run the following from the command prompt to start a default instance of SQL Server in single user mode:
sqlservr.exe -m
If the instance is a named instance of SQL Server in single user mode, run the following to start:
sqlservr.exe -m -s <instancename>
3. Reapply any SQL Server updates, service packs, and hotfixes previously applied to the SQL Server.
4. Restore the master database as you would a user database. If a master backup is not available, re-create all missing entries for your user databases, logins, endpoints, and so forth.

If the master database is accessible, start SQL Server in single-user mode, and then restore the master database as you would a user database.

Rebuilding the master database also rebuilds the msdb and model databases. After rebuilding the databases, restore the system databases (master, msdb, and model) from the most recent good backup.
Rebuilding the master database installs all system databases to their initial location. If initially one or more system databases were moved to a different location, a similar move is required again.

MSDB System Database

Like the master database, the msdb database, by default, uses the simple recovery model.

Because the msdb database contains information regarding the SQL Server Agent jobs and schedules, as well as the backup history, it should be backed up whenever you do the following:

  • Perform backups.
  • Save SSIS packages.
  • Create new SQL Server Agent jobs.
  • Configure SQL Server Agent mail or operators.
  • Configure replication.
  • Schedule tasks.
  • Create or modify any policies created in Policy-Based Management.
  • Configure or modify Management Data Warehouse.
  • Add new registered servers (if an instance is set up as Central Management Server).

The msdb database is backed up in the same way that a user database is backed up.

To restore the msdb database, you do not need to put the server in single-user mode as you do with the master database. However, it's still not a normal restore because without a current msdb, Management Studio is not aware of the backup history. Therefore, the msdb backup can't be chosen as a backup database but must be selected as a backup device.

Use the Contents button to check the disk device for specific backups. If several backup instances are in the backup device, you can use the Contents dialog box to select the correct backup. It then fills in the file number in the restore form.

Before restoring the msdb database, stop SQL Server Agent. This is to ensure that the msdb database is not accessed by the SQL Server Agent and allows the restore to complete.

2. Performing a Complete Recovery

If the server has completely failed and all the backups must be restored onto a new server, follow these steps:

1. Build the Windows server, and restore the domain logins to support Windows authentication.
2. Install SQL Server and any service-pack, cumulative updates, security upgrades, or hotfixes.
3. Start SQL Server in single-user mode, and restore the master database.
4. Verify that SQL Server Agent is stopped. Restore the msdb database.
5. If the model database was modified, restore it.
6. Restore the user databases.

Best Practice
Performing a flawless recovery is a “bet your career” skill. Take the time to work through a complete recovery of the production data to a backup server. The confidence you gain can serve you well as a SQL Server DBA.

Top 10
Technology FAQ
- Microsoft ebs security server configuration
- IIs7 on Windows server 2003
- How to Configure Failover Clusters With Win 2008 Server R2?
- Windows 2008 Network Load Balancing
- Windows Server 2008 - Group Policy Management - Remove Computer Management
- Remove shortcuts possibility in a web page or to put in favorite
- HTA Dynamic Drop Down List
- IIS host header and DNS
- VMware or MS Virtual Server?
- Adobe Acrobat 9 inserting tab pages
programming4us programming4us