Migrate import 80.30 => 80.40

[Mike_Jensen]

I am trying a migrate import from my 80.30 SMS to a 80.40 SMS.

I have verified that the versions of the migration tools on both SMS's are the same.

I receive an error on the import:

Database export was done with migration tools for different version.
You must export and import database with migration tools for version
installed on destination machine.

Execution finished with errors. See log file '/opt/CPshrd-R80.40/log/migrate-2021.06.28_10.58.36.log' for further details

I am trying to use the -skip_upgrade_tools_check -v to get the import to work but can't seem to get that right:

[Expert@SMS1-8040:0]# pwd
//opt/CPsuite-R80.40/fw1/bin/upgrade_tools
[Expert@SMS1-8040:0]# ./migrate import -skip_upgrade_tools_check -v R80.40 SMSfrom8030.tgz

Use the migrate utility to export and import Check Point
Security Management Server database.

Usage: migrate <ACTION> [OPTIONS] <FILE>

Action (required parameter):

export - exports database.

import - imports database.

Options (optional parameters):

-l - Export/import logs without log indexes.
-x - Export/import logs with log indexes.

Note: only closed logs are exported/imported.

-f - Filter private data.

Note: option is valid for export mode only.

-n - Run non-interactively

--exclude-uepm-postgres-db - skip over backup/restore of PostgreSQL.

--include-uepm-msi-files - export/import the uepm msi files.

--exclude-licenses - skip over backup/restore of licenses.

File (required parameter):

Name of archived file to export/import database to/from.
Path to archive should exist.

Note:
Run the utility either from the current directory or using
an absolute path.

[Expert@SMS1-8040:0]#

The SMSfrom8030.tgz is located in //opt/CPsuite-R80.40/fw1/bin/upgrade_tools

[PhoneBoy]

You're trying to use the legacy migration tools. You should be using the new migration tools starting from R80.20 onward.
See: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Mike_Jensen]

Thank you PhoneBoy.  I take it I have to take the export from 80.30 using migrate_server?  What is the correct syntax for the export / import?  I see the examples but they seem to be for a MDS.  I don't have a multi domain environment.  I don't know if that makes a difference or not.

I found the migrate_server script in /opt/CPsuite-R80.30/fw1/scripts , but can't seem to get it to run

I have tried:

./migrate_server export /var/log/tmp/SMSexport

migrate_server export /var/log/tmp/SMSexport

[the_rock]

Hey Mike,

Here is the best way to do it...once you download R80.40 upgrade tools and import them into R80.30 mgmt upgrade_tools dir (what I do is copy existing tools to say  a new folder called updated _upgrade_tools and then copy R80.40 tools in there, once done, run chmod 777 * and run  ./migrate export R80.30_export and once done, copy that  file to R80.40 server (to same dir $FWDIR/bin/upgrade_tools (maybe do chmod 777 * command as well) and then run ./migrate import R80.30_export (or whatever name you gave it) and that will import the config.

I had done this numerous times and never a problem. 

[PhoneBoy]

You shouldn’t be using the legacy migration tools to migrate from any release R80.20 or above.
They should only be used to migrate from an earlier release to releases up to and including R80.40.
They may still be present and may still work but you will have a better experience with the newer tools.

[the_rock]

Thank you, I will keep that in mind. I used method I mentioned for R80.30 to R80.40 and it worked, but if this is newest method, will definitely execute those commands next time. 

Cheers!

[Power_Support]

Hi @the_rock,

Typical beginner issue.

Security bugs can be introduced when 777 permissions are granted. Linux lesson one, only grant permissions that are absolutely necessary.

You can also use 770 here.

[the_rock]

I run that command by habit, never gave me problems 🙂

[G_W_Albrecht]

See: sk135172: Upgrade Tools package for upgrade from R80.20 and above and sk163814: Security Management Upgrade troubleshooting (new upgrade process)

[Mike_Jensen]

Following the commands at the bottom of sk135172 the process just sits on Stopping Check Point services ...  I am over 30 minutes now.  Is it suppose to take this long?

[Expert@SMS-1:0]# $MDS_FWDIR/scripts/migrate_server export -skip_upgrade_tools_check -v R80.30 /var/log/tmp/SMS1

The export operation will eventually stop all Check Point services (cpstop). Do you want to continue (yes/no) [n]? yes
Stopping Check Point services ...

[PhoneBoy]

It's not uncommon for that command to take a while to complete, especially in larger environments.

[PhoneBoy]

The correct syntax for migrate_server is listed in the SK I linked above.
It is different from the legacy migratIon tools.

[Mike_Jensen]

The SK's show the syntax example as  $MDS_FWDIR/scripts/.....  I was able to make this work correctly using $FWDIR/scripts/migrate_server  instead.  I wish the SK had an example with $FWDIR as well.

When on 80.40 is it acceptable to use the old style migrate export to have a backup of my policy to use if I ever needed to rebuild my SMS and then import to 80.40 (no version change)?

[PhoneBoy]

On a non-MDS system, $MDS_FWDIR should equal the same thing as $FWDIR (just FYI).
I'm not clear on the precise status of the old migration tools in terms of support.
That said, it seems safe to export/import on the same version, but I would test it before relying on it. 
The resulting export from migrate_export should be smaller.

[the_rock]

Did you download R80.40 upgrade tools and then import them onto R80.30 before doing the migrate export? Since versions are different, this is definitely a must.

[RamGuy239]

Upgrade Tools are no longer needed, and no longer recommended since R80.20. Upgrade Tools / Migration Tools has been replaced with $MDS_FWDIR/scripts/migrate_server which is a script that will automatically update itself if the management installation has a connection with updates.checkpoint.com.

Gone are the days where you have to manually grab migration tools from a newer version in order to get a database export in the correct version. Everything is explained in sk135172.

Not only is this much easier compared to fiddle with various migration tools. But it's also way more transparent in its process. The script is verbosely providing you much better information on what it doing during both export and import. And it's running interactively so you don't have to worry about your SSH session idling before it's done when dealing with large databases.

You simply run $MDS_FWDIR/scripts/migrate_server export -v RXX.XX /path/filename.tgz
If you want to include logs you can simply add -l or -x if you want to include logs and indexing. Indexing data is not compatible between R80.xx and R81.xx so you'll have to use -l if you are moving between R80.xx and R81.xx.

If you are going to include the logs the export will be much larger so I would always recommend trimming down the number of logs before doing the export. Let's say you have 5 months of logging data you will most likely not need to have all 5 months included in the export so if you can trim it down to something like 1 month worth or even less it will make for a much more efficient export and import.

When you want to import you do the same:

$MDS_FWDIR/scripts/migrate_server import -v RXX.XX /path/filename.tgz
If you did the export including logs (-l) or including logs and indexing (-x) you have to specify this in the import as well. You will have to add the -l or -x when doing the import.


I can't really see any reason why anyone would use the legacy upgrade tools / migration tools over this migrate_server script. It's simply superior in pretty much every possible way. The only downside is that it's R80.20+, if you are going from any older versions you will have to use upgrade tools / migration tools.

[Mike_Jensen]

Thank you for the information.  The scenario I am proposing using the old migrate export would be if I am NOT migrating to a different version and I simply want a backup file of my policy.  Migrate export seems to be a lot faster and doesn't require a cpstop / cpstart.  I agree moving between versions migrate_server is the better option.

[the_rock]

I can only speak for myself, but I used migrate export and import regardless of the version and never had a problem at all and it was always super fast.

[PhoneBoy]

migrate export requires a cpstop/cpstart.

[the_rock]

I agree, but personally, I never found that to be a show stopper 🙂