ExamFinch.com My Study

Study guide

7.6 Backups, Snapshots, and Migrate Export

Practice this exam

CCSA R82 — Check Point Certified Security Administrator Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Architecture

1.1 CCSA R82 Exam Facts 1.2 Standalone vs Distributed Deployment 1.3 Gaia OS, clish and expert Mode 1.4 The SmartConsole Suite 1.5 Secure Internal Communication and the ICA

2 Chapter 2: Security Policy & Access Control

2.1 Policy Packages 2.2 Access Control Policy Overview 2.3 Ordered Layers and First-Match Evaluation 2.4 Inline Layers and Nested Rule Matching 2.5 Access Rules: Fields, Actions, and Track Options 2.6 Implied Rules and Global Properties 2.7 Stealth and Cleanup Rules: Placement and Best Practice 2.8 Hit Count and Policy Install Workflow

3 Chapter 3: Network Address Translation (NAT)

3.1 NAT Overview in Check Point 3.2 Hide NAT (Many-to-One) 3.3 Static NAT (One-to-One) 3.4 Automatic vs Manual NAT and Proxy ARP

4 Chapter 4: Identity Awareness

4.1 Identity Awareness Overview 4.2 Active Directory Query 4.3 Identity Collector 4.4 Identity Agent 4.5 Captive Portal and Access Roles

5 Chapter 5: Threat Prevention

5.1 Threat Prevention Overview 5.2 Application Control 5.3 URL Filtering 5.4 Intrusion Prevention System (IPS) 5.5 Anti-Bot and Anti-Virus 5.6 Threat Emulation and Threat Extraction 5.7 TP Profiles, Best Practice, and Ordered Layers for TP 5.8 HTTPS Inspection

6 Chapter 6: ClusterXL — High Availability, Load Sharing, and Failover

6.1 ClusterXL Overview: Why Clustering, HA vs Load Sharing 6.2 High Availability Mode: Active/Standby, Primary Up vs Active Up 6.3 Load Sharing Modes: Multicast, Unicast (Pivot), and Traffic Distribution 6.4 Cluster Control Protocol (CCP) and State Synchronization 6.5 Failover, Cluster States, and Troubleshooting with cphaprob

7 Chapter 7: VPN, Logs, and Troubleshooting

7.1 Site-to-Site IPsec VPN 7.2 Remote Access VPN 7.3 Encryption Domains and VPN Communities 7.4 Mobile Access Blade 7.5 Logs, Monitor, and SmartEvent 7.6 Backups, Snapshots, and Migrate Export 7.7 fw monitor, fw ctl zdebug, and cpview 7.8 cpinfo and Common Issues

7.6 Backups, Snapshots, and Migrate Export

Key Takeaways Explain This Topic AI

A Gaia snapshot is a full-system image used for bare-metal rollback; it cannot be scheduled.

Gaia system backup is the preferred method for regular recovery; it can be scheduled and is smaller than a snapshot.

migrate_server export / import replaces the legacy migrate export and upgrade_export on R82; the legacy migrate is for same-version migration only.

R82 changed export file extension from .tgz (gzip) to .txz (XZ compression).

Last updated: July 2026

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

  • Scenario Tool
  • Bare-metal rollback point before a major change Gaia snapshot
  • Regular nightly config backup Gaia backup (scheduled)
  • Move management DB to new hardware, same version migrate_server export (auto-invokes legacy migrate )
  • Upgrade Management Server to R82 migrate_server export on source, migrate_server import on new R82 box
  • Multi-Domain Server backup mds_backup
  • VSX sk100395 (special workflow)
  • Pre-Upgrade Backup Sequence (R82 official)

Save a snapshot of the source system.

Save a backup of the source system.

Collect a CPinfo file.

Run the Pre-Upgrade Verifier (PUV); if it succeeds, take a second snapshot, second backup, second CPinfo .

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.