Metadata Databases & System Center Essentials 2010

One of the reasons SQL server can spread through your organisation is that it underpins so many applications, including quite a few candidates from Microsoft, like Project Enterprise , Visual Studio Team Server, and the System Center line-up.  All of these use SQL Server to store metadata, for example in the case of System Center Virtual Machine Manager (SCVMM) the catalogue and state of the virtual machines under control of SCVMM is stored in a series of tables.  This is a good thing as SQL server is being used for the right reasons and in the right way:

  • The data is typically quite compact and structured lending it self to a relational database. 
  • With SQL server already installed the additional benefits of reporting services can be used to monitor the application.
  • SQL Server can be used to store authorisation information – who can do what to the various parts of the application.  In this case the database can be protected with a certificate to ensure it is secure.
  • Multiple  (concurrent) user access to the tools can occur while maintaining this data in a consistent known state

However in the case of System Center Essentials (SCE pronounced as “ski”) which is designed for the small medium sized business there probably isn’t going to be a dedicated database administrator in the business and this might end up being the first exposure to SQL Server.  I mention this because one of the killer reasons to use a database for storing all this data is that it is pretty simple to backup the data.

SCE 2010 actually uses a number of databases, as it is a cut-down combined version of its bigger brothers like SCVMM:

  • SUSDB has all the deployment data about updates
  • VirtualManagerDB has all the metadata about the virtual machine templates, which is similar to Virtual Machine Manager
  • OperationsManagerDW all the monitoring event data in a format that can be used for reporting
  • SystemCenterEssentials has everything else in so the monitoring data, security and even a data warehouse scheme used by the reports

System Center products like SCE aren’t  mission critical applications but that doesn’t mean you shouldn’t back them up as the history of what has been done and how systems are behaving could be important in future either for troubleshooting, asset management, or other compliance work.  SCE Books online has some advice on making backups, but I am not sure who would dig down into that so here’s a cut & paste of the important bit:

Component to Back Up Full Backup Incremental Backup

SystemCenterEssentials

Daily

Not applicable

OperationsManagerDW

Monthly

Weekly

ReportServer

On a recurring basis, with the frequency depending on how often reports change in your organization, and every time after significant changes to report definitions (additions, changes, and deletions).

Same as full backup

SUSDB

According to WSUS recommendations. For more information, see Backing Up Windows Server Update Services 3.0 SP2

According to WSUS recommendations. For more information, see Backing Up Windows Server Update Services 3.0 SP2

VirtualManagerDB

Daily

Not applicable

Master database (Master)

Every time after installing and configuring the database components and after making significant changes to logons or other security changes.

Per IT policies

Msdb database (Msdbdata)

After the initial installation and configuration of the Essentials database components.

After changing the scheduled SQL Server agent jobs that Essentials 2010 uses.

Custom Management Packs (.xml files)

Monthly or after making significant changes to management packs.

Not applicable

Notice the additional entries here for the non-SCE databases Master, msdb & ReportServer.  If SCE is not sharing the installation of SQL Server with other applications then don’t assume these are being backed up unless you as the SCE administrator are doing it.  Actually you might want to check anyway as everyone on a shared SQL Server might assume that someone else is doing it. 

One final thing is that there other data outside these databases to consider including encryption keys and certificates as well as parts of active directory that should be backed up to ensure you can recover from every type of failure that could affect SCE which is also detailed in books on line here.