Replicating System Databases

The following are a list of all MS SQL Server System databases and a description of what they are for:

Master	The Master database holds information for all databases located on the MS SQL Server instance, and includes information such as system logins, configuration settings, linked servers, and general information regarding the other system and user databases for the instance. Because MS SQL Server cannot start without a functioning master database, you must administer this database with care. For this reason, it is vital to make regular backups of this database. (see Replicating Master Database for more information).
Model	Model is essentially a template database used in the creation of any new user database created in the instance. You can place any stored procedures, views, users, etc. in the model database so that when a new database is created, the database will contain the objects you have placed in the model database. Based on your needs you may or may not need to replicate this database.
Tempdb	Tempdb holds temporary objects such as global and local temporary tables and stored procedures. This database is recreated every time SQL Server starts, and the objects contained in it will be based upon the objects defined in the model database. This database should never be replicated
Msdb	The msdb database stores information regarding database backups, SQL Agent information, DTS packages, SQL Server jobs, and some replication information such as for log shipping. Since you are using Peer DRS to replicate your databases, you should not need to replicate this database.
Distribution	When your MS SQL Server instance is configured as a distributor for replication, this database is added to your system. This database holds history and metadata for snapshot, merge, and transactional replication. Since you are using Peer DRS to replicate your databases, you should not need to replicate this database.

In general, it is usually not necessary to replicate any of the System Database, with the possible exception of the master database--especially if you have many user logins that frequently change.

All System databases use the SIMPLE recovery model, and as a result, you cannot perform incremental backups on a database set for SIMPLE recovery. Therefore, the incremental backup schedule will automatically be disabled. If you require frequent backups of any of the System Databases, then you should increase the frequency of the full backup schedule. In addition, in order to replicate any of the System databases, both the primary and target database MS SQL Server instances must be at the exact same version and revision.

In addition to the above mentioned restrictions and requirements for replicating System databases, the master database has one extra restriction. MS SQL Server requires the server to be in single-user mode before the master database can be restored. You put a MS SQL Server instance in single user mode by starting it up with the (-m) option. See How to: Configure Server Startup Options (SQL Server Configuration Manager) for more information. Furthermore, while in single user mode, no other database besides the master database can be restored, which precludes leaving the MS SQL Server instance in this mode while Peer DRS is running.

The best solution for replicating the master database is to create a Replication Job in Peer DRS to backup the master database and add a File Copy Only Target that will keep the latest copy of the master database on the target server without restoring it into the database server. When you need to failover, then you will need to place the MS SQL Server instance in single-user mode, and either manually restore it into the standby target server using the Peer DRS full backup file (see below), or enable the restore job and trigger the job manually. If you plan on using the target database as a warm, read-only standby server, and the master database and login information does not change often, you can backup and restore the master database before replicating any other databases, and then just disable the restore job making it a File Copy Only target from that point forward.

First, the SQL Server needs to be started in single-user mode. This can be done through either the command prompt or via SQL Server Configuration Manager. See How to: Restore the master Database for additional details.

Next, open a second command prompt and change into the %programfiles%\Microsoft SQL Server\MSSQL.1\MSSQL\Bin and use the sqlcmd utility to execute the following command. See Using the sqlcmd utility for more information.

Once the restoration of master is complete, the SQL Server can be started in normal, multi-user mode.