Better way to backup a firewall?

[TechGromit]

We have been using the backup feature on the CLI, using the "add backup local" command, we would then copy the file off and store elsewhere. Recently we had a firewall fail and were shipped a replacement. We changed the OS version to 81.40, and applied the same hotfix, but the build was different, so the backup we had refused to restore because of a different build. We were able to recover by swapping the Hard Drive from the failed unit to the working unit.  The question I have is if i can't restore with the backups, why I'm I doing them. I have been copying off the config via CLI, with the idea of restoring the config on a replacement firewall and using a policy push to install the existing firewall rules on it. but there must be a better way to create backup/images/ whatever where it's not as picky about the current state of the replacement hardware when preforming a restore.

[the_rock]

See, here is the issue...so say, just as an example, you have 2000 series box and you want to restore that backup to say 6000 series appliance. That would NEVER work, as interfaces and everything is different, so 2000 backup could not be restored and thats why you need to have show configuration from old appliance and then copy bits and pieces to new appliance.

Here is what I always do. On old box, from expert mode, run -> clish -s "show configuration" > /var/log/config.txt and then save the file, copy it to a new appliance to same dir and then from clish on new appliance, run -> load configuration /var/log/config.txt and it would error out depending on the line and then you simply fix the line it complained about and do it again. You may have to do this few times (depending on the config), but it does work.

Yes, I agree, its not the optimal way, but best I know of.

Hope that helps.

Andy

[TechGromit]

Different hardware, yes agreed it will never work.  Replacement hardware that is of the same model, a backup/image/snapshot should be restoreable. There may be some leg work involved to get it in the same OS family, like 81.40.

[the_rock]

What @Wolfgang said is totally logical and correct and yes, I also believe you meant R80.40. Either way, command he gave actually ensures that backup bypasses any hotfixes needed and then you can install them manually later. 

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

[Wolfgang]

@TechGromit  restore from an existing backup requires same hardware, same software release and same hotfixes. The hardware and software release will be mandatory, wrong hotfixes can be used with a changed setting „dbset backup:override_hfs“. Follow Restore from Gaia system backup fails with "The following hotfixes seem to be missing" 

If you want a simple restore, you can create snapshots, export them and in the First Time Wizzard of the new appliance you can import these snapshot.

Question about you’re mentioned release 81.40. I think we are talking about 80.40 ?

[TechGromit]

---

@Wolfgang wrote:

Question about you’re mentioned release 81.40. I think we are talking about 80.40 ?

---

---

probably I knew there was an 8 somewhere in the version. 🙂

[Vladimir]

In addition to copying Gaia configuration, scheduled backups are also preserving Check Point-specific configuration files (listed in sk160392).

So for different use cases, any or all may be necessary:

1. Gaia OS configuration file (created using save configuration <filename>), convenient, since with offline modifications, it could be easily loaded to a different hardware or VM.

2. Appliance Snapshot (partition image recovery in case of RMA to identical appliance)

3. Backup (much smaller than snapshot and could be used with last snapshot to bring gateway to the latest known good state)

More on this in my book "Check Point Firewall Administration R81.10+", "Backup and
Recovery Methods" section of Chapter 6.

[_Val_]

Look into CDT, tht might be a great backup tool.

[G_W_Albrecht]

Best summary of most options is found here: sk108902: Best Practices - Backup on Gaia OS