Migrating to a New Server

This tutorial describes one way to migrate a Traffic Sentinel installation from one server to another. For example, to move to new hardware or a new OS.


The server migration task can be broken down into four steps

  1. Install new server
  2. Migrate configuration
  3. IP address Handoff
  4. Migrate traffic history

Install New Server

Bring up the new server with a new IP address, but using the same hostname as the current Traffic Sentinel server. Keeping the same hostname is not essential, but it makes it easier because the product software key is (usually) tied to the server hostname, so the same key will work.

However if you do need a new key please use the link on the customer portal to Request New Key for this license.

Download the installation tarball and follow the installation guide to manually install the latest version of Traffic Sentinel on the new server.

If necessary, Upgrade your existing version of Traffic Sentinel to the same version. Either by running the installation manually or using the File>Upgrade web page.

It can be helpful to clear the cache on your browser at this stage, to ensure that new versions of javascript files will be downloaded from the server as you navigate the product pages.

Log in as "administrator" and use the File>Control page to stop data-collection on the new server.

Migrate Configuration

Traffic Sentinel includes a utility script ~inmsf/scripts/config_snapshot which you can use to extract a tarball of all the configuration settings, reports, widgets, REST API scripts and more. Run it like this:

~inmsf/scripts/config_snapshot /tmp/sentinel

This will create the file /tmp/sentinel-<date>-<id>.tar.gz. Copy this file to the new server, then install it there using

~inmsf/scripts/config_restore sentinel-<date>-<id>.tar.gz

You should now be able to log in to Sentinel on the new new server using your usual login id and password.

If the hostname changed and you have a new key, then you should first go and add the new key to the File>Configure>Edit>Site page.

IP Address Handoff

For now the sFlow®, NetFlow™, IPFIX and SNMP data collection will still be happening on the old server. At this point you can choose one of the following strategies:

  • Exchange IP addresses so that sFlow/NetFlow/IPFIX feeds will start going to the new server without requiring any change to the switch/router configuration, and so that any firewall rules or SNMP ACL lists that may have been configured for the old IP address will still work. You may decide to treat the sFlow collector address as a virtual address and just *add* it to the new server as an extra IP address. For example, if you add the IP address to interface eth0 it will appear as interface eth0:1.
  • Modify the switch/router configuration to send sFlow/NetFlow/IPFIX to the new IP address and ensure that SNMP access to the switches and routers is allowed from that address.

When you are satisfied that the configuration has been fully restored (including any custom configuration or scripts that might have been missed by the steps above) and that the data collection feeds are all configured correctly, then use the File>Control page to start data-collection on the new server.

Migrate Traffic History

The Traffic History database consists of binary files arranged in directories by day, in YYYYMMDD format. So that the directory:

contains the traffic history for 27-Aug-2015. To copy this to the new server is simply a matter of copying these directories across, and then making sure they are readable/writable by user inmsf on the new server. If the traffic history is very large you may find it best to use rsync(1) or even to have the new server mount the old server's disk using nfs. However in most cases it is OK for the data migration to take time, so a simple script that invokes scp(1) from the new server will work:
scp -r oldserver:$HISTDIR/* $HISTDIR
chmod -R inmsf:inmsf $HISTDIR
You may also want to repeat this for the ~inmsf/data/activeData directory. Note that in some cases the directory ~inmsf/data/ may be a link to some other directory. This happens if the utility script ~inmsf/scripts/moveDataDir was used to relocate the traffic history to a different partition that might have had more space, or if the utility script ~inmsf/scripts/history_archive is being used under cron to move day directories to alternative network-storage after some time rather than deleting it.

Related Topics