Hello,
My FreePBX15 system has been working like a champ for few years now. However my backups are gettting bigger and bigger. I found today that the /var/lib/mysql has grown to 68GB. Is there a way to flush some of the old SQL data and free up the disk space.
Thanks.
I have not tested this guide on FreePBX 15, nor do I intend to.
68GB is significantly larger than any system I have tested against.
I would first confirm what is consuming the space before assuming the majority of it is CDR/CEL data.
du -sh /var/lib/mysql/*
16K /var/lib/mysql/aria_log.00000001
4.0K /var/lib/mysql/aria_log_control
5.4M /var/lib/mysql/asterisk
201M /var/lib/mysql/asteriskcdrdb
3.4G /var/lib/mysql/ibdata1
5.0M /var/lib/mysql/ib_logfile0
5.0M /var/lib/mysql/ib_logfile1
1004K /var/lib/mysql/mysql
0 /var/lib/mysql/mysql.sock
212K /var/lib/mysql/performance_schema
0 /var/lib/mysql/test
du -sh /var/lib/mysql/asteriskcdrdb/*
20K /var/lib/mysql/asteriskcdrdb/cdr.frm
4.0K /var/lib/mysql/asteriskcdrdb/cdr.TRG
4.0K /var/lib/mysql/asteriskcdrdb/cdrTrigger.TRN
20K /var/lib/mysql/asteriskcdrdb/cel.frm
4.0K /var/lib/mysql/asteriskcdrdb/db.opt
12K /var/lib/mysql/asteriskcdrdb/queuelog.frm
20K /var/lib/mysql/asteriskcdrdb/transient_cdr.frm
137M /var/lib/mysql/asteriskcdrdb/transient_cdr.MYD
64M /var/lib/mysql/asteriskcdrdb/transient_cdr.MYI
If the majority of that space is CDR/CEL data, I recommend pruning much smaller date ranges than the before 1 July 2023 example used in the guide below.
For example, I have just tested it again on v16 with the following data set:
±--------------+
| cdr_to_delete |
±--------------+
| 470194 |
±--------------+
±--------------+
| cel_to_delete |
±--------------+
| 3522574 |
±--------------+
Ensure you have a recent backup or VM snapshot before making any changes. This sort of pruning is not routine maintenance. If possible, test the procedure on a dev system first. Also make sure you have plenty of free disk space available before starting. The backup and restore test requires additional temporary database storage. One of my test runs crashed because there wasn’t enough free space, and recovering it wasn’t straightforward. If the filesystem runs out of space, the restore will fail part-way through and require manual recovery.
Before pruning the database, it’s worth checking whether other large items (such as call recordings or old log files) can be removed instead. If the database itself is not the primary consumer of disk space, pruning CDR/CEL records may not significantly reduce disk usage.
I have free spaxce to work with. I am at 57% total space used, so I have some space to work with. but I wanna clear up soem space before it becomes too big. I will try your tips. Thx
Btw, I reached out to Sangoma support to clear some space for me even tho I offered to pay for it and they flat out denied it because 'freepbx15 does not receive any support anymore". They instructed me to uprade (clean install 17) then run backup restore from 15 to 17. If moving 300 users with all the commercial modules and sangoma mobile deployements was easy, I would have done it already.
That is not a reason to avoid upgrading.
FreePBX 15 is EOL and no longer receives security updates, so running it indefinitely carries increasing risk. Fair play to Sangoma for pushing back. Not everyone would refuse the work rather than simply taking your money with a “make sure you’ve backed up and we’ll give it a go” caveat.
Moving 300 users is not a simple exercise, and nobody sensible would suggest that it is. However, there are plenty of reasons to get your system onto version 16 as an intermediate step and start planning a migration path.
It sounds like you’re carrying a lot of responsibility, so I’d encourage you to tackle this before a non-critical pruning task. I’d also be wary of anyone who too easily accepts payment for an unsupported version.
Trust me I want latest and secure PBX, but Sangoma since taking over has not presented an easy migration tool. They want us to move to a newer version - make it easy for us.
When I first installed the “stable freepbx 17” even networking was broken… Now they say there are no bugs on the 17.. really? they why I am getting locked out of the gui every day…
I can assure you there are no concerns with v17. It’s both mature and stable, considerably more so than v15.
FreePBX-17 requires Debian-12 so there is no “easy” upgrade when you are moving from CentOS. It requires a fresh OS to do it. Best advice is to spin up a new VM, hardware, whatever, and restore the V15 FreePBX backup. It will do a lot of the heavy lifting including migrating from chan_sip to chan_pjsip. Commercial modules often require intervention from Sangoma to insure they are up and running correctly on the new system. Then test the devil out of it before point the users at the new system. Trunks may require modifications for pjsip. Any custom programming in your extensions_custom.conf file can no longer use macros. There are a lot of changes.
Sangoma is working on FreePBX-18 on Debian-13 and Asterisk is on version 23 so if you wait much longer, you will be left in the dust. I wouldn’t delay any longer. It takes a lot of time and effort to test before cutover to the upgraded system.