Microsoft Operations Manager 2005 Operations Guide: Backup and Restore

Microsoft
Operations
Manager 2005
Operations Guide
Backup and Restore

Authors: Anat Kerry, James R. Morey
Program Manager: Tom Keane
Published: December 2004
Applies To: Microsoft Operations Manager 2005
Document Version: Release 1.0
The information contained in this document represents the current view of Microsoft Corporation
on the issues discussed as of the date of publication. Because Microsoft must respond to
changing market conditions, it should not be interpreted to be a commitment on the part of
Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the
date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES,
EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting
the rights under copyright, no part of this document may be reproduced, stored in or introduced
into a retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the express written
permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted herein are fictitious, and no association
with any real company, organization, product, domain name, e-mail address, logo, person, place,
or event is intended or should be inferred.
 2004 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows NT, Windows Server, Active Directory, ActiveSync, and
Windows Mobile are either registered trademarks or trademarks of Microsoft Corporation in the
United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
Acknowledgments
Primary Reviewers: Tom Keane, Bill Hodghead, Janaina Bueno
Managing Editor: Sandra Faucett
Did you find this information useful? Please send your suggestions and comments about
the documentation to momdocs@microsoft.com.
Looking for more MOM information? Experience the power of customer communities!
MOM Community
Backup and Restore
C H A P T E R 5
This chapter provides detailed information about, and instructions for, backing up and restoring
your Microsoft® Operations Manager (MOM) 2005 environment.
In This Chapter
• What To Backup
• Causes of Failure
• Impact of Failure
• Backup Best Practices
• Backing Up MOM Data
• Restoring MOM Data
• Additional Resources
Send feedback to the MOM Documentation Team: momdocs@microsoft.com.
What To Backup
To ensure your ability to properly preserve and restore your MOM environment, you should
backup several key items. These items are the MOM (OnePoint) database and transaction logs,
the MOM Reporting (SystemCenterReporting) database and transaction logs, all of the
Management Packs you have imported or created, including all changes and customizations you
have made to them, and any files you have on the File Transfer Server.
MOM Community
6 Chapter 5 Backup and Restore
MOM Operational Database (OnePoint)

The most important item to back up is the MOM operational database. This database contains
almost all of the MOM environment configuration settings, agent information, Management
Packs with customizations, operations data that has not been archived to the Reporting database,
and other data required for MOM to operate properly.
This database is constantly being written to and read from, so you must backup the database
regularly to preserve the latest information about your MOM environment. The database is
groomed, regularly, by MOM and data is transferred to the Reporting database, if Reporting is
installed. The size of the operational database does not grow in the same way that the Reporting
database grows. The operational database tends to grow and shrink in size daily, whereas the
Reporting database grows with each DTS job archiving operational data and shrinks only when it
is groomed. The size of the operational database varies because of new operational data being
written to it, and groomed from it. In times of intense data collection, the operational database
can grow in size rapidly.
Important
Failure of the MOM database, without an established backup is
catastrophic. It requires the rebuilding of your entire MOM
environment, and results in the loss of almost all MOM-specific
data. Your backup plans should include the MOM database, at
a minimum.
You can use the backup and restore features in Microsoft SQL Server™ for this task.
MOM Reporting Database (SystemCenterReporting) and SQL

Reporting Database(ReportServer)
The Reporting server contains two databases related to MOM Reporting: the MOM Reporting
database and the SQL Report database. You need to back up both databases.
The MOM Reporting database holds all of the archived operational data from your MOM
environment. This data is used by SQL Reporting Services to create and present the reports
provided by MOM 2005. This data is important for trend analysis, performance tracking, and
many other IT analysis tasks. Because this database can grow to a very large size (more than one
terabyte) over time, backing it up can take longer than it takes for the operational database, but
backup might not have to be done as often, because the Reporting database is only updated daily
and not constantly.
The SQL Reporting database stores report definitions, report metadata, cached reports and
snapshots. This information is updated as administrators manage report definitions. For example,
information is updated when an administrator defines new reports, or changes the definitions of
MOM Community
Causes of Failure 7
existing reports. If you do not backup this database, you can recreate report definitions by re-
importing the reports, however, and cached (already-created) reports will be lost.
You can use the backup and restore features in Microsoft SQL Server for this task.
Master Database (Master)

The master database is a system database, which records all of the system-level information for a
SQL Server system, including the location of the database files. It also records all logon accounts
and system configuration settings. The proper functionality of the master database is key to the
operation of all of the databases in a SQL Server instance.
MSDB Database (Msdbdata)

