> Source: [sk1000106](https://support.checkpoint.com/results/sk/sk1000106) # sk1000106 - Logging does not work after reverting to the previous Gaia Snapshot on a physical Check Point appliance | Property | Value | |----------|-------| | Solution ID | sk1000106 | | Date Created | 2026-09-03 | | Last Modified | 2026-09-11 | | Technical Level | General | | Products | Logging & Status | | Versions | R82.20 | | OS | Gaia | ## Symptoms - After reverting to the previous Gaia Snapshot on a physical Check Point appliance: * **On a Security Management Server / Domain Management Server / Domain Log Server / Dedicated Log Server:** * New traffic log entries and audit log entries do not appear in the SmartConsole **Logs** view, and log queries may return no results or fail. * Logging does not recover over time - no new log files are created, and no log switch occurs. * The "`cpwd_admin list`" command shows that the logging process (`fwd`) and the log indexing process (`log_indexer`) restart repeatedly. * **On a Security Gateway:** * The Security Gateway does not save traffic logs locally and does not forward logs to its Management Server / Log Server. ## Cause The internal log file format was changed in these versions: * Check Point R82.20 * R82.10 Jumbo Hotfix Accumulator Take 36 * R82 Jumbo Hotfix Accumulator Take 118 In these versions, the active log files (`$FWDIR/log/fw.*` files) are written in the new format. When you restore a Gaia Snapshot (on a physical server or in a virtual machine), it restores the disk partitions except the **log** partition. As a result, after reverting to a previous version, the active log files on the disk are still in the new format, which the reverted earlier version cannot read. The logging processes fail when they try to open these files. **Scenario 1 - the R82.20 version:** 1. The server was running one of these versions: * R82.10 Jumbo Hotfix Accumulator Take 24 or lower, of just the R82.10 version * R82 Jumbo Hotfix Accumulator Take 107 or lower, of just the R82 version 2. You created a Gaia Snapshot 3. You upgraded to the R82.20 version 4. You restored this Gaia Snapshot **Scenario 2 - the R82.10 version:** 1. The server was running the R82.10 Jumbo Hotfix Accumulator Take 24 or lower, of just the R82.10 version 2. You created a Gaia Snapshot 3. You installed the R82.10 Jumbo Hotfix Accumulator Take 36 or higher 4. You restored this Gaia Snapshot **Scenario 3 - the R82 version:** 1. The server was running the R82 Jumbo Hotfix Accumulator Take 107 or lower, of just the R82 version 2. You created a Gaia Snapshot 3. You installed the R82 Jumbo Hotfix Accumulator Take 118 or higher 4. You restored this Gaia Snapshot ## Solution **Important** - Schedule a maintenance window because this procedure stops all Check Point services on a server. ### Procedure for a Security Management Server / Log Server / Security Gateway > On Security Gateways, this procedure is required only when restoring a Gaia Snapshot: > > * from R82.10 Jumbo Hotfix Accumulator Take 36 to an earlier Take > * from R82 Jumbo Hotfix Accumulator Take 118 to an earlier Take > > Show / Hide this section > **Action plan in ClusterXL High Availability / Load Sharing Unicast mode:** > > 1. Perform this procedure on one Standby / Non-Pivot cluster member at a time - on all Standby / Non-Pivot cluster members. > > 2. Perform a manual cluster failover on the Active / Pivot cluster member. > > 3. Perform this procedure on the former Active / Pivot cluster member. > > **Action plan in ClusterXL Load Sharing Multicast mode:** > > Perform this procedure on one Active cluster member at a time. > > **Procedure:** > > 1. Connect to the command line on the server. > > 2. If the default shell is Gaia Clish, then log in to the Expert mode: > > |----------| > | `expert` | > > 3. Stop the Check Point services: > > |----------| > | `cpstop` | > > 4. Go to the **$FWDIR/log/** directory: > > |-----------------| > | `cd $FWDIR/log` | > > 5. Examine the current working directory to make sure: > > |-------| > | `pwd` | > > 6. Examine the list of log files before moving them: > > |-----------------------------------------------------------------| > | `echo *.{,adt,v}log{,ptr,initial_ptr,account_ptr} *.logLuuidDB` | > > 7. Create a backup directory: > > |--------------------------------| > | `mkdir -p /var/log/R8220_logs` | > > 8. Move the log files: > > **Notes:** > * It is necessary to move the active log files "`fw.*log*`" that were created after the upgrade. > > * If the active logs were rotated while running the newer version, then the earlier version cannot read them as well. Move these log files as well ("`.*log*`"). > > |-----------------------------------------------------------------------------------------| > | `mv -v fw.{,adt,v}log{,ptr,initial_ptr,account_ptr} fw.logLuuidDB /var/log/R8220_logs/` | > > 9. Restore the default globbing behavior: > > |---------------------| > | `shopt -u nullglob` | > > 10. Start the Check Point services: > > |-----------| > | `cpstart` | > > 11. Wait for all the required processes to come up. > > Wait until this command shows that the "`STAT`" column shows "`E`" for all processes: > > |-------------------| > | `cpwd_admin list` | > > 12. Make sure the new `$FWDIR/log/fw.log` file was created: > > |---------------------------| > | `ls -l $FWDIR/log/fw.log` | > > 13. Connect with SmartConsole to the Security Management Server / relevant Domain Management Server. > > 14. On the left navigation panel, click **Logs**. ### Procedure for a Multi-Domain Security Management Server / Multi-Domain Log Server > Show / Hide this section > 1. Connect to the command line on the server. > > 2. If the default shell is Gaia Clish, then log in to the Expert mode: > > |----------| > | `expert` | > > 3. Stop the Check Point services: > > |-----------| > | `mdsstop` | > > 4. Prevent the shell from treating unmatched wildcard patterns as literal filenames: > > |---------------------| > | `shopt -s nullglob` | > > 5. Move the current active and rotated log files to a backup directory: > > 1. For the main context "MDS": > > 1. Go to the main context "MDS": > > |----------| > | `mdsenv` | > > 2. Go to the **$MDSDIR/log** directory: > > |------------------| > | `cd $MDSDIR/log` | > > 3. Examine the current working directory to make sure: > > |-------| > | `pwd` | > > 4. Examine the list of log files before moving them: > > |-----------------------------------------------------------------| > | `echo *.{,adt,v}log{,ptr,initial_ptr,account_ptr} *.logLuuidDB` | > > 5. Create a backup directory: > > |------------------------------------| > | `mkdir -p /var/log/R8220_logs_MDS` | > > 6. Move the log files: > > **Notes:** > * It is necessary to move the active log files "`fw.*log*`" that were created after the upgrade. > > * If the active logs were rotated while running the newer version, then the earlier version cannot read them as well. Move these log files as well ("`.*log*`"). > > |---------------------------------------------------------------------------------------------| > | `mv -v fw.{,adt,v}log{,ptr,initial_ptr,account_ptr} fw.logLuuidDB /var/log/R8220_logs_MDS/` | > > 2. For **each** Domain Management Server / Domain Log Server: > > 1. Go to the context of the Domain Management Server / Domain Log Server: > > |-----------------------------------------------------------------------| > | `mdsenv ` | > > 2. Go to the **$FWDIR/log/** directory: > > |-----------------| > | `cd $FWDIR/log` | > > 3. Examine the current working directory to make sure: > > |-------| > | `pwd` | > > 4. Examine the list of log files before moving them: > > |-----------------------------------------------------------------| > | `echo *.{,adt,v}log{,ptr,initial_ptr,account_ptr} *.logLuuidDB` | > > 5. Create a backup directory: > > |------------------------------------------------------------| > | `mkdir -p /var/log/R8220_logs_Domain_` | > > 6. Move the log files: > > **Notes:** > * It is necessary to move the active log files "`fw.*log*`" that were created after the upgrade. > > * If the active logs were rotated while running the newer version, then the earlier version cannot read them as well. Move these log files as well ("`.*log*`"). > > |-----------------------------------------------------------------------------------------------------------------------| > | `mv -v fw.{,adt,v}log{,ptr,initial_ptr,account_ptr} fw.logLuuidDB /var/log/R8220_logs_Domain_``/` | > > 6. Restore the default globbing behavior: > > |---------------------| > | `shopt -u nullglob` | > > 7. Start the Check Point services: > > |------------| > | `mdsstart` | > > 8. Wait for all the required processes to come up: > > 1. Go to the main context "MDS": > > |----------| > | `mdsenv` | > > 2. Wait until this command shows that all processes are in the status "`up`" and show a PID: > > |-----------| > | `mdsstat` | > > 3. Go to the context of each relevant Management Server: > > |-----------------------------------------------------------------------| > | `mdsenv ` | > > 4. Wait until this command shows that the "`STAT`" column shows "`E`" for all processes: > > |-------------------| > | `cpwd_admin list` | > > 9. Make sure the new `$FWDIR/log/fw.log` file was created: > > 1. Go to the context of each relevant Management Server: > > |-----------------------------------------------------------------------| > | `mdsenv ` | > > 2. Examine the current working directory to make sure: > > |-------| > | `pwd` | > > 3. Examine the file: > > |---------------------------| > | `ls -l $FWDIR/log/fw.log` | > > 10. Connect with SmartConsole to the Security Management Server / relevant Domain Management Server. > > 11. On the left navigation panel, click **Logs**. ### Procedure for a Scalable Platform Security Group > On Scalable Platforms, this procedure is required only when restoring a Gaia Snapshot: > > * from R82.10 Jumbo Hotfix Accumulator Take 36 to an earlier Take > * from R82 Jumbo Hotfix Accumulator Take 118 to an earlier Take > > Show / Hide this section > **Action plan in a Security Group:** > > 1. Perform this procedure on one Security Group Member at a time - on all non-SMO Security Group Members. > > 2. Perform a manual cluster failover on the SMO Security Group Member. > > 3. Perform this procedure on the former SMO Security Group Member. > > **Procedure:** > > 1. Connect to the command line on the Security Group. > > 2. If the default shell is Gaia gClish, then log in to the Expert mode: > > |----------| > | `expert` | > > 3. Get the ID of the Security Group Member that runs the "SMO" task: > > |---------------------| > | `asg stat -i tasks` | > > 4. For **each** non-SMO Security Group Member: > > 1. Go to the context of the non-SMO Security Group Member: > > |---------------| > | `member ` | > > 2. Stop the Check Point services: > > |----------| > | `cpstop` | > > 3. Prevent the shell from treating unmatched wildcard patterns as literal filenames: > > |---------------------| > | `shopt -s nullglob` | > > 4. Move the current active and rotated log files to a backup directory: > > 1. Go to the **$FWDIR/log/** directory: > > |-----------------| > | `cd $FWDIR/log` | > > 2. Examine the current working directory to make sure: > > |-------| > | `pwd` | > > 3. Examine the list of log files before moving them: > > |-----------------------------------------------------------------| > | `echo *.{,adt,v}log{,ptr,initial_ptr,account_ptr} *.logLuuidDB` | > > 4. Create a backup directory: > > |--------------------------------------------| > | `mkdir -p /var/log/R8220_logs_` | > > 5. Move the log files: > > **Notes:** > * It is necessary to move the active log files "`fw.*log*`" that were created after the upgrade. > > * If the active logs were rotated while running the newer version, then the earlier version cannot read them as well. Move these log files as well ("`.*log*`"). > > |-------------------------------------------------------------------------------------------------------| > | `mv -v fw.{,adt,v}log{,ptr,initial_ptr,account_ptr} fw.logLuuidDB /var/log/R8220_logs_``/` | > > 5. Restore the default globbing behavior: > > |---------------------| > | `shopt -u nullglob` | > > 6. Start the Check Point services: > > |-----------| > | `cpstart` | > >
> > 7. Wait for all the required processes to come up. > > Wait until this command shows that the "`STAT`" column shows "`E`" for all processes: > > |-------------------| > | `cpwd_admin list` | > > 8. Make sure the new `$FWDIR/log/fw.log` file was created: > > |---------------------------| > | `ls -l $FWDIR/log/fw.log` | > > 5. Perform a manual cluster failover on the SMO Security Group Member: > > 1. Go to the context of the SMO Security Group Member: > > |---------------| > | `member ` | > > 2. Perform a manual cluster failover: > > |---------------------------------| > | `clusterXL_admin --b down` | > > 3. Examine the state of the Security Group Members: > > |---------------| > | `asg monitor` | > > 4. Get the ID of the Security Group Member that runs the "SMO" task now - another Security Group Member must run as "SMO": > > |---------------------| > | `asg stat -i tasks` | > > 5. Follow the entire Step 4 on this former-SMO Security Group Member. > > 6. Restore the cluster state on this former-SMO Security Group Member: > > |-------------------------------| > | `clusterXL_admin --b up` | > > 6. Examine the state of the Security Group Members - they all must be "`ACTIVE`": > > |---------------| > | `asg monitor` | > > 7. Connect with SmartConsole to the Security Management Server / relevant Domain Management Server. > > 8. On the left navigation panel, click **Logs**. > > Traffic logs from Security Group Members should appear. ### Notes * In the newer versions (see the "Cause" section), all the log files are in the new format. Earlier versions cannot read these log files. To read these log files, use a server that runs the newer version. * The moved active "`fw.log`" may be partially damaged at its end (the logging process may have written to it while failing). Verify the content of this log file in the newer version before relying on it. --- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content