<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Unreliable Snapshots in Firewall and Security Management</title>
    <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Unreliable-Snapshots/m-p/274991#M104751</link>
    <description>&lt;P&gt;I imagine if the shapshot is bigger than your snapshot partition, that could cause an issue.&lt;BR /&gt;Hopefully, we can get to the bottom of it.&lt;/P&gt;</description>
    <pubDate>Tue, 07 Apr 2026 14:07:05 GMT</pubDate>
    <dc:creator>PhoneBoy</dc:creator>
    <dc:date>2026-04-07T14:07:05Z</dc:date>
    <item>
      <title>Unreliable Snapshots</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Unreliable-Snapshots/m-p/274947#M104740</link>
      <description>&lt;P&gt;I've recently had three separate systems blow up when I tried to revert to snapshots. It looks like something is causing the systems to create an extremely large file in /tmp named&amp;nbsp;snap_log_backup.tgz. This file fills up all the storage in the snapshot, so a snapshot which would ordinarily be 14 GB is 32 GB (the size of lv_current) instead. All three were R82 at the time of snapshot; two were jumbo 44, one (a management server) was jumbo 60.&lt;/P&gt;
&lt;P&gt;Reverting to such a snapshot results in a non-bootable system. It hangs during init, and you need the ability to power-cycle it to get back to the boot menu to get into maintenance mode. And of course this happened to two systems built by somebody unfamiliar with LOMs in a facility which isn't typically staffed, so I had to send someone to go physically there and hit a button.&lt;/P&gt;
&lt;P&gt;Check your snapshot sizes with 'lvs' and get the "Size" and "Used" values for lv_current from 'df -h'. A healthy snapshot should be about as big as lv_current's Used. A snapshot with this problem will be about the size of lv_current's Size.&lt;/P&gt;
&lt;P&gt;You &lt;U&gt;&lt;EM&gt;&lt;STRONG&gt;might&lt;/STRONG&gt;&lt;/EM&gt;&lt;/U&gt; be able to fix the snapshot by &lt;A href="https://community.checkpoint.com/t5/General-Topics/Mounting-snapshots/m-p/146129" target="_self"&gt;mounting it&lt;/A&gt; without the '-o ro' and removing the /tmp/snap_log_backup.tgz from inside it. On the third system, this got the snapshot to restore at least well enough to boot. I haven't tested the restored system exhaustively.&lt;/P&gt;
&lt;P&gt;I don't yet know anything about what causes the problem in the first place. Support apparently couldn't reproduce it, but it has bit me every single time I've needed to restore to a snapshot in the last few months.&lt;/P&gt;</description>
      <pubDate>Tue, 07 Apr 2026 00:59:11 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Unreliable-Snapshots/m-p/274947#M104740</guid>
      <dc:creator>Bob_Zimmerman</dc:creator>
      <dc:date>2026-04-07T00:59:11Z</dc:date>
    </item>
    <item>
      <title>Re: Unreliable Snapshots</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Unreliable-Snapshots/m-p/274991#M104751</link>
      <description>&lt;P&gt;I imagine if the shapshot is bigger than your snapshot partition, that could cause an issue.&lt;BR /&gt;Hopefully, we can get to the bottom of it.&lt;/P&gt;</description>
      <pubDate>Tue, 07 Apr 2026 14:07:05 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Unreliable-Snapshots/m-p/274991#M104751</guid>
      <dc:creator>PhoneBoy</dc:creator>
      <dc:date>2026-04-07T14:07:05Z</dc:date>
    </item>
  </channel>
</rss>