The MSDB database is a SQL system database, which is used by the SQL Server agent to
schedule jobs and alerts and for recording operators. The proper functionality of the MSDB
database is key to the operation of all the databases in a SQL Server instance.
Note
This database contains task schedules that are vital to the
health of the MOM database, and should be included in your
backup plan. You only need to back up this database after you
first configure MOM, or if you change the scheduled agent
jobs.
Management Packs
Management Packs contain all of the data and rules for determining how MOM manages
applications, services and devices. Backing up your Management Packs is vital to restoring your
MOM environment, should circumstances require this. Although backing up the MOM
operational database also captures this information, backing up the Management Packs separately
also allows you to re-import them separately from the database, which can be useful in cases
when you must roll back the changes in one or more Management Packs. This adds an additional
layer of safety, and makes exporting Management Packs fast and easy.
You can use the export and import features in MOM to complete this task. You can export
Management Packs using either the MOM Administrator console or the
ManagementModuleUtility.exe command line utility. Using the utility, you can automate and
schedule to export of Management Packs.
MOM Community
File Transfer Server Files

The files that you use for File Transfer responses are not part of your MOM environment, but
you might want to back up these files to make sure that they can be restored, if necessary. These
files might be logs that are transferred from an agent, or software updates transferred to, and
installed on, an agent.
You can use various file backup methods for these files.
Custom Files
You might consider backing up other files that are used by MOM:
• ManualMC.txt, a custom text file that administrators can use to control which computers are
included, or excluded, in the computer discovery and agent installation processes.
If you are using this file, then it is located in the same folder where you installed
MOM 2005. The default MOM 2005 installation folder is \%SystemRoot%\Program
Files\Microsoft Operations Manager 2005.
• Custom Administrator console (*.mmc) files.
• Customized Operator console (*.omc) files.
Causes of Failure
Even with the best maintenance practices, hardware might fail, occasionally, and data might
become corrupted, causing interruption to MOM functionality. If there are any early signs of
failure, it is best to respond immediately in order to minimize the impact of a possible failure.
There are various causes for failure. Some of the most common causes of failure, and tips for
minimizing the risk of such failure, are listed below.
Disk Failure
A disk failure on a MOM server will prevent that server from providing the proper MOM
functionality. The impact of a disk failure depends on the MOM server experiencing the problem,
and on your specific MOM deployment.
You can minimize the risk of a disk failure by using RAID arrays, and by performing regular disk
checks. This is especially important for critical MOM servers, such as the MOM database server,
and also when clustering is not implemented. For more information about minimizing the risk of
a disk failure, see ‘Preparing the hard disk drives’ topic in the “Deploying MOM 2005 across
Multiple Computers” chapter of the Microsoft Operations Manager 2005 Deployment Guide.
MOM Community
Causes of Failure 9
Security Breach/Virus Infection

A security breach, or a virus infection, on MOM servers, can delete or corrupt data in MOM
databases, or on the hard drives. In those scenarios, MOM stops operating properly, and the
integrity of the data is no longer guaranteed. The impact of a security breach or a virus infection
depends on the MOM server experiencing the problem, and on your specific MOM deployment.
You can minimize the risk of a security breach, or a virus infection, by ensuring that the
appropriate security policies are enforced. For information about MOM security, see the
Microsoft Operations Manager 2005 Security Guide.
Corrupted Data
Data can become corrupted for various reasons, such as software failure and human error. Also, a
MOM upgrade might fail, causing the newly-upgraded database to be corrupted. If there is no
option to reverse the changes that caused the corruption, the only way to restore MOM
functionality might be to restore the data, and then return to an earlier point, before the
corruption started
Corruption of Account and NT Group Information

