How to keep recordings from filling your disk

A busy VICIdial dialer can produce 100 GB or more of Call recording files in a single month. WAV (PCM) files at roughly 1 MB per minute are the main culprit. Left unmanaged, the /var/spool/asterisk/ partition fills up and Asterisk silently stops recording new calls — with no error surfaced to agents or supervisors. The fix is a three-layer strategy: compress the format, enforce retention limits, and offload to cheaper storage. For the full recording overview, see VICIdial call recording explained.

Layer 1 — Switch to a smaller recording format

The Recording format (WAV/MP3) setting in Admin > Servers > Edit Server controls the on-disk format. The choices and their rough sizes per minute of audio are:

• WAV (PCM) — roughly 1 MB per minute. Highest quality, largest files. Use when downstream tools like voice analytics require uncompressed audio.
• GSM — roughly 125 KB per minute. About 8x smaller than WAV. Adequate for manual compliance review and QA listening.
• MP3 — roughly 60 KB per minute. Requires a post-call conversion step using sox or lame. Smallest on disk, but adds slight CPU overhead after each call.

Switching from WAV to GSM typically cuts your recording storage by 85 to 90 percent with no hardware change. For a full comparison of the trade-offs, see how to record in GSM vs WAV.

Layer 2 — Automated retention and deletion

The Recording retention setting (measured in days) tells VICIdial's cleanup scripts how long to keep recordings on the local disk. Set it under Admin > System Settings. Once a recording exceeds that age, the nightly cleanup cron job removes the file and, optionally, the corresponding database row in recording_log.

**Heads up:** Deleting the file without deleting the database row leaves a dead link in the Recordings report. Users who click the play button get a 404. Either configure your cleanup script to handle both, or accept that stale rows will appear in search results until you prune them manually.

A manual find-based cleanup for files older than 90 days looks like this — run it with -print first to review the list before committing to -delete:

find /var/spool/asterisk/monitorDONE/ -name '*.wav' -mtime +90 -delete

Wrap this in a cron job scheduled for off-peak hours, such as 3 AM nightly.

Layer 3 — Offload before you delete

Most compliance requirements say keep recordings for X years — not keep them on the dialer itself. Offload old files to a NAS, an S3-compatible bucket via rclone, or a dedicated archive server, then remove the local copy. A nightly rsync job paired with a cleanup script handles this cleanly without manual intervention. See how to offload old recordings off the dialer for the full setup walkthrough.

flowchart TD
    A[Call ends, file written to monitorDONE] --> B[Nightly cron job runs]
    B --> C[rsync files to NAS or S3 archive]
    C --> D{Transfer successful?}
    D -- Yes --> E[find deletes local copies older than retention limit]
    D -- No --> F[Alert fired, no local files deleted]
    E --> G[Disk usage stays flat]
    G --> A

Disk space planning numbers

Use these rough figures to estimate your monthly storage need before you hit a problem:

• 10 agents, 6 hours per day, 5-minute average talk time, WAV format: roughly 18 GB per month.
• Same scenario recorded in GSM: roughly 2.25 GB per month — a factor of 8 reduction.
• 100 agents at the same rate in WAV: roughly 180 GB per month. Provision 2 to 3x headroom on the partition to avoid surprises during peak dialing periods.

Disk monitoring

Add a cron job that fires an alert when the partition exceeds 80 percent full. A simple check:

df -h /var/spool/asterisk | awk 'NR==2 {print $5}'

Compare the output to a threshold in your script and email or Slack an alert if it is over 80. Do not wait for the disk to fill — Asterisk gives no warning when it stops recording due to a full partition.

If you want disk alerts and archival handled automatically without writing cron jobs, check our managed hosting plans — disk monitoring and nightly offloading are included.