This blog post is part of a series how to backup your SCOM environment.
You can find the other parts here:
Another part in the process of backing up your environment and thus making sure that all the data is available to restore your environment is backing up the Reporting services dbase which basically contains all your reports.
The standard report can be easily recreated when reimporting the management pack but if you made custom reports they will be lost if you do not have a backup.
This process consists of 4 steps:
Let’s get started!
The 2 dbases to backup are Reportserver and Reportservertempdb. Although it’s not absolutely necessary to backup the Reportservertempdb to restore your environment it will definitely save you some time in the process. If you loose your Reportservertempdb you’ll have to recreate it… So if you’re in the process of backing up take a backup of the Reportservertempdb as well.
You can use any method which is allowed by SQL to backup these dbases whether it’s System Center Data Protection Manager, third party software or the build-in SQL backup process.
I’ll be using the build-in SQL backup:
Open the Microsoft SQL Server manager and browse to your server / dbase:
Right click your reporting dbase and choose Tasks > Back Up…
Leave the backup type as Full, change the name (if you like otherwise use the default name) and check the location of the file.
Caution: Make sure you choose a file location which is included in your normal day to day file backups so you have it in your backup system when your server is completely lost.
If all goes well you’ll get the message that your backup was successful
Now repeat the steps above as well for the ReportservertempDB and save it in the same location as you have saved your ReportServerDB backup.
This encryption key is used for encrypting sensitive information in the dbase to ensure the safety of the data in it. You normally only have to save this key once as this is used in a 1-on-1 relationship with the dbase and the Symmetric key.
The key needs to be restored in the following cases:
Open your reporting Services Configuration Connection by choosing Start > all programs > Microsoft Sql Server ‘version’ > Configuration tools > Reporting Services Configuration Manager
A dialog box will appear to check the Server name and the report Server Instance:
If the are correct click Connect.
On the next page choose Encryption Keys and in the right pane click Backup button.
Choose the file location + name by clicking the … button.
Fill in a desired password. This password is used to encrypt the file so make sure you use a password you remember because there’s no way to restore the key without it + there’s also no way to reset the password on the exported SNK file.
If all goes well the key has been backed up and your receive the “Creating Encryption Key Backup” successful message at the bottom.
The reporting services uses different files to store the application settings. It’s very important you have this config files handy when disaster strikes because they contain all your settings / customizations.
Best practice is to take a backup of these files when you have installed the server, deploy custom extensions or when you run a full backup of your environment for drp reasons.
The following files must be included in a backup location which is covered by your filebackup system:
Web.config for both the Report Server and Report Manager ASP.NET applications
Machine.config for ASP.NET
Backup the files that you create and maintain in Report Designer and Model Designer. These include report definition (.rdl) files, report model (.smdl) files, shared data source (.rds) files, data view (.dv) files, data source (.ds) files, report server project (.rptproj) files, and report solution (.sln) files.
Remember to backup any script files (.rss) that you created for administration or deployment tasks.
Verify that you have a backup copy of any custom extensions and custom assemblies you are using.
This was the last blog post in the series “How to backup your SCOM environment”. If you follow these guidelines you’ll have a pretty good chance of recovering from a disaster with as little downtime, as little data loss as possible.
In the next series I’ll be posting how to Recover it all using the backups we took so stay tuned and as usual if you have remarks or feedback you can reach me on facebook / twitter.