# Restoring a Database from another MiVoice Business System

## Restoring to a System with a Different Configuration

When restoring a database to a MiVoice Business system which is different from the one on which the database was backed up, the licenses, configuration options, and dimension selection programming on the target system must be adequate to support the requirements from that database. If you restoring to a different system, ensure that the licensing, configuration options, and dimension selection match the original system.

## Restoring to a Different Platform Type

Restoring a database from one platform type (AX, CX II, CXi II, MXe III) to another requires that the two databases match in the modules and add-ons, including embedded analog circuits programmed.

For example:

- You can restore a database from a CX II or CXi II to an MXe III controller; however, the Layer 2 switch on the MXe will require configuring after the Restore. The AMB and AOB may also require re-configuration.

- You can only restore an AX controller database to an AX controller. You cannot restore a database from another type of controller to an AX controller.

- You can restore a database from an EX controller to a CX II or CXi II to an MXe III controller, and vice versa.

## Restoring a Foreign MiVoice Business Database

When restoring a database, if the IP address in it doesn't match the one in the target MiVoice Business system (the system you are restoring the database to), then the database is considered foreign.

Restoring foreign databases is supported in MCD Release 5.0 and later. errors, particularly in the Network and Cluster Elements forms and the Admin Group form

IMPORTANT: To restore a foreign database in an SDS data-sharing network, the database must not already exist on any element in the network. For example, in an SDS network of three nodes, A, B, and C, you cannot restore a database to Node A if it was taken from either Node B or C. Furthermore, the Restore Foreign Database feature is NOT a substitute for performing an SDS sync to distribute data. When adding a new node to an existing network, the proper procedure is to start sharing from an existing node, and then perform a full sync from that node to the new node. See Unsupported Uses for Foreign Databases for additional information regarding unsupported uses for Foreign Databases.

## Supported Uses for Foreign Databases

The following are recommended ways to use foreign databases:

### 1) "Gold " Database Creation (Standalone Systems)

A dealer may want to set up a “Gold” database that contains commonly programmed system data—for example, COS, COR, System Options, etc. Rather than repeatedly entering the common data for each customer, the dealer can program it once in his lab and back it up to create a Gold database. He can then restore that database to controllers at multiple customer sites and reprogram the IP addresses in them to align with each customer's network.

Normally, no user or device data is included in the Gold database so licensing isn’t a concern. If licensed data is added, then the dealer would need to license the lab system before programming the users or devices. Even with the introduction of license violation mode in MCD 5.0, licensing is still required, as you cannot enter license violation mode without first communicating with the AMC, a process which involves hardware identification.

### 2) Off-site Commissioning (Standalone Systems)

Dealers who prefer to work in their labs instead of at the customer's site can use a Foreign Database to set up systems. The dealer typically has his own licensed lab hardware that uses an IP addressing scheme different than the one the customer has. With the Foreign Database feature, the dealer does not need to worry about matching destination IP addresses (or the customer changing destination IP addresses without notice). He can commission the systems, back them up, and then restore at the customer’s site, on different hardware, with different IP addresses. The only additional step, if the systems are clustered, is to re-initiate SDS sharing.

### 3) Cluster Configuration

Foreign Database Restore is a useful way to start building a cluster either on the customer’s premises or in the dealer’s lab.

A) Building a cluster at the customer’s site

To build a cluster at a customer site:

1. Make a Gold database that has all the cluster elements programmed in the Network Elements form.

2. Restore the database to a single element in the cluster.

3. Use SDS to share, then sync, the data to all other nodes in the network.

B) Building a cluster using a single MiVoice Business system at the dealer’s site

To build a cluster offsite—in a dealer’s lab, for example—using a single MiVoice Business system, start with a full install of the MiVoice Business software with licensing to allow cluster and device programming. Then, proceed as follows to create databases for each element in the cluster:

1. Program the first cluster element (Element A) with users and devices (this case assumes no resiliency)

2. Back up the database.

3. Do another full install (to clear the database) and re-license.

4. Program users and devices for the second element (Element B)

5. Do another database backup.

6. Repeat steps 3-5 for each element in the cluster.

At the customer’s site,

1. Restore the databases to their corresponding elements.

2. From one cluster element, add the names and IP addresses of the other elements to the Network Element form.

3. Create the cluster.

4. Start sharing data via SDS.

5. Finish by synchronizing at least the data in the Telephone Directory, User, and Service Hosting data.

C) Building a cluster at the dealer’s site using multiple MiVoice Business systems

This use case is a variation on the preceding one. The difference is that the dealer is using multiple systems to configure the databases, essentially replicating the customer’s network in his lab. As in the previous case, the dealer is required to license the systems to allow cluster and device programming.

To build the cluster, follow the usual procedure—enter the cluster members into the Cluster Element form on one of the systems, and then start sharing data via SDS to the other clusters elements.

1. Complete the system programming (e.g., trunks, COS, etc.) and add the users and devices.

2. Back up the databases on each system.

At the customer’s site,

1. Restore the backups to the customer's systems.

2. Re-align the IP Addresses of all other nodes in the network, then start sharing from that node.

After sharing, all databases will be in-sync, and IP addresses will match.

## Unsupported Uses for Foreign Databases

In general, Foreign Databases are best used in greenfield installations or following a Full Install (which deletes the existing database) of MiVoice Business software on a previously commissioned system. Using them in other scenarios is not recommended and should be avoided altogether in the following instances:

### 1) Restore to a different node in the same cluster

Restoring a Foreign Database backup from a system that was already a member of the same SDS network as the Restore destination is not supported—in fact, the Restore fails. For example, in a network of nodes sharing via SDS, restoring a backup from network element B to network element A will fail.

IMPORTANT: This Restore failure is only detected AFTER the first reboot and isn’t evident unless you are monitoring the RTC shell or examining the ESM logs. Further, the database that was previously in place is NOT be preserved.

### 2) Restore from one clustered SDS network to another

Consider two independent clusters, A and B. It is possible to take a database backup from a member of cluster A and restore it to a member of cluster B. In this case, the Restore will work since the backup database complies with the rule that it must not come from a system that is already a member of the same SDS network as the Restore destination. The mistake becomes apparent when SDS tries to sync the databases and encounters inconsistencies which result in SDS errors.

### 3) Restore from an Enterprise system to a Standalone system

Restoring a database backup from an Enterprise licensed system to Standalone licensed system is not supported. The inverse is possible, but you lose support for resiliency and the other features that Enterprise licensing provides.