Database import

[babicmilan]

Hello, after I have tried to import database ...

[Expert@CP-MGMT-EPRS_BL:0]# ./migrate import /var/log/SMS.tgz
The import operation will eventually stop all Check Point services (cpstop).
Do you want to continue? (y/n) [n]? y

Extracting the database...

Migrate is only supported between machines with the same take

Execution finished with errors. See log file '/opt/CPshrd-R81.20/log/migrate-2024.04.10_16.33.26.log' for further details

What is cause of error?

Which takes are different? Atached log.

Best regards,
Milan Babic

[PhoneBoy]

The take refers to the level of Jumbo Hotfix installed on both systems.
Why are you using the legacy migration tool?
You should be using migrate_server from R80.20 onward: https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_SecurityManagement_AdminGuid... 

[babicmilan · Accepted solution]

Yes, Jumbo Hotfix on both systems were different. It is cause of error: "Migrate is only supported between machines with the same take"

But, now I have installed Jumbo Hotfix Take 53 as source server before migrate import operation. Again, I get some error and I don't know cause.

(attached documents). After I finish migrate import and run "api status" command some of processes are stopped

CP-MGMT-EPRS_BL> api status

API Settings:
---------------------
Accessibility: Require local
Automatic Start: Unknown

Processes:

Name State PID More Information
-------------------------------------------------
API Stopped 0
CPM Stopped 0
FWM Stopped 0
APACHE Started 14071

Port Details:
-------------------
JETTY Internal Port: 0
JETTY Documentation Internal Port: 0
APACHE Gaia Port: 443

Profile:
-------------------
Machine profile: 24800-35800 with SME
CPM heap size: 3072m

Apache port retrieved from: dbget http:ssl_port

--------------------------------------------
Overall API Status: The API Server Is Not Running!
--------------------------------------------

API readiness test FAILED. The server is down and unable to receive connections!

Notes:
------------
To collect troubleshooting data, please run 'api status -s <comment>'

CP-MGMT-EPRS_BL>

[the_rock]

Ok, so if jumbo takes are the same, just to confirm, did you follow below process?

Best,

Andy

Pozdrav 🙂

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

[babicmilan]

Yes, I have tried a both methods, legacy and new migration tool but without success.

[the_rock]

Can you attach output of cpinfo -y fw1 on both current and new system?

Andy

[babicmilan]

Hello, after reboot of SMS, I get a following situation

CP-MGMT-EPRS_BL> api status

API Settings:
---------------------
Accessibility: Require local
Automatic Start: Enabled

Processes:

Name State PID More Information
-------------------------------------------------
API Started 13469
CPM Started 13469 Check Point Security Management Server is running and ready
FWM Stopped 0
APACHE Started 12056

Port Details:
-------------------
JETTY Internal Port: 62675
JETTY Documentation Internal Port: 51583
APACHE Gaia Port: 443

Profile:
-------------------
Machine profile: Large env resources profile with SME or Dedicated Log Server
CPM heap size: 1280m

Apache port retrieved from: dbget http:ssl_port

--------------------------------------------
Overall API Status: Started
--------------------------------------------

API readiness test FAILED. The server is down and unable to receive connections!

Notes:
------------
To collect troubleshooting data, please run 'api status -s <comment>'

CP-MGMT-EPRS_BL> cpinfo -y fw1

This is Check Point CPinfo Build 914000239 for GAIA
[FW1]
HOTFIX_NGM_DOCTOR_AUTOUPDATE
HOTFIX_R81_20_JUMBO_HF_MAIN Take: 53
HOTFIX_GOT_MGMT_AUTOUPDATE
HOTFIX_WEBCONSOLE_AUTOUPDATE
HOTFIX_PUBLIC_CLOUD_CA_BUNDLE_AUTOUPDATE
HOTFIX_VCE_R81_20_AUTOUPDATE
HOTFIX_GOT_TPCONF_MGMT_AUTOUPDATE

FW1 build number:
This is Check Point Security Management Server R81.20 - Build 010
This is Check Point's software version R81.20 - Build 024

CP-MGMT-EPRS_BL>

[babicmilan]

After reboot FWM process is stopped, I think that it is a reasom why I can't to log in via Smart Console application and get error (attached picture)

[the_rock]

100% thats the reason. Please run cpm doctor script from $FWDIR/scripts

Andy

[babicmilan]

Please, can you tell me exact command sinax

