How I fixed my FreepBX Backup

My FreePBX backup system decided to stop working last week, and of course I only noticed when I actually needed to restore something. Classic scenario, right? Here's how I tracked down and fixed the issue.

The Problem

The backup module was throwing cryptic errors in the logs, and manual backups were failing silently. When I checked the backup directory, I found a bunch of incomplete files and nothing recent that looked usable. Not exactly confidence-inspiring.

First step was checking the obvious stuff - disk space, permissions, and the backup configuration. Everything looked normal on the surface, but digging into the FreePBX logs revealed the real culprit: database connection timeouts during the backup process.

Tracking Down the Root Cause

The backup process was timing out when trying to dump the Asterisk database. This was happening because my system had grown over the years - more extensions, call logs, voicemails, and CDR records than when I originally set it up.

I confirmed this by running a manual mysqldump to see how long it actually took:

mysqldump -u root -p asterisk > /tmp/test_backup.sql

Sure enough, it was taking about 12 minutes to complete, but the FreePBX backup module was configured with much shorter timeouts.

The Fix

The solution involved adjusting a few MySQL and FreePBX settings. First, I increased the MySQL timeout values in /etc/mysql/my.cnf:

[mysqld]
max_execution_time = 1800
wait_timeout = 1800
interactive_timeout = 1800

Then I restarted MySQL:

systemctl restart mysql

Next, I needed to modify the FreePBX backup module settings. This is where it gets a bit tricky because you can't just edit a config file. I had to go into the FreePBX admin interface and increase the backup timeout under Admin > Backup & Restore > Advanced Settings.

I set the backup timeout to 30 minutes (1800 seconds) to give plenty of buffer room.

Additional Cleanup

While I was at it, I also cleaned up some old CDR records that were bloating the database unnecessarily. FreePBX keeps everything by default, but I don't need call records from 3 years ago.

mysql -u root -p asterisk -e "DELETE FROM cdr WHERE calldate < DATE_SUB(NOW(), INTERVAL 1 YEAR);"

This freed up about 2GB of space and will make future backups faster.

Testing and Monitoring

After making these changes, I ran a manual backup to verify everything worked. It completed successfully in about 8 minutes - much better than the previous timeouts.

I also set up a simple cron job to check that backups are completing properly:

#!/bin/bash
# Check if backup completed in last 24 hours
find /var/spool/asterisk/backup -name "*.tgz" -mtime -1 | wc -l

If that returns 0, I get an alert that backups aren't running.

Lessons Learned

The main takeaway here is that FreePBX systems need maintenance as they grow. Default timeout settings that worked fine for a small deployment can become problematic as your database grows. Regular monitoring of your backup system is crucial - don't wait until you need a restore to discover it's broken.

Also, periodic database cleanup isn't just about disk space - it directly impacts backup performance and reliability.