Probably due to how rotation is setup. There are two factors here, time and file size. The logs rotate and remove old log files every X days (7 i think is default) but it will create .0, .1 files if the log file size reaches Y size.
For this file to grow to 2GB in less than a week means you have a lot of traffic hitting the system and you should probably check your firewall configs or at least look to see what is filling up the log file so quickly.
I’m not sure about this case, but, as a general principle, you should not rely on removing a file for an active log file. If the file is kept open, the underlying disk space will not be released until it is eventually closed, but no-one will be able to open the file to make use of its contents. Whether this is a factor depends on whether the file is kept open between messages, or opened and closed around each message.
The file in question (fail2ban.0) was last modified the first day I booted the new system on 8-3-22. No other .1, .2, .3s exist and logrotate.d is working on the fail2ban. You can see -20230502, back to 20230426 is active and modified on the corresponding dates and dates and older are purged.
Asterisk services are not exposed to the internet and the PBX is behind a sonicwall firewall which is also monitoring traffic.
Traffic is monitored and suspicious activity is relatively low. I monitor all fail2ban activity daily/weekly and get very low amounts of attempts if any.