[Expert@CP-MGMT-EPRS_BL:0]# cd $FWDIR/scripts
[Expert@CP-MGMT-EPRS_BL:0]#

[the_rock]

./run_cpmdoc.sh

[babicmilan]

Hello, sorry for later answer.

I have converted *.html to *.pdf document.

[PhoneBoy]

cpmdoctor is showing log indexing crashing:

10399093 Apr 12 14:24 /var/log/dump/usermode/cpsemd.56480.core.gz
10467136 Apr 12 14:26 /var/log/dump/usermode/cpsemd.60501.core.gz
2427927 Apr 15 10:11 /var/log/dump/usermode/log_indexer.26598.core.gz
2427444 Apr 15 10:12 /var/log/dump/usermode/log_indexer.31435.core.gz

Best to engage with the TAC here: https://help.checkpoint.com 

[the_rock]

I see what Phoneboy is saying. I also checked the doc and those are the only errors coming up, nothing else.

Andy

[Jheff_Reis]

Hello Babic,

Can you to resolve this case, I've with same problem...

[the_rock]

Just run ./runcpm_doc.sh script from $FWDIR/scripts and examine the output.

Andy

[fpaez]

Hello everyone,

I also face the same issue with r81.20 with a customer. I found out that the customer upgraded to R81.20 last year which means they used the ISO Check_Point_R81.20_T631. Please notice that Check Point changed this one this year (2024) due to the vulnerability with C2S VPN, and now the ISO is Check_Point_R81.20_T634.

I made a mini lab to confirm this and using the ISO with T631 run the import correctly. Maybe this is the issue you are facing. 

Best Regards,

Reagles

IMPORTANT NOTE: I replicated my lab environment twice (in different vmware environments) and for some reason I do not know, the second time I had to run the import almost 3 times (one after the other), in the third one the import run correctly.

[babicmilan]

---

@fpaez wrote:

Hello everyone,

I also face the same issue with r81.20 with a customer. I found out that the customer upgraded to R81.20 last year which means they used the ISO Check_Point_R81.20_T631. Please notice that Check Point changed this one this year (2024) due to the vulnerability with C2S VPN, and now the ISO is Check_Point_R81.20_T634.

I made a mini lab to confirm this and using the ISO with T631 run the import correctly. Maybe this is the issue you are facing. 

Best Regards,

Reagles

IMPORTANT NOTE: I replicated my lab environment twice (in different vmware environments) and for some reason I do not know, the second time I had to run the import almost 3 times (one after the other), in the third one the import run correctly.

---

Hello fpaez,

I am sure that I have used ISO Check_Point_R81.20_T631 because I have been doing it two months before a new ISO Check_Point_R81.20_T634 was launched. I don't know the real reason why the problem happened.

Luckily, I have found some older backup, restore configuration and resolve the problem on another way.

Best Regards,

Milan Babic

[Pablo_Munoz]

In case this still helps anybody, 'Take' is the word that is internally used to refer to the Gaia 'Build' version too. So if Jumbo version is confirmed to be OK, the issue is most probably referring to a mismatch on the 'Build' version of the operating systems, just like FPaez mentioned with the ISO images.

Easy way to check if there is a difference, from clish run 'show version all' (or 'show version os build') and confirm that the Build number is also the same between servers. This is how it looks like for me:

> show version all

Product version Check Point Gaia R81.20
OS build 627
OS kernel version 3.10.0-1160.15.2cpx86_64
OS edition 64-bit

Make sure the target server matches this version too, not just the Jumbo!

[JozkoMrkvicka]

Or maybe update CPUSE deployment agent to check if OS build numbers match during package verification ? If secondary management is about to be upgraded, it must communicate with primary management. There is some check already in place.

[Rohit_Raut]

Hi, I am also facing same issue. I have R81.20 build 631 mgmt server which is on-prem. I need to migrate it to AWS. The mgmt server which I have launched on AWS is R81.20 build 634. Is there any workaround to restore the backup on R81.20 build 634?

[Pablo_Munoz]

I was able to do this for a customer by exporting the source database using "migrate_server export" command (this is the new method, explained in the admin guide) instead of "migrate export" which is the old way.

The exported database would need to be imported into the new server using "migrate_server import" as well, I don't have the exact syntax handy but it's mentioned multiple times in the Installation and Upgrade Guide for R81.20.

I hope this helps.