FreePBX backup scheduling

Build the restore inventory before the schedule

FreePBX 15 and later Backup and Restore jobs select module data and may add custom directories. The current Sangoma guide says call recordings are not included by default; add __ASTSPOOLDIR__/monitor only when recordings belong in this recovery job. A new job may also show ASTETCDIR for custom configuration files, which should be reviewed rather than accepted or removed without an inventory.

List configuration, voicemail, recordings, certificates, prompts, custom files and any data protected elsewhere. Assign each item a recovery-point and recovery-time objective. A selected module, completed job or success notification is not proof that every required dependency entered the archive.

Treat Filestore and destination independence separately

FreePBX 15 and later moves storage configuration into the Filestore module. Sangoma documents email, FTP, local, Dropbox, SSH and S3 location types, and a backup job can select multiple locations. Multiple rows are not automatically independent copies: verify separate failure domains, ownership, credentials, transport protection, destination paths, quotas and restore access.

The Filestore guide says several failed remote transfers can leave a copy under /var/spool/asterisk/backup/backup_name/backupfile. That fallback is still on the PBX and can consume local storage; it is not proof of off-system protection. Email is documented for small archives, with a 25 MB default maximum. Measure archive size and duration instead of assuming the transport will accept recordings or long retention.

Read the generated schedule and notification path

Enable scheduling deliberately and inspect every generated field. Sangoma's guide says the schedule fields default to random values, so a newly created job must not be described as a midnight backup without checking its actual expression. Set frequency from the recovery-point objective, expected change rate, archive duration and destination window; stagger recording-heavy jobs away from busy calling periods.

Backup notifications require an email address in the job, and mail can be filtered or fail independently. Test the notification route, but keep it separate from scheduler execution, archive creation and remote arrival. Record the job ID, displayed schedule, timezone, next expected run, start and finish time, notification result and destination object.

Make retention arithmetic explicit

The current module guide documents retention by run count or age. Delete After Runs set to 0 means unlimited retention, not deletion of every archive. Translate the chosen schedule and retention into expected archive count and storage: include failed-transfer local fallbacks, temporary working space, growth in voicemail or recordings and the time needed to detect a bad backup.

Confirm that expired archives are actually removed from each selected location and that at least one known-good restore point remains after the job runs. Destination free space, object count, archive size and retention deletion are separate observations; an old filename disappearing does not prove the newest archive is complete.

Verify job, archive and restore as three stages

Use the job grid and fwconsole backup --list to identify the configured job and its ID, then use the exact CLI command shown by the installed module when automation or a controlled manual run is required. First confirm scheduler or command completion, then confirm the expected archive arrived and is readable, and finally perform a complete isolated restore. A zero-byte, truncated, incomplete or undecryptable archive can pass a superficial file-exists check.

The web restore flow presents a module confirmation, while Sangoma warns that CLI restore has no confirmation. Isolate the target and block production trunk registration or calling before importing an archive. Record source and target FreePBX and module versions, archive identity, encryption-key recovery, selected modules, elapsed time, warnings, manual steps and the post-restore call matrix.

Plan the FreePBX 17 migration boundary

Sangoma describes cross-version restore for FreePBX 15 and later, but that capability is not proof that every module, custom file, operating-system dependency or channel driver is compatible. The current restore guide exposes FreePBX 17 choices to skip or convert chan_sip extensions and trunks to PJSIP. Treat each skip or conversion option as a migration decision with its own inventory, rollback and acceptance test.

Do not combine an unpractised disaster restore, channel-driver conversion and production cutover into one assumed-safe operation. Rehearse the selected path in an isolated target, compare extensions, trunks, routes, prompts, voicemail, recordings and custom files, and use the restore testing procedure before relying on the measured recovery time. Retest after changing module versions, storage providers, encryption, archive contents or conversion policy.

Monitor the scheduled job and destination object separately

The Filestore workflow records job completion, local archive, transfer result, destination presence, age and cleanup independently. Follow the missing-artifact diagnostic before widening credentials or rerunning an uncontrolled schedule.