Replacing an appliance by using back up and restore
You can upgrade an appliance by backing up your old appliance and restoring the information to your new appliance.
About this task
This is the simplest and preferred method for upgrading or replacing a complete configuration, but requires you to stop each queue manager for a short period (an hour or so depending on size of the queue manager being relocated).
If you plan to use the same IP addresses or DNS names for IBM® MQ applications connecting to the new system, you will need to move all queue managers to the new appliance at the same time, and modify the network configuration at this point. You can avoid this requirement if you use HA with floating IP addresses, because individual IPs can be moved with their associated queue managers independently. If you are changing the IP address as part of the relocation, client applications and remote queue managers must be informed of the new IP (through configuration change, updated CCDT, and so on).
The procedure described assumes that you want to move a queue manager in its entirety, with all message data on queues and in a known fixed state (likely to be a state that is consistent with external systems, for example, databases, at a particular point in time). If you do not have this requirement, there are other options that reduce the potential service outage:
- Back up the queue manager while it is running. The archive is created from a point-in-time snapshot of the queue manager, but transactions continue to be processed on the running (old) appliance. Restoring from this archive to your new appliance could mean, for example, that duplicate copies of a message are processed by your applications, or that new messages sent since the archive was created are lost. This option also requires additional spare storage capacity on the source system to create the temporary snapshot.
- Back up the queue manager configuration only using the dmpmqcfg command. Using this method, you can recreate the queue manager on the new appliance in your own time, before redirecting applications to the new location. This method requires minimal downtime, but all message data on the existing system is lost (so you need to quiesce applications and drain messages before redirecting applications to the upgraded system).