Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Restoring the Database from a Backup Without Affecting Service

 

Use this procedure to restore the database on an uncommissioned CMM without affecting service. This procedure first commissions the CMM and then restores the database.

It is primarily used for in-service replacement of a CMM in a chassis that has no active CMMs, such as in a system where the sole CMM in a single CMM chassis or both CMMs in a dual CMM chassis have failed.

This procedure does not affect service as long as the database being restored matches the existing service provisioning on the chassis.

Warning

Service modules are automatically warm reloaded as part of this procedure. Software-based features on the service module (such as PM collection, APSD, APR, FPSD) are disabled while a service module warm reloads.

Note

The backed-up configuration must be compatible with the software and chassis:

  • A configuration database is specific to a software version. In order to restore a backed-up database onto a replacement CMM, you must ensure that the replacement CMM is running the same software version as the software version running when the backup was created.

  • In releases lower than 4.2, a configuration database is also specific to a chassis. You can only restore a backed-up database to a replacement CMM on a chassis if the database was backed up from that chassis. You cannot restore a database to a CMM on a chassis if the database was backed up from another chassis.

    Starting with release 4.2, this restriction is relaxed. You can restore a backed-up database to any chassis of the same chassis type (BTI7801 to BTI7801, BTI7802 to BTI7802, BTI7814 to BTI7814).

Prerequisites

  • If you are replacing a CMM in a chassis, see Replacing the CMM in a Single CMM System before starting this procedure.

  • The configuration database that you want to restore is compatible with the chassis and with the software version on the CMM.

  • The replacement CMM is uncommissioned for this chassis.

  1. Seat the CMM into slot A. If your system has two CMMs, leave the other CMM unseated.
  2. Log in locally to the CMM in slot A over the craft serial or craft Ethernet port.

    For information on how to do this, see Logging In to the CMM Craft Ethernet or Craft Serial Ports.

  3. Enter setup mode. This is known as the commissioning shell.
    localhost console
  4. To see the list of available commands, type help.Note

    The commands in the commissioning shell should only be used on an uncommissioned system. Do not use the commissioning shell commands as a substitute for regular CLI commands.

  5. Set the time zone.

    For example:

    (cmm-setup)$ settz

    Follow the series of menu-driven options to set the time zone.

    Note

    You must manually set the correct time zone, date, and time even if you use NTP servers. The BTI7800 requires a correct clock at all times, including the period prior to the establishment of NTP server connectivity. Use of NTP servers is recommended.

  6. Set the date.

    For example:

    (cmm-setup)$ setdate
  7. Set the time.

    For example:

    (cmm-setup)$ settime
  8. Set up the networking parameters.Note

    All parameters are required to be set for proper operation of the BTI7800.

    For example:

    (cmm-setup)$ commission
  9. Since you are restoring the database instead of setting it to factory defaults, type no.

    For example:

  10. Restore the database.
    1. To restore the database from a backed-up configuration file stored at a remote location:

      For example:

      (cmm-setup)$ restoreremotedb

      This command finishes by performing an automatic warm reload of the CMM and all modules. The commissioning shell displays a set of log messages as the CMM reboots.

    2. To restore the CMM from a backed-up configuration file stored in local chassis storage:

      Note

      This option is available only for the BTI7801.

      (cmm-setup)$ restorelocaldb

      This command might take 15 minutes or more, and finishes by performing an automatic warm reload of the CMM and all modules.

  11. You will be logged out as the CMM reboots. When you see the login prompt, log back in to the craft serial or craft Ethernet port and start the commissioning shell.
    localhost console
  12. Reboot the CMM. This last reboot is required to ensure the CMMs and all service modules are synchronized.
    (cmm-setup)$ reboot

    The CMM in slot A reboots into the specified configuration and assumes the role of the active system controller module (SCM). Service modules are also rebooted. This might take several minutes. Proceed to the next step after the CMM finishes rebooting.

  13. If you have a dual CMM system, seat the other CMM into slot B. The CMM in slot B will now synchronize with the CMM in slot A. This might take several minutes. When this is finished, the Active LED on the CMM in slot B turns green.
  14. Log in to the CLI using the shared management IP address and verify that the CMMs are synchronized if applicable. For information on how to log in to the CLI, see Logging In to the CLI.

    The examples below have been edited to show only the relevant output.

    In a dual CMM system, the CMMs are synchronized when the HA Status is In Sync:

    bti7800# show system

    In a single CMM system, only the active controller is listed:

    bti7800# show system

The chassis is now commissioned and the database restored.

Release History Table
Release
Description
Starting with release 4.2, this restriction is relaxed. You can restore a backed-up database to any chassis of the same chassis type (BTI7801 to BTI7801, BTI7802 to BTI7802, BTI7814 to BTI7814).