Shore Up
"Three safes of different sizes lined up on a shelf — a small pouch, a filing box, and a heavy vault — each holding a copy of the same building's blueprints."
Security

"Back Up a Check Point Gaia System: Backup, Snapshot, and Migrate Export"

Ketan Aagja7 min read
No ratings yet

Check Point gives you three different ways to save the state of a Gaia machine, and admins mix them up constantly. They are not interchangeable. This guide walks all three on Gaia R81.20 (standalone Security Management Server or gateway, not a Multi-Domain Server), driven from Gaia clish with a bit of expert mode. If you run MDS the paths and tools differ — stop and read the Multi-Domain guide instead.

Before you run this

These procedures capture and, in the case of restore/revert, replace the configuration or the entire operating system of a production firewall or management server. A snapshot revert reboots the box and rolls the whole OS back to a point in time — that is destructive to anything changed since, and it is not undoable once it completes. A backup restore overwrites the current configuration.

  • Privileges: add backup / add snapshot run from Gaia clish under an admin user with read-write access. migrate_server runs in expert mode (root). Reverting a snapshot requires the same read-write clish access.
  • Test first: read each command before you run it, and rehearse the whole export → import cycle on a lab VM or a spare appliance before you trust it for a real migration. A backup you have never restored is a hope, not a backup.
  • Console / out-of-band access: keep a console or OOB session open, especially for a snapshot revert — it reboots the machine, and if the reverted image has different network config you can lose management and production traffic at the same time. Do not do this over the only SSH session you have.
  • Order of operations: take a fresh backup (and ideally a snapshot) before you change or upgrade anything, and do restores/reverts in a maintenance window.
  • Rollback path: for OS-level problems, set snapshot revert is Check Point's own rollback. For configuration problems, set backup restore puts the saved config back. These are the rollback — so make sure one exists before you touch the system.

Which one do I actually need?

  • System Backup — Gaia OS settings and the Check Point product configuration/database, as a compact .tgz. Small, fast, and the everyday choice before a policy or OS-setting change. Restore it onto the same version on comparable hardware.
  • Snapshot — a full image of the OS and everything on it. Large, slower, and tied to the platform and version. This is your "put it back exactly as it was" safety net around risky work like a hotfix or upgrade.
  • Migrate Export — exports only the management database (objects, rules, users, certificates) in a hardware- and (within limits) version-portable form. This is the tool for moving a management server to new hardware or a new version, not for daily backups.

System Backup (config + product database)

From clish. A local backup lands under /var/CPbackup/backups/.

# Back up locally
add backup local

# Or push straight to an SCP server (recommended — don't leave the only copy on the box)
add backup scp ip 192.0.2.50 path /backups username backupuser password YOURPASSWORD

Replace 192.0.2.50, /backups, backupuser, and YOURPASSWORD with your own values. ftp and tftp variants exist with the same shape if you prefer them.

List what you have and check status:

show backups
show backup status

Restore is the mirror image. This overwrites the current configuration, so do it in the window with console access:

set backup restore local <backup_file_name>

Use the exact filename shown by show backups. For an SCP-hosted file, the set backup restore scp ... form takes the same connection parameters as the add backup scp line above; confirm the exact keywords against the R81.20 Gaia Administration Guide before you run it against production.

Snapshot (full OS image)

Snapshots are managed from clish and stored under /var/CPsnapshot/. They consume significant disk — check free space before you start, because a failed snapshot mid-way is its own outage.

# Create a named snapshot with a description
add snapshot pre_upgrade_2024 desc "Baseline before R81.20 jumbo hotfix"

# List snapshots
show snapshots

Reverting is the powerful and dangerous part. It reboots and rolls the entire system back:

set snapshot revert pre_upgrade_2024

Run that only from console/OOB, in the window, with a plan for the reboot. To clean up old images:

delete snapshot pre_upgrade_2024

On some appliance models, snapshots are also exposed in the Gaia Portal under Maintenance; the CLI above is the version-stable path, so I lead with it. Note that a snapshot lives on the appliance's own disk — export it off the box (see the export option in the snapshot tooling, documented in the Gaia Administration Guide) if you want it to survive a disk failure.

Migrate Export (management database, for migration)

This is for management servers when you are moving to new hardware or a new version. Run it in expert mode. The tool is migrate_server under $FWDIR/scripts/:

expert
cd $FWDIR/scripts
./migrate_server export -v R81.20 /var/log/mgmt_export.tgz

-v R81.20 states the target version and the last argument is the output file. Confirm the exact flags for your build — Check Point has changed migrate_server's options across R80.x/R81.x (there are switches for including/excluding logs and for domain scope) — against the R81.20 Installation and Upgrade Guide, section on migrate_server. I am not going to guess flag names that could silently produce an incomplete export.

Two things that bite people: stop the export from writing into a filesystem that is already tight on space, and always copy the resulting .tgz off the box immediately.

Import on the target (matching version) uses the same tool with import:

cd $FWDIR/scripts
./migrate_server import -v R81.20 /var/log/mgmt_export.tgz

Again, verify the import flags in the Installation and Upgrade Guide for your exact version before running it against a live target.

Verify it worked

  • Backup: show backups lists the new file with a timestamp. Copy it off the box and confirm the size is non-zero. The real proof is a restore into a lab VM.
  • Snapshot: show snapshots lists the named snapshot. Confirm /var/CPsnapshot/ has free space left and note the size.
  • Migrate export: the .tgz exists and is non-zero; the tool prints a success line on completion. The only trustworthy verification is a successful migrate_server import into a test management server of the same version.

Undo / rollback

  • A backup is undone by restoring the previous backup (set backup restore ...).
  • A snapshot revert is undone only by having taken a newer snapshot first — there is no "un-revert", so snapshot the current state before you revert to an old one if you might want to come back.
  • A migrate export creates a file and changes nothing on the source; deleting the .tgz is the entire cleanup. An import, by contrast, replaces the target's database — protect the target with its own backup first.

When in doubt about a flag or a filename, check show backups / show snapshots for the real names and the R81.20 Gaia Administration and Installation & Upgrade Guides for the exact syntax rather than typing from memory into a production box.

Written by
Ketan Aagja

Runs enterprise networks and security for a living, and writes Shore Up to turn two decades of hands-on Linux, Windows and mail-server work into guides you can actually use.

More about the author →

Was this article helpful?

Tap a star — no sign-in needed.

Be the first to rate this article.