Improvement Suggestion for Gaia System Backup – Make Restore Dependencies Visible

[israelfds95]

I would like to suggest an improvement to the Gaia System Backup functionality. I have frequently faced problems when restoring System Backups because some required software dependencies are not visible before the backup is collected. Normally, before collecting a System Backup, I check the Gaia version, ISO build and installed Jumbo Hotfix Take, so I can prepare the same or another appliance with exactly the same software versions before restoring the backup. However, even when doing this, the restore can fail because of dependencies that were not visible in Gaia.

For example:

I recently collected a System Backup from a 6600 running R82 Build 777 + JHF Take 122. Before collecting the backup, Gaia just showed Take 122 as the installed Jumbo Hotfix.

I then formatted the target 9100 with the same R82 Build 777, installed JHF Take 122, and tried to restore the System Backup. However, the restore failed because the backup required BUNDLE_R82_JUMBO_HF_MAIN#91.

To complete the restore, I had to uninstall Take 122, install Take 91, install Take 122 again, and then restore the System Backup. For one appliance this is already inconvenient (and is a waste of time), but when working with tens or hundreds of firewalls, discovering these dependencies through trial and error can result in a significant waste of time.

My suggestion

It would be very useful if Gaia run a verification on System Backup and displayed the complete restore requirements (like a restore path) for each System Backup before downloading or after downloaded. For example:

Restore Requirements
Gaia: R82 Build 777
Current JHF: Take 122
Required dependencies: Take 91 → Take 122

Gaia already seems to know this information, since the restore process can identify the missing Take 91. My suggestion is simply to make these dependencies visible beforehand, allowing administrators to prepare the appliance correctly before attempting the restore. This would make System Backup much more predictable and useful, especially in large-scale deployments.

Has anyone else experienced this behavior with System Backup?

[David_C1]

Yes, and agree it is dumb. Not sure why it should matter what JHFA takes were installed previously if you are trying to restore to a machine with the same final JHFA installed. Perhaps there is a technical reason...?

Dave

[Bob_Zimmerman]

It's to let you uninstall the jumbo. If you don't go through the same path, then uninstalling stuff on the box restored from backup would give different results from uninstalling the same stuff on the original box.

[Bob_Zimmerman]

I mostly don't take backups of firewalls.

If certain changes go wrong, I use a snapshot to get back to the state before the change.

If a drive fails, the other drive in the RAID should keep the member up and running.

If a cluster member fails, I rebuild it from another member of the cluster. I find it faster than trying to reproduce the same version-and-hotfix installation path you noted as a problem, especially if you've installed jumbos freqently.

If a whole cluster fails, a sizable chunk of the datacenter is likely damaged, and the network around it will need to be rebuilt. I find backups not useful for recovering from this, because I have to make enough other changes I'm effectively building a new cluster anyway.

[Tom_Hinoue]

I just stumbled across this issue while working with R82.10.
I raised a TAC case and am now waiting for a hotfix.

Restore from Gaia system backup fails with hotfix information does not match
https://support.checkpoint.com/results/sk/sk1000023

In my case, I started with a fresh R82 installation on a 9100/Smart-1 appliance, then upgraded to R82.10 (no JHF), applied JHF Take 40, and then applied JHF Take 44. The backup was taken at this point.

I then tried to restore the backup to an appliance that followed this upgrade path:

R82 fresh installation → R82.10 (no JHF) → JHF Take 44

The restore failed.

The strange part is that the backup/restore also failed even when I followed the exact same upgrade path (same version/build) as the appliance where the backup was originally taken.

I’m honestly wondering why this backup/restore scenario wasn’t fully tested by RnD before the software was released.
I agree that backup/restore should be a much more straightforward process.

I now have to wait for the hotfix before I can restore the backup and continue investigating on my customers original issue.
I honestly didn’t expect to get stuck at this point...

[israelfds95]

In my experience, restoring a System Backup after uninstalling a problematic JHF has worked well. Over the last few months, I've used this approach several times to recover from JHFs that caused serious issues, such as SMS, CPM, or API failures, avoiding the need to roll back to VM snapshots.

However, the problem described in this post is becoming increasingly frequent and frustrating. Your case is even more concerning because the restore failed despite following the exact same upgrade path. I believe Check Point needs to improve the reliability and testing of this process, as System Backup is a critical recovery mechanism we should be able to trust. Thanks for sharing your experience, and I hope the hotfix resolves your issue!