AnsweredAssumed Answered

SSGMigrate vs SSGRestore

Question asked by Ankush on Sep 27, 2017
Latest reply on Sep 29, 2017 by Ankush

I am using the software version of API Gateway v8.4 and API Portal V35. (Form Factor is Software)

Environment as below:-

Server1: API Gateway v8.4
Server2: API Portal v35

I am supposed to build the similar environment without changing hostnames, certificates on new servers. The only difference is IP address of new servers will differ.
In /etc/hosts, server names, URL names, hostnames everything will be similar.

Server3: API Gateway v8.3
Server4: API Portal v35

From Portal perspective, I am doing the backup on Server2 and restoring on Server4. All looks good here.

From Gateway perspective, I am doing the backup on Server1 (image backup with -ia flag) and restoring on new Server3 with
As per Server3 Gateway, just installed SSG RPM and installed the MySQL DB. Then using to import the server1 gateway configs in Server3.

Server1 Backup Command: #./ -image -ia -v –halt
Server3 Restore Command: #./ -image /opt/SecureSpan/Gateway/config/backup/images/ -dbu username -dbp ****** –v –halt

I was able to successfully restore the gateway on Server3 and able to test all the functional use cases are working as expected.

Even though everything is working as expected, one thing is not clear for is about "cluster_info" table details.

This table during the restore process got all details from Server1.

In that columns named "address", "esm_address", I have manually updated the new Server3 IP Address. But, was not sure about "multicast_address" value.

Can I ignore this "multicast_address" field and leave as is?
Will that create impact to my old cluster (Server1) or new cluster (Server3) gateways by any chance?


BTW, I didn't use for this by referring the documentation "Migration Tip" in

"Note: If your goal is to initialize a new cluster using a backup image, use the Restore Utility ( instead. For more information, see Restore Gateways."

Other than "multicast_address" in "cluster_info" table as a clarification, on our new cluster, everything is working as expected.
BTW for an additional information, I am building this new parallel equivalent environment and then upgrade that gateway to V9.2 CR05 release.