Backing up and restoring HP Insight Management 7.3 Central Management Server (Windows)

Technical white paper | HP Insight Management 7.3
Note:
If you have implemented a policy automatically restarting stopped services in your environment, this policy must be
temporarily disabled to avoid restarting the services during the recovery process.
Caution:
Although selected services are started by the mxsync tool, executing operations that change the state of managed
resources should be avoided until resynchronization is complete.
mxsync Systems Insight Manager synchronization section
To discover system changes that may have occurred after the backup was created during the execution step, you are asked
to connect to Systems Insight Manager, log in as Administrator and run Systems Insight Manager tasks to discover Onboard
Administrators, hypervisor host operating systems, operating systems deployed on blades, VM guests, and stand-alone
servers. The mxsync tool pauses while you complete discovery. Once discovery is complete, you can return to mxsync to
continue the synchronization process.
For more information about performing a Systems Insight Manager discovery, see the HP Systems Insight Manager 7.3 User
Guide.
If, as a post-backup activity, managed resources were added to the discovery tasks, or credentials or licenses were added or
modified, these changes should be made before running discovery.
mxsync Virtual Connect Enterprise Manager synchronization section
During this section the restored VCEM database is resynchronized with the actual state of the VC Domains managed by
VCEM.
There are two phases in this section. During the first phase, the mxsync tool analyzes the WWN and MAC addresses
assigned to profiles in the VC domains managed by VCEM to identify addresses that were allocated or reassigned after
backup.
An address could have been allocated if, for example, as a post-backup activity, a VC-based logical server or infrastructure
orchestration service was created. To prevent a post-backup allocated address from incorrectly being reassigned to a
second server during the execution step of this phase, the mxsync tool marks these addresses as
External
in the VCEM
database.
An address could have been reassigned if a VC-based logical server was deleted, the address freed, and then assigned to a
new logical server. To eliminate the conflict caused by reassigning an address to a different VC profile during the execution
step of this phase, the mxsync tool deletes the definition of the VCEM profile that contains the reassigned address.
If as a post-backup activity a VC Domain was added to or removed from a VC Domain Group, the VC Domain is no longer
accessible to VCEM after the VCEM database is restored from backup. During phase 1, you are given the opportunity to
provide the credentials for the added or removed VC Domain. This allows mxsync to access the VC Domain to identify any
WWN or MAC addresses that were assigned to the VC Domain after backup. If no VC Domains were added or removed after
backup, you respond ”n” if prompted to provide credentials.
During the second phase, the mxsync tool issues requests to VCEM to resynchronize each VC Domain managed by VCEM.
Note:
During the analysis step of phase 2, mxsync displays an ISSUE for each VC Domain managed by VCEM stating that the VC
Domain MAY need to be synchronized with VCEM. This is only a potential issue. The test to check if the VC Domain is out of
sync will temporarily place the VC Domain in maintenance mode and therefore can only be performed during the execution
step.
If, as a post-backup activity a VC Domain was added to or removed from a VC Domain Group, you need to manually reissue
the
Add to VC Domain
Group or
Remove from VC Domain
operation to successfully complete phase 2. See Appendix E: VCEM
resynchronization actions for additional details.
34