Management server backups are 71GB

[Parabol]

Hi all, I am having some issues sending backups of the management server to our dedicated backup server. I noticed I was getting the error "Failed to transfer the package to the remote server." I tried with both SCP and FTP with the same error. Our standby management server transfers it fine, so the config should be OK.

I am fairly certain it's due to the backup size, probably its timing out. I performed a local backup and it is 71GB:

-rw-r--r-- 1 admin root 71G Mar 9 10:42 backup_--_mgmtserver_2026_03_09_09_52_11.tgz

Is this size usual? I am wondering if there is some issue that is bloating it for me.

For reference the disk space:

[Expert@mgmtserver:0]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_splat-lv_current 80G 51G 30G 64% /
/dev/sda1 282M 47M 221M 18% /boot
tmpfs 32G 35M 32G 1% /dev/shm
/dev/mapper/vg_splat-lv_log 1.9T 1.4T 486G 75% /var/log
cgroup 32G 4.0K 32G 1% /sys/fs/cgroup

Thanks

[emmap]

It's quite large - first thing I usually recommend to check is that you don't have large files in the /home/ folders, as they are included in backups.

What version are you on?

[Parabol]

Thanks I will check this, we are running R82 Take 36

[CaseyB · Accepted solution]

You are on a version with a bug that causes large backups. Please upgrade to R82 JHF-41 or above.

 https://sc1.checkpoint.com/documents/Jumbo_HFA/R82/R82.00/Critical-Information.htm 

[Bob_Zimmerman]

Also note that backups are always going to be large. I personally wouldn't use Check Point's backup tool for anything. Instead, I use 'migrate export' for normal managements and mds_backup for MDSs. In an environment with around 100k rules and about 80k objects, the mds_backup is around 4.8 GB.

[Lesley]

have you checked this post? pretty sure this can cause the issue

[Parabol]

Just to say this fixed the issue, backups are now 2GB in size down from 71GB!

Thank you

[George_Ellis]

Check your revisions, under multi-domain, sessions (submenu).  In each CMA, check Manage & Settings, Sessions, Revisions.  In the past for us, it is copies of revisions that use a lot of space.
Also verify that you are not backing up logs unless you intend to. 

Edit - PS (not assuming you don't know it, but for general reference)
cd /var/log
du -h --max-depth=1 | sort -h

cd /home

du -h --max-depth=1 | sort -h

[Parabol]

Thanks we have about 6-weeks worth of revisions showing here, probably about 140 revisions. Would this take up a large amount of storage?

I can see that log indexes take up the vast majority (1TB) - presumably the backups must include this?

[Expert@mgmtserver]#cd /var/log/opt
[Expert@mgmtserver]#du -h --max-depth=1 | sort -h
4.0K ./CPviewExporter
24K ./CPotlpAgent
188M ./CPSmartLog-R82
192M ./CPSmartLog-R81.20
1.2G ./CPshrd-R82
11G ./CPshrd-R81.20
309G ./CPsuite-R82
1017G ./CPrt-R82
1.4T .

[Expert@mgmtserver]#cd ./CPrt-R82
[Expert@mgmtserver]#du -h --max-depth=1 | sort -h
0 ./distrib
0 ./events_db
20M ./Database
105M ./conf
183M ./log_indexer
1.1G ./log
1016G ./log_indexes
1017G .

[the_rock]

That many revisions, I would say take up lots of space, for sure.

[George_Ellis]

Remove the revisions to something you trust, maybe only 2 weeks?  Don't know your environment, so that is just a guess.  
Don't know your environment or configuration.  If you are logging to the mdm only, 1TB sounds light (our environment generates 150GB+ a day across 2 MLMs).  Check your $FWDIR/logs .

[George_Ellis]

While this is not likely in your backups, you can get 11GB back.

11G ./CPshrd-R81.20

[the_rock]

Good point, George. I would definitely consider that.