my backups went from 17m to 850m in the last few days!? i did some search and found some issues with suricata cache (which may or may not have been addressed), so i excluded those, any other big changes in whats being backed up? also seems that i can just untar the file and check the contents - guess thats my next move.
thanks!
What IPFire version are you running?
IPFire 2.29 (x86_64) - Core-Update 203 - pretty sure i updated to latest just in last week or so, didn’t notice the backup size diff until later and do NOT think its update related (i have another firewall with same version that still has 16m backup - but its not running quite the same options)
I just did a backup of my CU203 system. With logfiles: 521MB. Without logfiles: 227MB.
I also have a CU202 system. With logfiles: 437MB. Without logfiles: 222MB. There doesn’t seem to be a big difference between CU202 and 203 at least on my systems.
The only suggestion I have is to double-check you don’t have logfiles included in the backup? Was the 17MB backup with or without logs?
both backups are without logs, its def odd. i’ll try to look out at tonight - extract it and look around
looks like it backed up ‘/var/log/suricata/reporter.db’ (and thats a 1g file) - if i exclude logs, shouldn’t all of /var/log get skipped!? i just ran another one to be certain, selected ‘include logs’, then re-selected exclude logs, and the result is the same - roughly 845m!? in the expanded backup, i only see rrd, suricata, and vnstat folders while in the /var/log on the system, i see many more - could it be there’s just some mis-spelled ‘exclusions’?
oh… that file is explicitly included in the /var/ipfire/backup/include file - is that on purpose? maybe this file is actually needed with suricata (even though its in the logs folder) - would be nice if there was a way to shrink/purge that!
Yes, because that is the database of the extracted details for all the IPS hits you have had.
However it’s data comes from the fast.log files and it should not really get to 1G size unless you have been having millions of hits on your IPS.
ls -hal /var/log/suricata/
total 80M
drwxr-xr-x 4 suricata suricata 4.0K Aug 2 00:01 .
drwxr-xr-x 19 root root 12K Aug 2 00:01 ..
drwxr-xr-x 2 root root 4.0K May 21 20:55 certs
-rw-r--r-- 1 suricata suricata 74K Aug 4 10:19 fast.log
-rw-r--r-- 1 suricata suricata 21K Aug 1 23:45 fast.log.1.gz
-rw-r--r-- 1 suricata suricata 22K Jul 25 23:43 fast.log.2.gz
-rw-r--r-- 1 suricata suricata 20K Jul 18 23:53 fast.log.3.gz
-rw-r--r-- 1 suricata suricata 23K Jul 11 23:59 fast.log.4.gz
-rw-r--r-- 1 suricata suricata 21K Jul 4 23:56 fast.log.5.gz
drwxr-xr-x 2 root root 4.0K May 21 20:55 files
-rw-r--r-- 1 root root 76M Aug 2 10:09 reporter.db
-rw-r--r-- 1 root root 32K Aug 4 10:19 reporter.db-shm
-rw-r--r-- 1 root root 4.0M Aug 4 10:19 reporter.db-wal
The reporter.db file on my system is at 75MB and that is covering data all the way back to October 2025, so 9 months worth.
What size are the fast.log files in that directory on your system.
If your fast.log files are relatively small, then either, historically, you had a short period with thousands or millions of IPS hits or some corruption or some file error occurred.
You can check if you had a high level of IPS throughput at some stage by looking at the Throughput graph on the IPS WUI page and choosing monthly and or yearly to see if you have had a period with very high IPS hit traffic.
Shrink? It holds all your IPS alarms. It should also compress well in the backup.
great info!! i will go check those fast logs and report back. far as the shrink/purge - didn’t realize what exactly it held so knowing that, i might like to purge for a certain age, right? like if i had HEAVY activity a year ago, i may want to purge that out (ie, if i deem it something that was a one time occurance)