Running script in production. Backup or Snapshot?

[RCordova]

I need to add over 200 new IP objects to our management station. I have tested my script in a non-prod environment and it works fine but I'm still a little reluctant to run it on our production mgmt station. As a precaution should I backup or take a snapshot before running the script?

[Kaspars_Zibarts]

If you feel "reluctant", then best is to backup or snapshot. Alternatively, do no publish changes with script, verify manually before publishing, thus you have an option to discard! 🙂 Can always try to revert revision too. So you do have options 🙂

[the_rock]

I honestly cant recall last time I ever told anyone to do snapshot, always backup. But, if you are reluctant and worried, then maybe do both, just to be on safe side. Below link might help clear any differences/confusion.

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Andy

[Timothy_Hall]

A backup should be plenty, I always download the backup file off the system via browser beforehand just in case something strange happens.  A snapshot is an image of the whole system other than Firewall Traffic Logs & the SmartEvent database; I think it is pretty unlikely that running your script will corrupt the underlying Gaia OS in which case a snapshot would be needed to recover.  Snapshots are normally employed prior to in-place upgrades (especially between major code versions) where the chances of the upgrade failing and leaving the system in a corrupt state are nonzero.

[RCordova]

Thanks all for the replies. I will just go with a backup. Appreciate the feedback.

[HeikoAnkenbrand]

Hi @RCordova,

The statement does not apply 100% to your case.

Backup -> If you want to change the hardware of the system.  -> Restore should be performed under the same GAIA software R8x.x + same JHF.

Snapshot -> If you want to use the same hardware. -> Restore should be performed under the same hardware.

Migrate Export vs. Migrate Server Export -> If you want to back up the "Management Server Database"  -> Restore the Check Point database and all management server files (tabel.def, user.def,...) on the same SW + JHF release.

I would use a snapshot or a migrate server export here. Snapshot is the easiest way if you have destroyed your management server;-)

clish > add snapshot <snapshot name>

If something goes wrong with your script:

clish > set snapshot revert <snapshot name>

[genisis__]

I agree.

We do backups as a matter of routine, however if I'm doing adhoc tasks such as HFA or adding objects via scripts, then I find it's pretty quick to do a migrate export.

I generally do a snapshot when doing major upgrades; as mentioned by Tim, store things offline if that is a option. 

In fact if you can do a migrate export, then import into VM, test using the live data in a contained environment so you know the results.

[JozkoMrkvicka]

As everything was clarified and should be clear, I will try to use this thread to ask one off-topic question to all of you:

We all are doing backus, snapshots, migrate exports, save configuration to the file...

Do you really TEST them ? To restore backup, snapshot, migrate import, load configuration ?

I mean, we are all paranoid in case of failure - thats the case we are doing these backup things...

But what in case we really need to perform rollback ? Are you periodically testing backup methods in PRODUCTION ?

Are we 100% sure that we can rely on these backup methods in production and are we sure they will be restored successfully ?

[Ruan_Kotze]

We host customer environments with MDS, thus we do scheduled testing (every two weeks) in an offline environment.  We use CP backups, backups via hypervisor (MDS environment is virtualized) as well as DB exports.  We also use a fantastic little product called Unimus to do clish backups. 

Overkill perhaps, but it makes me sleep well at night and  the resultant increase in effort is minimal.

I've had issues in high-pressure situations with snapshots (not the fault of the technology but a process error on our side) so whilst they work and have their place, it is not something we do as a rule currently. Of course it is still done automatically with major version upgrades.

A failure to restore our environment will have very severe financial and reputational impact for us, so we take this seriously.

[_Val_]

Very good point. Testing backups and snapshots periodically is must, to make sure they are actionable. Very few people actually do.

[JozkoMrkvicka]

Some auditors may require evidence that you have successfully tested the backup restoration process (maybe even in production).

[Kaspars_Zibarts]

I do that often enough as we replicate production environment in the lab, so to get the latest MDS for example, I would do backup restore 🙂 

Gateways, not that often.. 🙂