Backing Up and Restoring the RMS System

Updated: November 15, 2006

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

When planning for system recovery, your plans should account for the failure of the database server and the failure of an RMS cluster. In the event of a database server failure, you can restore the functionality of an RMS cluster from a backup copy of the configuration database. You do not need to obtain a new server licensor certificate or private key for your RMS cluster because these items are stored in the configuration database.

Planning the RMS System Backup

In addition to the server key, user data, including public key information, is stored in the configuration database. To protect valuable key data, back up the configuration database to media, and place the media in a secure location. The configuration database for the root cluster changes frequently, so it is recommended that you frequently perform backups. The more often new users are added to your organization, the more often you should perform backups. If you are backing up your root cluster and are using RMS with Service Pack 1 or earlier, you should also make sure to include the sysmessages table from the master database in your back up. This table includes RMS-specific messages. If not backed up, the root cluster will not be able to function and will return an error. If this table is not in the back up, it can be recreated by repeating the provisioning process using an existing database.

RMS with Service Pack 2 no longer uses the sysmessages table.The RMS logging database contains logs that might provide interesting troubleshooting and statistical data, but it is not usually critical to an RMS system. The Directory Services database is a local cache of the Active Directory database, so it is recreated automatically when you restore an RMS system. To establish a plan for backing up your RMS databases, consult your SQL Server administrator.

If you are using a hardware-based CSP (cryptographic service provider) to protect the RMS private keys, you must also back up the CSP configuration. For more information about how to back up and restore the hardware CSP, consult the CSP documentation.

If you used a software-based CSP other than the default software-based CSP to encrypt the RMS private keys, make sure that you have organizational key management practices (such as backup and restore procedures) in place for that CSP before you use it with RMS.

Planning to Restore an RMS System

If you are restoring a database server from backup, make sure that the version of RMS running is the same version that was running when the backup was created. Inform users of the RMS system that if they started using the RMS system after the date of the back up, they will be required to get a new rights account certificate. No protected content is lost as a result.

To restore a single RMS server from a cluster, rebuild the server, reinstall RMS and then join the server to the cluster by using the existing database. This activity does not affect the users of the RMS system because the clustered servers operate as one.

Community Additions