7.6 Backups, Snapshots, and Migrate Export

Backups, Snapshots, and Migrate Export

R82 ships three complementary ways to preserve a Security Management Server or gateway configuration: the Gaia snapshot, the Gaia system backup, and migrate_server export. Each captures a different scope, has different restore semantics, and is used at a different point in the maintenance lifecycle. CCSA candidates must know which one to reach for in each scenario.

Gaia Snapshot

A snapshot is a full image of the system at a point in time. It includes:

• The entire file system with customized files.
• System configuration (interfaces, routing, hostname).
• Software Blades configuration.
• The management database (when taken on a Management Server).

A snapshot is large — it contains the whole root partition, part of /var/log, and other important files. It cannot be scheduled. Restore is all-or-nothing: you boot the box from the snapshot, returning the appliance to exactly the state it was in when the snapshot was taken.

From the CLI, take and manage snapshots with the Gaia snapshot command (or add snapshot / show snapshot in clish). On Scalable Platforms (Maestro/ElasticXL/Chassis) use g_snapshot in Expert mode for per-Security-Group-Member operations.

Best practice: take a snapshot immediately after Gaia installation and first configuration, and before any major change (hotfix, JHF, route change, policy migration). Snapshot is the bare-metal rollback mechanism — the right answer when a major change has hosed the appliance and you need to revert the entire OS state.

Gaia System Backup

The Gaia backup command (or the equivalent Gaia Portal page) exports the important configuration files into a much smaller archive than a snapshot. It is the preferred method for regular recovery because:

• It can be scheduled (daily/weekly).
• The file is small and easy to transfer off-box.
• Selected configuration can be extracted without restoring the whole appliance.

On R82 the system backup captures Gaia configuration, Check Point product configuration, and the management database (when run on a Management Server). It does not capture the entire file system, so it is not a substitute for a snapshot when you need a bare-metal rollback. For Multi-Domain Servers use mds_backup, which iterates over each domain.

CLI Snapshot and Backup Syntax

From clish you can manage both:

add snapshot <name>              # create a snapshot
show snapshot                    # list snapshots
delete snapshot <name>           # remove a snapshot
set backup destination <path>    # configure scheduled backup target
add backup schedule <cron>       # schedule recurring backups

From Expert mode, the legacy snapshot command (or g_snapshot on Scalable Platforms) and the backup script are still used. Restore is the inverse: revert to a snapshot in clish/Gaia Portal, or restore from the backup archive on a freshly installed box. Snapshots are not cross-version — a snapshot taken on R82 cannot be restored onto an R82.10 appliance, and snapshots taken on different hardware models are not interchangeable. Backups are more portable but still should be restored on the same major version they were taken from. Always transfer snapshot and backup files off-box to external storage before any major change — a snapshot sitting on the same disk that just failed is not a backup.

migrate_server export

migrate_server export is the tool for moving a Management Server database between servers or versions. It is the current command on R82 — the legacy migrate export (and upgrade_export from older releases) has been replaced. Run from Expert mode in $FWDIR/scripts/:

./migrate_server export -v R82 [-skip_upgrade_tools_check] [-l | -x] [--include-uepm-msi-files] [--exclude-uepm-postgres-db] [--ignore_warnings] <target_dir>/<file_name>
./migrate_server import -v R82 [-skip_upgrade_tools_check] [-l | -x] [/var/log/mdss.json] [--include-uepm-msi-files] [--exclude-uepm-postgres-db] <file_name>.tgz

On R82 the export file extension changed from .tgz (gzip) to .txz (XZ compression). The legacy migrate command in $FWDIR/bin/upgrade_tools/ is still present for same-version migration only; if you try to use it for a version upgrade it blocks you with a clear message pointing to migrate_server. Even when you use migrate_server for same-version migration, behind the scenes it automatically runs the legacy migrate for you.

When to Use Which

Pre-Upgrade Backup Sequence (R82 official)

1. Save a snapshot of the source system.
2. Save a backup of the source system.
3. Collect a CPinfo file.
4. Run the Pre-Upgrade Verifier (PUV); if it succeeds, take a second snapshot, second backup, second CPinfo.
5. Transfer all files to external storage in binary mode (FTP/text transfer corrupts the archive).

Exam Traps

• Snapshot is not deprecated on R82; what was deprecated is the legacy migrate export / upgrade_export.
• Snapshots cannot be scheduled; backups can.
• File extension on R82 is .txz (XZ), not .tgz — this has broken automation scripts that matched the old extension.
• For VSX, follow sk100395; do not use the standard snapshot/backup workflow.
• Backup is the preferred regular recovery method; snapshot is the emergency rollback method. They are complementary, not interchangeable.