User Rating: 3 / 5

Star Active Star Active Star Active Star InactiveStar Inactive

When you run a successful PBX with FusionPBX, one of your problems is to keep it on diet. Depending on your server sizing, this issue may come soon or later, but it will arrive. I am talking about disk space.

There are two points to cover:

  1. Database
  2. Recordings


Database grow speed will be directly proportional to the number of calls you have. This is because each time you call, the FusionPBX project will add a record in the v_xml_cdr table. And of course, this will use disk space. So, what I have done is to write the following script (but it on a well-known path, like /usr/loca/bin/):

/usr/bin/mysql -u root fusionpbx -e "DELETE FROM v_xml_cdr WHERE DATE(start_stamp) <= DATE(SUBDATE(NOW(),365))";

This will delete any 365-day older record. Keep in mind that this SQL query is for MySQL or MariaDB, if you are using PostgreSQL you will need to change it a little, but the idea is the same. Later you can put a crontab that executes every night. Don't forget that eventually, you will need to vacuum your database to void the fragmentation. Each database has its own method, in MySQL or MariaDB it is done by executing the command

mysqlcheck -o --all-databases


FusionPBX allows us to record calls as a rule or per demand. This will create a sound file inside the recording directory (for example /var/lib/freeswitch/recordings/, the path depends on your installation, this is just the default path I use on my RPM's of FusionPBX). I have created this script:

/usr/bin/find /var/lib/freeswitch/recordings -path '*archive*' -type f -mtime +90 -exec /usr/bin/rm {} \;

It will delete all recordings inside the archive directory (where the call recordings are) older than 90 days. After that, you will need to put a crontab and you are done.

Change my scripts to fit your needs. Always use absolute paths inside your scripts, I have used Centos 7 default paths and it can be different depending on your Linux distribution.


blog comments powered by Disqus