Background Gateway Upgrade – Now Available for EA!

[Raz_Zilberman]

Hi All,

We’re excited to announce the early availability of Background Gateway Upgrade, a major step forward in simplifying Security Gateway upgrade operations — now available for testing by interested customers and partners!

What is it?

Background Gateway Upgrade introduces a new upgrade flow where the majority of the upgrade process is handled in the background, with no impact to gateway performance or traffic.

This new capability is currently available under a feature flag through a specific Deployment Agent version in CPUSE.

Customer Benefits

With Background Gateway Upgrade, you can:

• Dramatically reduce downtime during major version upgrades or JumboHotfix installations

• Simplify upgrade planning and execution

• Minimize upgrade risk by pre-validating the upgrade environment

• Improve operational continuity — users and traffic stay unaffected until reboot

We’re here to support you throughout the process and would love your feedback as we shape this into a standard capability for all customers!

Questions? Want to participate? Drop a comment below or contact me directly.

Thanks,
Raz

[Vincent_Bacher]

Hi Raz,

Change management is quite a challenging topic in our organization.

That's why reducing risks and especially downtimes would be strong arguments in the change request process.
Could you share more details on how this new approach works? I'm really interested.

Best,
Vince

[Raz_Zilberman]

Sure, let's have a quick call later this week? ping me in my email - razz@checkpoint.com and I will schedule a call.

[Vincent_Bacher]

Will be happy to contribute.

[the_rock]

I would also be interested to test this in the lab, if possible.

[Raz_Zilberman]

Sure, ping me at my email - razz@checkpoint.com , and I will schedule a call.

[Bob_Zimmerman]

I'm also very interested, and I just sent an email.

Based on how it's described above, it sounds to me like this is more or less how Apple upgrades/updates their operating systems now: create a new logical volume, unpack the upgrade/update there, run whatever tests, then set the bootloader to boot from it. It's a little more complicated than something like illumos' or FreeBSD's boot environments, but it can be used with older filesystems like XFS. If I'm right, it will involve heavy I/O (basically a free resource on a healthy firewall) and very little CPU or RAM consumption.

[CheckPointerXL]

logical volume is cloned and then the upgrade takes place? just to understand how custom files are preserved

[emmap]

As I understand it, our upgrades already work similarly to that. A new root partition is created in the 'upgrade_reserved' disk space, the software is installed and the config is copied over to that new partition. The old root partition is stored as the 'AutoSnapshot' rollback point, which is why it's uncompressed as compared to regular snapshots. I guess we have improved the procedure such that we don't have to stop processes on the running gateway to perform the config copy.

[the_rock]

Wow, that sounds AMAZING!

[PhoneBoy]

Looking forward to seeing this in action!

[Tom_Hinoue]

Sounds great!

I'm curious if this can work backwards once the previous version is compatible to this feature.
It's not that I want to do a downgrade, but just wondering if we can uninstall a hotfix or revert to the previous version incase any issues occur. 

Also, does this mean the policy package from previous version will be compatible even after major version upgrade?

[the_rock]

Super valid and logical point, Tom.

[emmap]

I believe the Lightshots introduced in R82 can do this for us. Your system takes a lightshot at 3am every night to provide a rollback point. The most recent 5 automatic lightshot restore points are retained, along with the FCD restore point.

[the_rock]

Good to know!

[Tom_Hinoue]

Thanks for the follow up!
Can the restore using Lightshots be processed in the background to restore previous settings without any disruption?
This is what was I was wondering of the reverse of the new background upgrade feature. (background downgrade?) 

[emmap]

Ahh, I see what you mean. The current lightshot process certainly isn't intended to be disruption free. I haven't actually tried it yet but I imagine it would still need to reboot.

[Tom_Hinoue]

Thanks for checking.
Yes, I assumed backup/snapshots will need a reboot like it has always been 🙂

I guess I will wait for more news about this new feature. Looking forward to it.

[the_rock]

I guess lightshot is not available for R82 on VM in web UI, though I do see add lightshot there in clish.

[Raz_Zilberman]

correct

[Raz_Zilberman]

indeed, lightshots is part of the new upgrade method

[Phil_Pasquier]

This looks like a revolution! Thank you for your efforts.

I'll drop you an email !

Cheers

[the_rock]

Hey Raz,

Just wanted to circle back on this...is there free demo people can check for this or would I still need to email you to organize a call?

[Magnus-Holmberg]

Sounds great, is the plan to have this within the smartconsole?

[Raz_Zilberman]

Yes:) part of R82.20

[the_rock]

K, just emailed you.