While trying to follow security recommendations, administrators might accidentally delete or
corrupt the NT group information or the SQL Server user logins information. For example, an
administrator might accidentally remove the DAS account from the MOM Service group. This
will prevent MOM from communicating with the MOM Database, stopping all MOM
functionality.
Tip
Note: Using the Repair option of momserver.msi does not
repair such problems.
Physical Disaster
In the case that a physical disaster, such as fire or flooding occurs, MOM Servers might be
physically damaged, and part, or all, of the MOM data might be lost. Restoration in these cases is
possible only if the backup of the data is available, such as if it has been previously stored off-
site.
Physically protect MOM servers in the same way that you protect other key servers in your
organization. You can minimize the impact of a physical disaster by maintaining management
groups in different geographical locations. Implement alert-forwarding and multitiered structure
in your MOM deployment, as appropriate. Also, ensure that you have a complete backup of
MOM data in different physical locations.
MOM Community
Impact of Failure
Various MOM servers and components can potentially fail, because of the reasons mentioned
above, or for other reasons. The impact of each failure on MOM functionality is different, and
depends on the role of the failing server or component, and on the specific MOM deployment.
The impact of some server failures can be reduced significantly if failover, such as clustering, is
implemented. If clustering, or multiple Management Servers, are implemented in the
management group, then the urgency of restoration is greatly reduced. If, however, failover does
not exist, you might not be able to perform any MOM administrative tasks until you recover the
failing server.
The following table lists the impact of failure of the various MOM servers, and the general steps
you need to take to restore MOM functionality. In this table, the assumption is that each server
listed performs only a single role, as specified.
Table 5.1 - Impact of MOM Servers/Components Failure, and Restoration
Procedure
MOM Impact Restoration
Management
Server
Impact of Failure • Data from managed computers 1. Repair the
Without Failover is not processed, because server.
MOM agents are unable to 2. Reinstall MOM
send it to the Management Management
Server. The data is queued on Server.
the managed computers.
• Any other MOM components
(such as the Administrator
console) installed on the same
server are not accessible.
• Computers are not being
discovered.
• Agentless computers are not
managed.
• At some point, reports do not
contain up-to-date information,
because the Operational
database is not updated and
because the next scheduled
DAS job, to update the
MOM Community
Causes of Failure 11
Reporting database, cannot

run.
Impact of Failure • Workload on any additional After the failing
With Failover Management Servers in the Management
management group is Server is restored,
increased. MOM agents will
eventually resume
reporting to that
Management
Server.
MOM Database Impact Restoration
Server/
SQL Server/
Operational
Database
Impact of Failure • Data from managed computers 1. Repair the
Without Failover is not processed, and is not MOM database
stored in the database. This server, if
data might eventually be lost. needed.
• Performance on managed 2. Reinstall
computers is degraded, due to SQL Server, if
the accumulated data. needed.
• Cannot perform any MOM 3. Reinstall the
administrative tasks such as MOM database
viewing, editing or managing component, if
MOM objects. needed.
• Reports do not contain up-to- 4. Restore the
date information. Operational
• Administrator console and database.
Operator console do not
function.
• Changes to Management Pack
are not propagated to agents.
Impact of Failure • If the Operational database is
With Failover intact, clustering can
compensate for the failing
server; however, the workload
on other servers in the cluster
is increased.
• If the Operational database is
failing, clustering does not
MOM Community
reduce the impact of failure.

MOM Reporting Impact Restoration
Server/
Reporting
Database
Impact of Failure • Cannot view, edit or manage 1. Repair the
Without Failover reports. server, if
• The DTS job cannot run, and needed.
the Operational database 2. Reinstall MOM
cannot be groomed. This Reporting
results in performance server, if
problems with the Operational needed.
Database, and possible data 3. Restore MOM
loss, if the Reporting database Reporting
is not recovered within sixty database and
days. SQL Reporting
database.
Impact of Failure • If the Reporting database is
With Failover intact, clustering can
compensate for the failing
server; however, the workload
on other servers in the cluster
is increased.
• If the Reporting database is
failing, clustering does not
reduce the impact of failure.
File Transfer Impact Restoration
Server
Impact of Failure • File Transfer responses cannot 1. Repair the File
transfer files. Transfer Server.
2. Restore the
files.
Computer Impact Restoration
Hosting
Administrator
console/
Operator console
Impact of Failure • Cannot use consoles on the 1. Repair the
failing computer. computer.
MOM Community
2. Reinstall MOM
consoles.
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
Full Backup Incremental
Backup Item
Backup
MOM Database (OnePoint) Daily N/A
MOM Reporting Database Monthly Weekly
(SystemCenterReporting)
SQL Reporting Database (ReportServer) Note 5 Note 5
Master Database (Master) Note 1 Per your IT
policies
Msdb Database (Msdbdata) Note 2 Note 3
Management Packs and Reports (.akm and Note 4 N/A
.xml files)
File Transfer files As needed N/A
MOM Community
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.
MOM Community
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 company’s 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. To recover to the exact point of failure, you must use transaction
log backups.
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.
MOM Community
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.
MOM Community
Backing Up MOM Data

