- Products
- Learn
- Local User Groups
- Partners
- More
The Great Exposure Reset
24 February 2026 @ 5pm CET / 11am EST
CheckMates Fest 2026
Watch Now!AI Security Masters
Hacking with AI: The Dark Side of Innovation
CheckMates Go:
CheckMates Fest
Good afternoon all,
I've received an alert today about space usage on our management server.
I've recently inherited responsibility for this system which is currently on R81.20 and overdue an upgrade to the latest JHF. There is also the option to upgrade to R82. Both gateways are also on R81.20.
I ran a check on the top 25 directories using space. You'll see older directories - I believe these are created during in-place upgrades.
My questions on below - Can the CPsuite-R8x.xx folders prior to CPsuite-R81.20 be completely deleted without issue?
Upgrading: If I upgrade to the latest JHF, can it be done as a clean install like I see available for R82?
(I am assuming clean install will automatically delete all the older directories - please correct me if I'm wrong).
Thank you in advance for any/all help!
Output from CLI:
[Expert@fw-mgmt:0]# du -hax /var/log 2> /dev/null | sort -r -h | head -n 25
642G /var/log
619G /var/log/opt
169G /var/log/opt/CPsuite-R81.10/fw1/log
169G /var/log/opt/CPsuite-R81.10/fw1
169G /var/log/opt/CPsuite-R81.10
153G /var/log/opt/CPrt-R81.10
151G /var/log/opt/CPrt-R81.10/log_indexes
114G /var/log/opt/CPsuite-R81.20/fw1/log
114G /var/log/opt/CPsuite-R81.20/fw1
114G /var/log/opt/CPsuite-R81.20
96G /var/log/opt/CPrt-R81.20
94G /var/log/opt/CPrt-R81.20/log_indexes
87G /var/log/opt/CPsuite-R80.40/fw1
87G /var/log/opt/CPsuite-R80.40
86G /var/log/opt/CPsuite-R80.40/fw1/log
18G /var/log/CPda
17G /var/log/CPda/repository
9.7G /var/log/CPda/repository/CheckPoint#Major#All#6.0#5#4#BLINK_R81_20_T631_JHF_T65_MGMT/Blink_image_1.1_Check_Point_R81.20_T631_JHF_T65_SecurityManagement.tgz
9.7G /var/log/CPda/repository/CheckPoint#Major#All#6.0#5#4#BLINK_R81_20_T631_JHF_T65_MGMT
2.4G /var/log/CPda/repository/CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#65/Check_Point_R81_20_JUMBO_HF_MAIN_Bundle_T65_FULL.tgz
2.4G /var/log/CPda/repository/CheckPoint#CPUpdates#All#6.0#5#4#BUNDLE_R81_20_JUMBO_HF_MAIN#65
2.0G /var/log/CPda/repository/CheckPoint#CPUpdates#All#6.0#5#3#BUNDLE_R81_10_JUMBO_HF_MAIN#110/Check_Point_R81_10_JUMBO_HF_MAIN_Bundle_T110_FULL.tgz
2.0G /var/log/CPda/repository/CheckPoint#CPUpdates#All#6.0#5#3#BUNDLE_R81_10_JUMBO_HF_MAIN#110
2.0G /var/log/AutoUpdater
1.6G /var/log/AutoUpdater/repository
Hi,
This system had a lot of upgrades. Why not starting from scratch again with a clean R82 install.
With major upgardes (R81.x -> R82) we always perform a clean install of the management and sometime the gateways too.
If the management is VMWare, just create a new R82 SmartCenter and use the Check Point tools to export and import the database. Little risk and you start with a clean disk.
If the managament is an appliance you can do the same, but make sure you have created a good backup / export before re-imaging the appliance. Somewhat more risk, but you clean-up the disk for future installs.
It is my experience, stability increases when you perform a re-image / clean-install from time to time. A major upgrade to R82 is a good moment to do.
Regards,
Martijn
I would confirm the contents of these directories before deleting, but that seems reasonable.
I had done it in the lab before and was fine, no issues, but, to be safe, PLEASE do backup and snapshot as well.
The traffic log files in the older blah/log folders should be symlink'd in the current log folder, and they should be cleaned up automatically by the disk management mechanism. I have seen that fail though. It's pretty obvious when it does - your traffic logs in the current version folder will go back to a date a few months or so ago, then you'll have traffic logs from years ago in the older folders. In that case, it's definitely safe to just remove them. Other, non-traffic log files will be in there too, they are also safe to remove if you have no cause to reference them.
The R81.10 log_indexes folder is maybe a little different, it'll be the indexes of the traffic logs from that version - also should be handled by the log cleanup mechanism configured in the log settings in SmartConsole for the server they are stored on. Not sure if just deleting those is sensible but it probably shouldn't hurt.
Basically, for traffic logs, use the disk cleanup mechanism first, manually clean up stuff if you need to after. For other logs, you can just remove old ones if you need to. Otherwise just leave the server be and it should sustain itself at whatever thresholds are configured for cleanup.
If the management server is a VM, I always prefer building a new system and using migrate export/import as the upgrade strategy. This approach automatically gets rid of a lot of legacy files and clutter, and in my experience, it is the cleanest upgrade method when working with virtual machines.
That is the best way. 👌
The Release Notes state that only one upgrade is supported on VMs.
@cprio_ If it is a VM then you should be aware of that, and a new build (and import) is required for you upgrade
Hi,
This system had a lot of upgrades. Why not starting from scratch again with a clean R82 install.
With major upgardes (R81.x -> R82) we always perform a clean install of the management and sometime the gateways too.
If the management is VMWare, just create a new R82 SmartCenter and use the Check Point tools to export and import the database. Little risk and you start with a clean disk.
If the managament is an appliance you can do the same, but make sure you have created a good backup / export before re-imaging the appliance. Somewhat more risk, but you clean-up the disk for future installs.
It is my experience, stability increases when you perform a re-image / clean-install from time to time. A major upgrade to R82 is a good moment to do.
Regards,
Martijn
Thanks to each of you for your solid advice, it's really apreciated.
I've decided to trim log files for older versions for now and to review the log/disk management mentioned by @emmap, then to follow up on a new build VM per @Vincent_Bacher , @Don_Paterson , @Martijn.
No doubt I'll be back with more questions later, thanks again!
Totally vald points @Martijn
Looks to me that most of the storage is logging and packages.
I suggest configuring log retention policy - keep X days of logs and indexes. The mechanism should delete the oldest by itself.
You can see more info here: https://community.checkpoint.com/t5/Management/High-disk-consumption-of-dev-mapper-vg-splat-lv-log/m...
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 53 | |
| 39 | |
| 15 | |
| 12 | |
| 12 | |
| 11 | |
| 10 | |
| 10 | |
| 9 | |
| 8 |
Thu 19 Feb 2026 @ 03:00 PM (EST)
Americas Deep Dive: Check Point Management API Best PracticesTue 24 Feb 2026 @ 11:00 AM (EST)
Under The Hood: CloudGuard Network Security for Azure Virtual WANThu 19 Feb 2026 @ 03:00 PM (EST)
Americas Deep Dive: Check Point Management API Best PracticesTue 24 Feb 2026 @ 11:00 AM (EST)
Under The Hood: CloudGuard Network Security for Azure Virtual WANAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY