Migrate_Server Syntax

[Matlu]

Hello, everyone.

We have currently 1 SMS + Cluster SGs, in version 80.40

What we want is to apply some command in the SMS that allows us to do a BACKUP of the rule base.

The documentation is a bit confusing for us now.

We had understood that there was the command "migrate export", but now most of the documentation refers to apply the command "migrate_server".

What is the recommendation for exporting the SMS rule base?

Could you comment the syntax of the correct command to apply in MGMT, please.

Thank you all and best regards.

[Alex-]

You can use migrate_server as follows: $FWDIR/scripts/migrate_server export -v R80.40 /var/log/tmp/sms_r80.40_date.tgz

The path is an example but it must be absolute. Run cpstop or make sure all clients are disconnected to avoid policy changes while the export is being processed.

Then if you want to check your export in a lab or test machine, install an R80.40 SMS, apply the latest hotfix and migration tools and run:

$FWDIR/scripts/migrate_server import -v R80.40 /absolute_path_to/_file/sms_r80.40_date.tgz and wait for the process to complete.

[Matlu]

Thanks for the recommendations.

Now, using "migrate_server" is 100% mandatory, before executing a version upgrade of your GAIA OS?

In our environment, we have 1 SMS in R80.40 version, and another SMS for another site, in R80.30 version.

We need to bring it urgently, to R81.10 version, but the idea is to use CPUSE to upgrade the MGMTs.

I understand that "migrate_server", is to have a "Backup" of the rule base, in case "something" breaks during the upgrade, is that correct?

Both versions, R80.40 and R80.30, can jump "direct" to R81.10, in the SMS, using CPUSE, right?

Regards.

[Alex-]

migrate_server is typically used for the Advanced Upgrade/Migration  where you clean install or stage a new server from scratch and import an existing database, but by its nature of copying everything from a given SMS in an archive it can serve as a form of backup as well.

R81.20 is now widely recommended but for the sake of your question here's the link to the R81.10 information.

https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_RN/Topics-RN/Supported-Upgra...

Supported upgrade paths state that you can upgrade from R80.40 and R80.30 with both kernel versions directly to R81.10.

https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_Installation_and_Upgrade_Gui... provides the different upgrade methods from CPUSE to advanced upgrade.

For R80.40 to R81.10, you could use CPUSE Blink and you will get an upgrade progress report as it goes along.

For R81.20, you get the benefit with a brand new server installation which has been debated here, fixing some storage parameters for better performance but you can also go with CPUSE.

Always ensure you have the relevant backups and test them possibly in a test VM before proceeding.

[Matlu]

Basically, it is the customer who wants the SMS to be tested first in version R81.10.

In your recommendation to take it from R80.40 -> R81.10, I understood that we could use the CPUSE Blink Image, right? (This gives the benefit that it updates the Hotfix in a single MGMT reboot, as far as I understand).

CPUSE Blink Image, would you recommend it to take the R80.30 -> R81.10?

Obviously, we understand that it is the "migrate_server" who will serve as the "Backup of the rule base".

Right?

Thank you.

[Alex-]

I haven't personally done any Blink upgrade from R80.30 to R81+ but the Release Notes state it's supported.

CPUSE is the recommended approach with Blink as it upgrades the OS and installs the latest hot fix in one pass, then reboots and proceeds with the database import in a controlled process.

I did a bunch of R80.40 to R81+ with CPUSE/Blink without notable issues.

Anyway, you can download the Blink and run the verifier. 

The CPUSE approach is really well documented in the links I gave you.

Just make sure you follow the Important Notes at the beginning about backup and restores but for a standard SMS it should go smoothly.

It might also help if your SMS have the latest hotfix in their current version which might fix things relevant to the upgrade process, the SMS I upgraded were always running the last or at leat recent hotfixes.

[Matlu]

It can be considered a "good practice" that the Backup of the SMS box is:

1. Access by SSH to the CLI, and get a "show configuration".

2. Apply the "migrate_server", to obtain the backup of the rule base.

I know that the recommendation usually says to take a "SNAPSHOT" to the MGMT, but this usually takes too much time, and many times, you have problems because of the amount of disk space that the SNAPSHOT demands.

Can the indicated steps be considered appropriate for a correct BACKUP?

Greetings

[Alex-]

show configuration, migrate_server export and any custom modification to table files you may have done which are not exported I think.

By the way, Blink will take a snapshot as part of the upgrade process.

[the_rock]

Ola bro,

All you have to do is follow exactly instructions from the sk below, works 100% of the time.

Andy

https://support.checkpoint.com/results/sk/sk135172

If you get consused, let me know, I had done it many times.

[Josh28]

Dear community,

I’m bumping this thread because I have some questions regarding the migrate_server utily.

I have 2 MDS (primary and secondary) to migrate from R81.10 to R81.20. To finally have the new xfs filesystem, I’ve fresh installed 2 news VM in R81.20 with the same IP Addresses as the old one. Using the “./migrate_server verify -v” utility, I’ve corrected the errors and now I’m ready to export and import the configuration. My questions about the process are:

• Do I need the perform the export/import from both primary and secondary MDS ?
• About the export of the logs using the option “-l”, has we have a lot of CMA and many logs, I’m afraid it would make the export/import process long and expensive it terms of disk space. What are your feedback about this ? Should I import manually the logs after the export/import ?

Thank you all for your feedback.