MOM uses several data stores, with the majority of the data being stored in databases. Therefore,
backing up MOM databases is the most important task to ensure a complete recovery in the event
of a failure. If you back up MOM data properly, on a regular basis, no data loss is expected in the
event of a failure.
MOM uses the following data stores, which you need to back up:
• MOM Operational Database (OnePoint)
• MOM Reporting Database (SystemCenterReporting)
• SQL Reporting Database (ReportServer)
• Master Database (Master)
• MSDB Database (Msdbdata)
• Management Packs and Reports (.akm and .xml files)
• File Transfer Server files
• Custom files
The following sections describe how to back up each data store. As an additional precaution,
after you back up data, copy the backup file to another server for storage, or another backup
media such as tape.
Backing Up MOM Databases

If there are established guidelines and procedures for backing up databases in your organization,
then follow those guidelines and procedures to back up the MOM databases and the SQL system
databases. When backing up, ensure that all data, up to the point of failure, is backed up, and that
it can be later restored, if necessary.
Use SQL Server to back up MOM databases, manually, or schedule SQL Server tasks to ensure
Note
The MOM Reporting database uses a simple recovery model,
which truncates all transactions after completion. Therefore,
backing up the transaction log file is not useful. When backing
up the Reporting database, use only a differential backup or a
complete backup.
MOM Community
SQL Server allows access to the database while it is being backed up. This allows you to
continue to use MOM if you need to; however, you might notice a decrease in performance until
the backup is complete.
Note
If your backup procedure sets the MOM database to be offline
during backup, then MOM caches incoming data, and then,
after back up is complete, MOM stores that data in the
database.
Backing Up Management Packs

You can back up Management Packs, either by using the Import/Export Management Packs
Wizard, or by using the Management Module command-line tool (ManagementModuleUtil.exe.)
For information about the Management Module tool, see Chapter 8, “Tools”.
To back up a Management Pack using the Import/Export Management Packs Wizard, export the
Management Pack, and then store the exported file in a safe location.
To export a Management Pack using the Import/Export Management
Packs Wizard
1. Open the MOM Administrator console.
2. In the console tree, click Management Packs, and then in the Details pane, click
Import/Export Management Packs.
3. On the Import or Export Management Packs page, click Export Management Packs.
4. On the Select a Rule Group page, expand Rule Groups, expand the subfolders to select
child rule groups, and click the rule group that you want to export.
5. On the Select Views page, select the Views check-box to export all views, or expand Views
to select all views for a rule group, or to select individual views.
6. On the Select Tasks page, select the Tasks check-box to export all tasks, or expand Tasks to
select specific tasks to export.
7. On the Management Pack Name page, type a name, click Browse to navigate to the
location that you want to export the Management Pack to, select an overwrite handling
option, and then click Next.
8. On the Completing the Management Pack Import/Export Wizard page, click Finish.
Backing Up Report Definitions
MOM Community
When exporting a Management Pack, report definitions are not exported along with the other
MOM objects defined in that Management Pack. To back up report definitions, you must use
either of the following methods:
• Export report definitions using SQL utilities or the Report Utility (RptUtil.exe). For
information about this utility, see Chapter 8, ‘Tools.’
• Backup the SQL Reporting database. (ReportServer).
If, after importing reports, no changes were made to those reports, then you can later re-import
those reports in the case of a failure. However, if changes were made to the report definitions
after they were imported, then you must back up the report definitions after changes are
complete, using one of the methods mentioned above.
Backing Up File Transfer Server Files

You can use any file backup and restore utility that is used in your organization for file back ups.
Backing Up Custom Files

Back up any custom files that are used in your MOM deployment, such
as ManualMC.txt, or custom MOM Operating console. You can use any
file backup and restore utility that is used in your organization for file
back ups.
To save custom MOM Operator console settings
1. In the MOM Operator console, configure the settings the way that you want them.
2. On the File menu, click Save As.
3. In the Save As dialog box, select a location to save the console settings as an Operations
Manager Config file (*.omc).
Restoring MOM Data

Depending on the failure scenario, in order to restore MOM functionality, you might first need to
repair or reinstall a failing server, reinstall SQL Server, or both. Whenever you are planning to
restore MOM data, you must reinstall software using the original settings, such as computer
names, installation paths, management group names, and the DAS account. After recovering any
failing MOM servers, and reinstalling components, as needed, you can restore the MOM data
that was lost.
MOM Community
See Table 5.1 for the high level restoration procedure, based on the failure scenario. Refer to the
specific restoration procedures in this section, as needed.
Restoring MOM Databases

