- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
Watch NowOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hello we are running gaia r80.20 Jumbo Hotfix 87 in cluster
We will change the 2 appliances for 2 5800 that will be in cluster and i will install R80.20 Jumbo Hotfix 87 also
Im keeping my management server running on a VM and it's running gaia R80.20 jumbo Hotfix 87 also
After that what step i need to do to export my configuration from the 4800 and put it back on the 5800
Thanks !
See sk108902: Best Practices - Backup on Gaia OS for the best way to do this ! I would suggest to use both:
System Backup (and System Restore)
System Backup can be used to backup current system configuration. A backup creates a compressed file that contains the Check Point configuration including the networking and operating system parameters, such as routing and interface configuration etc., but unlike a snapshot, it does not include the operating system, product binaries, and hotfixes.
Save Configuration (and Load Configuration)
Allows saving Gaia OS configuration settings as a ready-to-run CLI script. This allows you review your current setup and quickly restore the Gaia OS configuration.
Does the system backup (and system restore) will work if it's take on my 4800 and restore on the 5800 ?
It's not hardware dependent ?
Should i not use the migrate export instead ?
migrate export seem to be only for the management server
Just tried it on my 2 fw
[Expert@infFire:0]# $FWDIR/bin/upgrade_tools/migrate
This utility requires the Check Point Security Management Server
So it answer my last question 🙂
SO should this work if i do these steps
I'd like to share my experience with a cluster of 5800 and R80.20 that's running almost all usual TP blades.
By default they run Xeon processors with Hyperthreading so you have 8 cores. I ran the cluster on R80.20 Take 47 for some weeks.
Then when Take 87 came out, I upgraded the standby member vie CPUSE, it rebooted and rejoined the cluster.
Unit A: R80.20.47, Unit B: R80.20.87.
Causing a ClusterXL failover from unit A to unit B caused a CPU error which completely crashed the box, nothing responded short of serial connection.
Reimage, then reinstall of Take 87: same issue. Try a week later with Take 91 when it becomes GA, same crashes happen. Works fine with Take 47 though so I was stuck to Take 47 on that cluster of 5800.
I'd go with R80.30 Take 19 which is anyway the recommended version, it works and cluster failovers didn't cause these crashes anymore.
Thanks for the info
But did you try it with both member at r80.20 Take 87 and then do the failover ?
Yes, and both crashed at the same time. Anyway I tried with a GA take higher than Take 47, Unit A or B first, a failover caused a CPU exception which broke the box and couldn't be recovered short of a reimage.
It's the only 5800 cluster I have under my care, so I don't know if others with the same systems encountered the same issue.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 12 | |
| 10 | |
| 9 | |
| 8 | |
| 6 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 |
Tue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY