Table of Contents
-
Migration of Domain Server between Multi-Domain Management Servers
-
Migrating a Global Domain
-
Exporting a non-Global Domain from a Multi-Domain Management Server
-
Importing a non-Global Domain into a Multi-Domain Management Server
-
Backing up / Restoring a Domain
-
Backing up a Domain
-
Restoring a Domain
-
Domain migration between Security Management and Multi-Domain Management servers
-
Before the migration
-
Migrating from a Security Management Server to a Domain Management Server
-
Migrating from a Domain Management Server to a Security Management Server
-
Known Limitations
-
Troubleshooting
Support for Domain Migration and Domain Backup/Restore is available in:
Support for Domain Migration between different versions (if you migrate to a higher version, then you also perform an upgrade):
- From versions R81.10, R81.20, and higher
- To versions R81.20 and higher
Important Notes:
-
Before you export a database, you must:
-
Update the Application Control signatures
-
Update Anti-Virus, Anti-Bot, and IPS signatures
- Discard or publish all sessions
-
You must use the latest Upgrade Tools package in all types of Domain migrations from sk135172.
Starting in the R81 version, the Domain migration feature is self-updatable. It allows faster release of features and fixes related to upgrade and migration.
Security Management Servers / Multi-Domain Management Servers R81 and higher that have online access to checkpoint.com
, will get the latest available Upgrade Tools automatically.
(1) Migration of Domain Server between Multi-Domain Management Servers
Important - Migrating a Domain is possible only when the source and the destination Multi-Domain Servers have the same version installed.
(1-A) Migrating a Global Domain:
You must migrate the Global Domain to the target Multi-Domain Management Server before you migrate a local Domain that is assigned to the Global Domain.
Local domain migration will be blocked in the import phase if the global domain version that the domain is assigned to is missing from the target machine. Please reassign global domain to all domains that should be exported before the export of the global domain and the local domains.
Note: When a global domain is migrated - the previous one is deleted. Thus, if there are domains assigned to the previous global domain - the migration will be blocked. A new global domain should not be migrated if the previous one is in use.
(1-B) Exporting a Domain from a Multi-Domain Management Server:
See the Management API Reference for your Management Server version.
-
On R81.10 and higher, run:
mgmt_cli export-management [version "TARGET_VERSION"] domain-name "NAME_of_DOMAIN" file-path "/var/log/<NAME_of_DOMAIN>_exported.tgz" --domain 'System Data' --format json
Note: The parameter 'version' is required if the versions of the source server and the target server are different.
-
On R81, run:
mgmt_cli -d "System Data" migrate-export-domain domain <Domain Name> file-path <Full Path to File>.tgz include-logs {true|false}
(1-C) Importing a Domain into a Multi-Domain Management Server:
See the Management API Reference for your Management Server version.
-
On R81.10 and higher, run:
mgmt_cli import-management file-path "/var/log/domain1_exported.tgz" --domain 'System Data' --format json
-
On R81, run:
mgmt_cli -d "System Data" migrate-import-domain file-path <Full Path to File>.tgz include-logs {true|false}
Notes:
-
After the Domain import, you must connect with SmartConsole to this Domain and install the Security Policy on each managed Security Gateway / Cluster / Virtual System / Virtual Router to receive logs from it.
-
If the Domain contains Security Gateway / Clusters you managed with the Provisioning Software Blade:
-
You must install the Security Policy on each SmartLSM Security Profile.
-
If after the migration, the Domain's IP address differs from the IP address before the migration, then after you install the Security Policy on each SmartLSM Security Profile, you must connect to the command line on each managed device and manually fetch the Security Policy with this command:
fw fetch <IP Address of Domain After Migration>
(2) Backing up / Restoring a Domain
(2-A) Backing up a Domain:
See the Management API Reference for your Management Server version.
-
On R81.10 and higher, run:
mgmt_cli export-management domain-name "domain1" file-path "/var/log/domain1_backup.tgz" is-domain-backup true --domain 'System Data' --format json
-
On R81, run:
mgmt_cli backup-domain domain <Domain Name | Domain UID> file-path <Full Path>
(2-B) Restoring a Domain:
See the Management API Reference for your Management Server version.
-
Restore the Domain:
-
On R81.10 and higher, run:
mgmt_cli import-management verify-domain-restore "true" file-path "/var/log/exported.tgz" --domain 'System Data' --format json
-
On R81, run:
mgmt_cli restore-domain file-path <Full Path> verify-only true
-
Delete the Domain
-
Restore the Standby Domain servers and Domain Log servers (they must be created with the same name and IP address):
-
For each Standby Domain server, run:
mgmt_cli set-domain name <Domain Name | Domain UID> servers.add.ip-address <Domain Server IP Address> servers.add.name <Domain Server Name> servers.add.multi-domain-server <Multi-Domain Server Name> servers.add.backup-file-path <Full Path> --format json
-
For each Log Server, run:
mgmt_cli set-domain name <Domain Name | Domain UID> servers.add.ip-address <Domain Server IP Address> servers.add.name <Domain Server Name> servers.add.multi-domain-server <Multi-Domain Server Name> servers.add.backup-file-path <Full Path> --format json servers.add.type "log server"
-
If there is a Management High Availability between the Domain and a dedicated Security Management Server:
-
Re-install the Security Management Server.
-
Reset SIC with the Security Management Server from the Active Domain server.
-
Add GUI clients and administrators to the Domain.
-
Install the Security Policy on each managed Security Gateway / Cluster / Virtual System / Virtual Router, to receive all logs from it.
(3) Domain migration between a Security Management Server and Multi-Domain Management servers
(3-A) Before the migration:
-
Check the Disk Space: The hard disk on the target machine must be at least 5 times the size of the exported database.
-
Make sure to publish changes you wish to migrate, only published changes are exported.
(3-B) Migrating from a Security Management Server to a Domain Management Server
(3-B-a) Export a Security Management Server:
-
Make sure all processes are up and running, with the "cpwd_admin list
" command.
-
Run the "fw logswitch
" command to close the active log files. Only closed logs are migrated.
-
If the target server has a different IP address than the source server, you must prepare the source database before the export:
-
Create a new host object in SmartConsole with the IP address of the target Security Management Server.
-
Define an Access Policy rule to each installed policy, that lets the new host connect to Security Gateways:
Source |
Destination |
Service |
New Server |
Any |
FW1 (TCP 256) CPD (TCP 18191) FW1_CPRID (TCP 18208) |
-
For VSX, add a rule to VSX policy as well (see sk167639 for specific instructions for migration with VSX).
-
Install the edited Security Policy on all Security Gateways and Clusters.
-
Log in with the API command to the "System Data" level and export the database:
See the Management API Reference for your Management Server version.
-
On R81.10 and higher, run:
mgmt_cli export-management [version "TARGET_VERSION"] file-path "/var/log/smc_exported.tgz" is-smc-to-mds true --domain 'System Data' --format json
Note: The parameter 'version' is required if the versions of the source server and the target server are different.
-
On R81 and lower, run:
mgmt_cli -d "System Data" migrate-export-domain file-path <Full Path to File>.tgz include-logs {true | false}
(3-B-b) Import into a Multi-Domain Management Server:
-
Install the Multi-Domain Management Server on the target server.
Note: For an existing Multi-Domain Management Server, create backup prior to importing a new Domain Management Server.
-
Copy the management database file that you exported from the source server to a directory of your choice on the target server. Use FTP, SCP or similar.
-
Log in via API command to the "System Data" level and import the database (for R80.20 Jumbo Hotfix Accumulator and R80.30 Jumbo Hotfix Accumulator, add the option "exported-from-mds false
"). See the examples below.
The command will create a new Domain and new Domain Management Server, and import the source database.
There is no need to create the Domain before the migration.
Note: Make sure the Domain name you wish to create does not conflict with the existing Domains.
See the Management API Reference for your Management Server version.
-
On R81.10 and higher, run:
mgmt_cli import-management domain-name "domain1" domain-server-name "domain1_Server" domain-ip-address "192.0.2.1" file-path "/var/log/smc_exported.tgz" --domain 'System Data' --format json
-
On R81 and R80.40, run:
mgmt_cli -d "System Data" migrate-import-domain domain-name <Domain Name> domain-server-name <Server Name> domain-ip-address <Server IP Address> file-path <Full Path to File>.tgz include-logs {true | false}
-
On R80.20 with the Jumbo Hotfix Accumulator and R80.30 with the Jumbo Hotfix Accumulator, run:
mgmt_cli -d "System Data" migrate-import-domain domain-name <Domain Name> domain-server-name <Server Name> domain-ip-address <Server IP Address> file-path <Full Path to File>.tgz include-logs {true | false} exported-from-mds false
-
Test the target deployment.
-
Disconnect the source server from the network.
-
Add GUI Clients.
-
With the GuiDBedit Tool, edit the value of the parameter hosted_by to see logs - see sk123593.
-
Install the Security policy on all Security Gateways and Clusters.
For LSM environment, install the Security policy on all the LSM Security Profiles.
-
If after the migration, the Domain's IP address differs from the IP address before the migration, and the Domain contains LSM Gateways / Clusters, run this command one time on each of the LSM devices:
fw fetch <IP Address of Domain After Migration>
-
If the target server has a different IP address than the source server - Delete the special Access Control rule you added before the migration:
-
Connect with SmartConsole to the target Domain Management Server.
-
In each Security Policy, delete the Access Control rule with the new Host object you added on the source Security Management Server before migration.
-
Delete the Host object you added on the source Security Management Server before migration.
-
Install the applicable policies on all managed Security Gateways and Clusters.
(3-C) Migrating from a Domain Management Server to a Security Management Server
(3-C-a) Export a Domain Management Server:
-
Make sure all processes are up and running, with the "mdsstat -m
" command.
-
Run the "fw logswitch
" command to close the active log files. Only closed logs are migrated.
Note: Log switch should be executed for the Domain context by running the command "mdsenv <IP Address or Name of Domain Server>
-
If the target server has a different IP address than the source server, you must prepare the source database before the export.
Do NOT change the hostname in the import.
-
Create a new host object in SmartConsole with the IP address of the target Security Management Server.
-
Define an Access Policy rule to each installed policy, that lets the new host connect to Security Gateways.
Source |
Destination |
Service |
New Server |
Any |
FW1 (TCP 256) CPD (TCP 18191) FW1_CPRID (TCP 18208) |
-
For VSX, add a rule to VSX policy as well (see sk167639 for specific instructions for migration with VSX).
-
Install the edited Security policy on all Security Gateways and Clusters.
-
Log in with the API command to the "System Data" level and export the database.
See the Management API Reference for your Management Server version.
-
On R81.10 and higher, run:
mgmt_cli export-management [version "TARGET_VERSION"] domain-name "domain1" file-path "/var/log/domain1_exported.tgz" --domain 'System Data' --format json
Note: The parameter 'version' is required if the versions of the source server and the target server are different.
-
On R81 and lower, run:
mgmt_cli -d "System Data" migrate-export-domain domain <Domain Name> file-path <Full Path to File>.tgz include-logs {true | false}
(3-C-b) Import into a Security Management Server:
-
Install the Security Management Server on the target server. If you change the IP address, make sure to use the same hostname and add license for Security Management Server.
-
Copy the management database file that you exported from the source server to a directory of your choice on the target server. Use FTP, or SCP.
-
Import the database:
See the Management API Reference for your Management Server version.
-
On R81 and higher, run:
$MDS_FWDIR/scripts/migrate_server migrate_import_domain [-l | -x] /<Full Path>/<Name of Exported File>.tgz
-
On R80.40 and lower, run:
$MDS_FWDIR/scripts/migrate_import_domain.sh -sn <Server Name> -dsi <Server IP Address> -o <Path to Export File>
-
Test the target deployment.
-
Disconnect the source server from the network.
-
Add a SmartConsole Administrator with the "cpconfig
" command.
-
Add GUI Client with the "cpconfig
" command.
-
Install the Security policy on all Security Gateways and Clusters.
For LSM environment, install the Security policy on all of the LSM Security Profiles.
-
If the Security Management Server IP after migration differs from the exported Domain IP and it contains LSM gateways/clusters, run the following command once on each of the LSM devices:
fw fetch <IP Address of Management Server>
-
If the target server has a different IP address than the source server- Delete the special Access Control rule you added before migration:
-
Connect with SmartConsole to the target Security Management Server.
-
In each Security Policy, delete the Access Control rule with the new Host object you added on the source Domain Management Server before migration.
-
Delete the Host object you added on the source Domain Management Server before migration.
-
Install the applicable policies on all managed Security Gateways and Clusters.
(4)Known Limitations
(4-A) Limitations for:
(4-B) Limitations for a Domain migration between Security Management and Multi-Domain Management servers
(5) Troubleshooting