Backup Best Practices

This section provides some best practices for backing up MOM data.

Testing The Backup and Restore Process

Every database environment should have an established backup and restore plan for failure recovery. This plan should be thoroughly tested and documented in a simulated environment using production backups.

It is strongly recommended that you test your backup and recovery procedures thoroughly. Testing helps to ensure that you have the required backups to recover from various failures, and that your procedures can be executed smoothly and quickly when a real failure occurs.

You can use a test environment including all the MOM components to test your backup and restore processes.

Recommended Backup Schedule

Table 5.2 suggests a schedule for regular backups of your MOM components and related items. These suggestions are specific to your MOM environment and are meant to be in addition to your other regularly-scheduled backups.

Table 5.2

1. You should backup this database after installing and configuring the MOM Database components and after making significant changes to logons or other security changes.

2. Only after first installing and configuring the MOM Database components.

3. Only if you change the scheduled SQL Server Agent jobs that MOM uses.

4. You can do this monthly of after significant changes to Management Packs. You only need to backup only the changed Management Packs.

5. You can do this on a recurring basis, frequency depends on how often reports change in your organization, or after significant changes to report definitions (additions, changes and deletions).

Do not backup during certain database grooming jobs

These grooming jobs run on the MOM Database Server and both read from, and write to, the database intensely and backing up the database during this time might cause failures in either the back up or the grooming job, or both. You can confirm the times these grooming jobs run in SQL Server Enterprise Manager. You can backup the Repotting Database while these jobs are running, as long as the SystemCenterDTSPackageTask task in not also running.

To check the schedules for grooming jobs

1. In Microsoft SQL Server Enterprise Manager, navigate to the MOM Database Server.

2. Navigate to Management / SQL Server Agent / Jobs.

3. In the results pane, open the Properties for the following jobs and click on the Schedules tab for each job:

   • MOMX Partitioning And Grooming

   • OnePoint - Reindex

   • OnePoint - Update Database

   • OnePoint - Check Integrity

Note

Although these grooming job times should be avoided, you might also want to schedule a time for the backup that does not overlap any of the grooming jobs.

Do not backup when the Reporting database DTS job is running

You should avoid backing up either the MOM Database or the Reporting Database (or even Management Packs) while the SystemCenterDTSPackageTask task is running. This task is located on the MOM Reporting Server and is scheduled at 1:00 AM by default. You can confirm or change the time this task runs in Scheduled Tasks.

To check the schedules for the Reporting DTS job

1. On the MOM Reporting Database Server and navigate to Start / Programs / Accessories / System Tools / Scheduled Tasks.

2. You can see the scheduled time for the SystemCenterDTSPackageTask by either observing the time in the Next Run Time column or by opening the Properties for the task and clicking on the Schedule tab.

Complete or Incremental Backup

You should perform database backups according to your companys backup policy. A full database backup captures the entire database, including all entries in the transaction log, and excluding any unallocated extents in the files. Pages are read directly from disk to increase the speed of the operation. At a minimum, a differential backup of the OnePoint database should be performed on a daily basis. A full backup should be performed on the OnePoint database weekly. The master and msdb databases should be backed up any time a change occurs that affects either database; however, you should back them up at least monthly.

Full Database Backups - A database backup creates a duplicate of the data that is in the database when the backup completes. This is a single operation, usually scheduled at regular intervals. Database backups are self-contained.

You can re-create the entire database from a database backup in one step by restoring the database. The restore process overwrites the existing database or creates the database if it does not exist. The restored database will match the state of the database at the time the backup completed, minus any uncommitted transactions. Uncommitted transactions are rolled back when the database is recovered.

A database backup uses more storage space per backup than transaction log and differential database backups. Consequently, database backups need more time to complete the backup operation and so are typically created less frequently than differential database or transaction log backups.

Differential (also know as Incremental) Database Backups - A differential database backup records only the data that has changed since the last database backup. You can make more frequent backups because differential database backups are smaller and faster than database backups. Making frequent backups decreases your risk of losing data.

You use differential database backups to restore the database to the point at which the differential database backup was completed.

Transaction Log Backups - The transaction log is a serial record of all the transactions that have been performed against the database since the transaction log was last backed up. With transaction log backups, you can recover the database to a specific point in time (for example, prior to entering unwanted data), or to the point of failure.

When restoring a transaction log backup, Microsoft SQL Server rolls forward all changes recorded in the transaction log. When SQL Server reaches the end of the transaction log, it has re-created the exact state of the database at the time the backup operation started. If the database is recovered, SQL Server then rolls back all transactions that were incomplete when the backup operation started.

Important

The MOM Reporting Database uses a simple recovery model which truncates all transactions after completion. This means that backing up the log file is not useful. Perform either a partial or complete database file backup.

Backup File Naming Conventions

Naming conventions can help you clarify which management group that backups are for and when they were done. You should use a naming convention for the various backup files so that you can restore your MOM environment smoothly and quickly.

Database Backups - Because you might have more than one management group in your MOM environment, be sure to include the management group name, or some distinguishing moniker, to the backup file name for the backup files for these management groups. This will eliminate unintentionally restoring the backup files from one management group to another management group. You might also want to include other information in the file name such as the database name, date and type of backup. For example, a file name might be: "MOMDB_DIFFERENTIAL_<management group name>_11_01_2004" or "REPORTING_FULL_<management group name>_11_01_2004."

Management Pack Backups (Exports) - As with databases, you might have more than one management group in your MOM environment, and the configuration for any given Management Pack might differ between these management groups. You can include the management group name, or some distinguishing moniker, to the AKM file name for these management groups. You might also want to include other information in the file name such as the date to the name. For example, a file name might be: "<management group name>_<Management Pack name>_<Management Pack version>_11_01_2004.akm."

Backing Up the Disk Drive on a Managed Computer

As part of your regular (not MOM-related) back-up practices, you might backup the disk drives on servers in your environment. When backing up the disk drive that the MOM agent is installed on, including the Management Servers, be sure to exclude the "<MOM Installed Partition>\Documents and Settings\All Users\Application Data\Microsoft\Microsoft Operations Manager\<management_group>\" directory. The agent will keep a lock o these files and the backup job will fail. If there are multiple management groups, such as when the agent is multihomed, be sure to exclude all the management group folders.