The PhoneBoy Blog

FireWall-1 FAQ: How do I backup and restore an MDS?

Last Modified: 31 Dec 2003

Please note: This content was from when I was operating my FireWall-1 FAQ site, which I stopped operating in August 2005. For some reason people still have links to this stuff on the Internet that people are still clicking on.

I am making this information available again AS IS. Given how old this information is, it is likely wildly inaccurate. I have no plans to update this information.

If you're still running versions of Check Point VPN-1/FireWall-1 where this information is still relevant to you, do yourself a favor and upgrade to a more recent release. If you happen to be running a current release and the information is useful, it's by happenstance :)

How do I backup and restore an MDS?

This document describes how to backup and restore a Check Point Provider-1 NG FP2 environment in a step-by-step process. Any statements contained herein are those of the author <a href=mailto:[email protected]>Steve Johnson</a> and in no way reflect those of Check Point Software Technologies or Akibia.

• Backing up the Provider-1 Environment
• Restoring an MDS Backup File to the same Provider-1 MDS
• Restoring an MDS Backup File to a different Provider-1 MDS

Backing up the Provider-1 Environment

The following steps should be executed while being in the global MDS environment. Type in ‘mdscmd’ to switch to the MDS environment before going through the steps below.

1. Make sure there are no GUI clients connected to the MDS.
2. Create a directory (/var/mdsbackup) and ‘cd’ into that directory.
3. Execute the command ‘mds_backup’ which will take a few minutes to backup your entire MDS environment. You will be able to do a complete restore of the Provider-1 environment using the compressed backup file that will be generated from this script.

Gotcha(s): In some hardened OS environments you may need to modify the mds_backup script as some of the binaries may not exist in your particular environment. For example, Check Point uses BSD commands like ‘whoami’ to make sure you are logged in as a super-user instead of SYSTEM V commands like ‘who am i’ and in some hardened OS configurations, this command may no longer exist. Please note that modifying the mds_backup script is not supported by Check Point.

The mds_restore script uses a Check Point utility called ‘gtar’. The gtar binary is not located in your path so copy the binary to /usr/sbin before attempting the restore. The gtar binary can be found in /opt/CPShared/5.0/util

Restoring an MDS Backup File to the same Provider-1 MDS </h3>

Use the following procedure to do a complete restore of the Provider-1 MDS as it existed at the time when the last mds_backup file was executed.

1. Copy the compressed *.mdsbk.tgz file to your /var/mdsbackup directory and ‘cd’ into that directory.
2. Execute the command, ‘mds_restore <name of mdsbk file>’ and follow the onscreen directions.

Restoring an MDS Backup File to a different Provider-1 MDS

Some may find it useful for testing purposes to take their live MDS config and bring it into a lab for additional trouble-shooting without impacting their production environment. Use the following steps to do a restore of a MDS backup file to a different Provider-1 MDS machine. To prevent confusion all of the commands below will be executed while in the global MDS environment variable. Type in ‘mdsenv’ to be sure you are in the correct environment.

• Both boxes must be running the same version of the Check Point Provider-1 software. In this case, we’re running Check Point Provider-1 NG FP2.

On the Provider-1 NG Lab MDS:

1. Create the /var/mdsbackup directory and ftp the *.mdsbk.tgz file from your production enviroment to this directory and ‘cd’ into that directory.
2. Execute the command, ‘mds_restore <name of mdsbk file>’.
3. Stop the MDS environment, ‘mdsstop’
4. The type of interface used may differ between the original MDS and the lab MDS. In my environment, the original MDS used cme interfaces and my lab MDS used hme interfaces. If you are using different kinds of interfaces modify the following files, if not, skip to step 5.

• vi the $FWDIR/conf/external.if and change the interface type. This file is the interface that you defined as your “Leading VIP interface” when running the mdsconfig utility.
• For each of your CMA’s you must modify the $FWDIR/conf/vip_index.conf file and change it to the correct kind of interface. The vip_index.conf file is used to assign virtual ip addresses to whichever interface you defined as your “Leading VIP Interface’ when running the ‘mdsconfig’ utility. Each vip_index.conf file is located in $FWDIR/customers/<cma_name>/fw50/conf for each CMA.

1. Next, you need to be sure that you’re using the same ip addressing that you had configured in your production environment. Please modify the following system files:

   • /etc/hostname.*
   • /etc/nodename
   • /etc/hosts
   • /etc/netmasks
   • /etc/defaultrouter (optional)

You’ll need to know the netmask and ip address from the original Provider-1 environment.

1. Reboot.
2. You may need to add in your lab machine’s MDG ip address as an authorized GUI client if you’re using a different ip address then what you normally connect from in your production environment. If so, add in your new MDG ip address as an authorized GUI client via the ‘mdsconfig’ utility.

Upon reboot, you should have a completely functional MDS environment for your lab network. The primary purpose of this lab restore is to test configuration changes to your MDS/CMA environments without affecting the production environment. It’s possible to gain additional trouble-shooting benefits if you have the resources to also build firewall modules in your lab environment, so you can see how potential changes could affect your firewall modules.