Depending on the failure scenario, you might need to restore any of the MOM databases, the
master database or the MSDB database. During a database restore, all connections to the
database must be closed, and the MOM Service on Management Servers should not be running,
otherwise the restore fails. To prevent this, take the database offline. You can use SQL Server to
verify that there are no open connections to the database.
Use SQL Server to restore MOM databases, following restore procedures in your organization.
Refer to the SQL Server documentation set for information about restore procedures, and restore
best practices.
To restore the Operational database
1. Use SQL Server to restore the Operational database
2. Grant access for the DAS account to the OnePoint database.
3. Using Enterprise Manager, select Security, and then select Login.
4. Select DAS Account, then right-click Properties, and select Database.
5. Select OnePoint, and then select the check-box for db_owner.
Restoring Management Packs

Management Pack data is stored both in the Management Pack itself, and in the Operational
database, after importing the Management Pack. As you customize Management Pack objects in
the Administrator console, the Operational database is updated with those changes. To keep the
Management Pack updated with your changes, you need to export the Management Pack after
those changes are complete.
You can restore Management Pack data in either of the following ways:
• Restoring the Operational database - If all changes to the Management Pack are included in
the latest Operational database backup, then the Management Pack objects are restored,
along with the rest of the MOM data, when the Operational database is restored.
• Re-importing the Management Pack - If you have exported the Management Pack, after
completing all changes to the Management Pack, then the Management Pack itself is up-to-
date. You can re-import the Management Pack, as follows, to restore its content:
• Using the Import/Export Management Packs Wizard.
MOM Community
• Using the Management Module command-line tool (ManagementModuleUtil.exe.) For

information about the Management Module tool, see Chapter 8, “Tools”.
Restoring Report Definitions
When restoring Management Packs, in either of the methods described above, report definitions
are not restored along with the other MOM objects defined in the Management Pack.
You can restore report definitions using either of the following methods:
• Import the report definitions using the Report Utility (RptUtil.exe). For information about
this utility, see Chapter 8, ‘Tools.’
• Import the reports along with the rest of the objects of the Management Pack.
• Restore the SQL Reporting Database (ReportServer).
Restoring Files to the File Transfer Server

You can use any restore utility that is used in your organization to restore files to the File
Transfer Server.
Restoring Custom Files

Restore any custom files that are used in your MOM deployment, such as ManualMC.txt, or
custom MOM Operator console files (.omc) to their original folder. You can use any file restore
utility that is used in your organization for this operation.
Additional Resources
For the latest information about MOM, see the product Web site at
http://go.microsoft.com/fwlink/?linkid=6727.
To access the MOM core product documentation on the Web, see the Technical Resources section
of the product Web site at http://go.microsoft.com/fwlink/?LinkId=8943.
To access the Microsoft Operations Manager 2005 Deployment Guide, see the guide on TechNet
at http://go.microsoft.com/fwlink/?linkid=33535
To access the Microsoft Operations Manager 2005 Security Guide, see the guide on TechNet at:
http://go.microsoft.com/fwlink/?linkid=33035
For more information about backup and restore using Microsoft SQL Server, see the SQL Server
Books Online.
MOM Community
MOM Community

Microsoft Operations Manager 2005 Operations Guide: Backup and Restore

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Microsoft Operations Manager 2005 Operations Guide: Backup and Restore

Caricato da

Copyright:

Formati disponibili

Microsoft

Backup and Restore

MOM Operational Database (OnePoint)

MOM Reporting Database (SystemCenterReporting) and SQL

Master Database (Master)

MSDB Database (Msdbdata)

File Transfer Server Files

Security Breach/Virus Infection

Corruption of Account and NT Group Information

Reporting database, cannot

reduce the impact of failure.

Backup Best Practices

Testing The Backup and Restore Process

Recommended Backup Schedule

Do not backup during certain database grooming jobs

Do not backup when the Reporting database DTS job is running

To check the schedules for the Reporting DTS job

Complete or Incremental Backup

Backup File Naming Conventions

Backing Up the Disk Drive on a Managed Computer

Backing Up MOM Data

Backing Up MOM Databases

Backing Up Management Packs

Backing Up File Transfer Server Files

Backing Up Custom Files

Restoring MOM Data

Restoring MOM Databases

Restoring Management Packs

• Using the Management Module command-line tool (ManagementModuleUtil.exe.) For

Restoring Files to the File Transfer Server

Restoring Custom Files

Potrebbero piacerti anche