Considerations for Backing Up and Restoring System Databases
SQL Server maintains a set of system-level databases, system databases, which are essential for the operation of a server instance. Several of the system databases must be backed up after every significant update. The system databases that you must always back up include msdb, master, and model. If any database uses replication on the server instance, there is a distribution system database that you must also back up. Backups of these system databases let you restore and recover the SQL Server system in the event of system failure, such as the loss of a hard disk.
The following table summarizes all of the system databases.
System database |
Description |
Are backups required? |
Recovery model |
Comments |
|---|---|---|---|---|
The database that records all of the system level information for a SQL Server system. |
Yes |
Simple |
Back up master as often as necessary to protect the data sufficiently for your business needs. We recommend a regular backup schedule, which you can supplement with an additional backup after a substantial update. For more information, see Considerations for Backing Up the master Database. |
|
The template for all databases that are created on the instance of SQL Server. |
Yes |
User configurable1 |
Back up model only when necessary for your business needs; for example, immediately after customizing its database options. Best practice: We recommend that you create only full database backups of model, as required. Because model is small and rarely changes, backing up the log is unnecessary. For more information, see Considerations for Backing Up the model and msdb Databases. |
|
The database used by SQL Server Agent for scheduling alerts and jobs, and for recording operators. msdb also contains history tables such as the backup and restore history tables. |
Yes |
Simple (default) |
Back up msdb whenever it is updated. For more information, see Considerations for Backing Up the model and msdb Databases. |
|
Resource (RDB) |
A read-only database that contains copies of all system objects that ship with Microsoft SQL Server 2005 or later versions. |
No |
— |
The Resource database resides in the mssqlsystemresource.mdf file, which contains only code. Therefore, SQL Server cannot back up the Resource database. .gif "Note") Note
You can perform a file-based or a disk-based backup on the mssqlsystemresource.mdf file by treating the file as if it were a binary (.exe) file, instead of a database file. But you cannot use SQL Server restore on the backups. Restoring a backup copy of mssqlsystemresource.mdf can only be done manually, and you must be careful not to overwrite the current Resource database with an out-of-date or potentially insecure version.
|
A workspace for holding temporary or intermediate result sets. This database is re-created every time an instance of SQL Server is started. When the server instance is shut down, any data in tempdb is deleted permanently. |
No |
Simple |
You cannot back up the tempdb system database. |
|
A database that exists only if the server is configured as a replication Distributor. This database stores metadata and history data for all types of replication, and transactions for transactional replication. |
Yes |
Simple |
For information about when to back up the distribution database, see Backing Up and Restoring Replicated Databases. |
1 To learn the current recovery model of the model, see How to: View or Change the Recovery Model of a Database (SQL Server Management Studio) or sys.databases (Transact-SQL).
Restoring System Databases
Important
System databases can be restored only from backups that are created on the version of SQL Server that the server instance is currently running. For example, to restore a system database on a server instance that is running on SQL Server 2005 SP1, you must use a database backup that was created after the server instance was upgraded to SQL Server 2005 SP1.
To restore any database, the instance of SQL Server must be running. Startup of an instance of SQL Server requires that the master database is accessible and at least partly usable. If master becomes unusable, you can return the database to a usable state in either of the following ways:
Restore master from a current database backup.
If you can start the server instance, you should be able to restore master from a full database backup. For more information, see Considerations for Restoring the master Database.
Rebuild master completely.
If severe damage to master prevents you from starting SQL Server, you must rebuild master. Next, you should restore your most recent full database backup of master, because rebuilding the database causes all data to be lost. For more information about how to rebuild master, see Rebuilding System Databases.
Important
Rebuilding master rebuilds all of the system databases.
If the model, msdb, or distribution database becomes unusable, restore the database from the current full database backup. For more information, see Considerations for Restoring the model and msdb Databases and Backing Up and Restoring Replicated Databases.