Performing Disaster Recovery with an Inactive Shadow LSMS

In this disaster recovery strategy, you have a complete LSMS system installed at a geographically remote site, but it is not running and does not receive updates from the NPAC until you perform the procedures described in this section. This strategy requires a much longer recovery period than having an active shadow requires, but is still much safer than having no shadow. Having no shadow can result in a very long recovery period in serious disaster situations, such as fire or natural disaster.

In addition to the assumptions listed in “Preparing for a Disaster Situation”, the following conditions are assumed:

At the shadow site, all hardware and software components have already been installed and passed an acceptance test.
At the main LSMS, valid backups exist for all data. These backups are ready to be shipped to the shadow LSMS.
A network connection exists between the shadow LSMS and each network element and each NPAC. At the time of failure, the shadow LSMS is not associated with any of the network elements or NPACs.

Perform the procedures shown in Table 1 on the shadow LSMS when a disaster occurs on the main LSMS.

Recovery Procedures When LSMS Shadow Is Inactive
Inactive	In the order shown, perform the following recovery procedures:
1	Recovery acceptance test on inactive shadow LSMS: Verifying the State of the Servers Verifying the Processes Running on the Active Server (with primary server as active server) Verifying the GUI Operability on the Active Server (with primary server as active server) Manually Switching Over from the Active Server to the Standby Server Verifying the Processes Running on the Active Server (with secondary server as active server) Verifying the GUI Operability on the Active Server (with secondary server as active server) Manually Switching Over from the Active Server to the Standby Server
2, 3	Contact each NPAC from which the LSMS needs data to: Provide them with the IP address with which to establish association to the shadow LSMS. Request which files will be needed to download to the shadow LSMS. .
4	FTP data from the NPAC and import it into the LSMS (see Downloading Files from an NPAC to the LSMS).
5	Start the LSMS GUI (association with each NPAC is automatically attempted).
6	At the shadow, add any locally provisioned data that needs to be added.
7	Perform the procedures described in “Reconnecting Network Elements”.
8	If the disaster outage has lasted for 7 days or less, for each network element, perform a time-range audit (specify the start time to be one hour before the outage occurred) and a full-range audit of DGTT, OGTT, and NPA Splits. For information about performing audits, refer to “Audit and Optional Reconcile from the LSMS GUI” in the LNP Database Synchronization User's Guide. (If the disaster outage has lasted more than 7 days, perform a complete bulk download from the shadow LSMS to each network element. For information about performing bulk downloads to network elements, refer to the LNP Database Synchronization User's Guide.)
9, 10,11	If any query servers are installed: Stop the directly connected query servers. Configure each directly connected query server to use the shadow LSMS as its master host (refer to the procedure described in “MySQL Replication Configuration for Query Servers” in the Configuration Guide. For each directly connected query server, perform the procedure in Reload a Query Server Database from the LSMS.
12	Run on the shadow LSMS until the main LSMS is restored.
13	After main LSMS has been repaired, “Returning Operation from Shadow LSMS to Main LSMS”.