Treat Filestore as the destination owner, not the backup payload
FreePBX 15 and later moved storage-location configuration out of Backup & Restore and into the independent Filestore module. Backup jobs select modules and custom paths, while Filestore defines where the resulting archive is sent. A valid destination therefore does not prove that the job includes recordings, voicemail, certificates, custom files or every required module.
Inventory the required recovery content first, then bind one named backup job to one or more named Filestore instances. Record the installed Backup & Restore and Filestore versions, repository channel and module-signature state. The public release branch showed Filestore 17.0.3.2 when reviewed, but only the selected PBX can establish its loaded version and supported destination handlers.
Choose a destination from its security and failure model
The current Sangoma guide documents email, FTP or SFTP, local paths, Dropbox, SSH and S3. These are not interchangeable labels. Record the destination owner, protocol, host or service, path or bucket, region, identity, authentication method, encryption boundary, server fingerprint or certificate validation, network path, quota, object policy, retention and recovery owner.
Email is documented for small archives and has a default maximum of 25 MB. Plain FTP, FTP with TLS and SFTP have different connection and trust models. Local storage can share the PBX failure domain. Dropbox uses an access token. SSH uses a key and has FreePBX-version-specific warm-spare guidance. S3 requires bucket, region and credentials. Select only the handler and controls actually supported by the installed module and destination service.
Use least-privilege credentials and explicit paths
Create a destination-specific identity with access only to the required path, bucket or application folder. Keep reusable passwords, access tokens, private keys and cloud secrets out of screenshots, job logs, tickets and archives. Record the credential owner, rotation method and recovery procedure without copying the secret into the acceptance record.
Treat a path as a security boundary. The Filestore guide requires a complete leading-slash path for FTP and documents separate paths for SSH, S3, Dropbox and local instances. Validate normalization, ownership, directory creation, traversal resistance, overwrite behavior and the exact final key or filename. Do not grant root, broad bucket or home-directory access merely to make a test button succeed.
Separate connection, archive creation and transfer evidence
A destination test can establish that one handler accepted one probe with the current configuration. It does not prove that the scheduled job ran, that an archive was created, that the complete bytes reached the destination or that retention preserved them. Run one controlled backup and retain the job ID, start and finish times, selected modules and custom paths, final status, archive name, size and cryptographic hash.
Then verify the independently observed destination object: path or key, size, timestamp, hash where available, storage class, retention or immutability state and account that can retrieve it. Sangoma documents that several remote-transfer failures can leave the backup in the local spool path; treat that fallback as an alert and capacity risk, not as successful off-system protection.
Design retention, monitoring and cleanup together
Backup & Restore can limit retained copies by run count or age, and a job can target multiple Filestore locations. Record which layer deletes which copy, the timezone and schedule, what zero or unlimited means for the installed release, and how failed transfers, partial files and local fallbacks are detected. Confirm that cleanup cannot remove the last accepted recovery point or silently fill the PBX filesystem.
Monitor job completion, archive creation, transfer result, destination presence, age, size and local-spool growth as separate conditions. Exercise credential rotation and a destination outage under change control. Alerts must identify the failing boundary without publishing credentials or assuming that another configured destination received the same artifact.
Accept the destination only through a contained restore rehearsal
Retrieve an identified archive through the documented custody path, verify its expected hash and preserve the original bytes. Restore it only to an isolated target whose carrier, phone, provisioning, DNS, firewall and scheduled-work paths are denied by default. Reconcile the manifest and module inventory, then use the existing restore-testing procedure to prove required configuration and bounded call paths.
Acceptance requires evidence that the intended archive can be found, retrieved, authenticated, decrypted when applicable, parsed and restored without competing for production service. A green Filestore test, successful upload or visible object does not establish recoverability. No destination, archive or restore result is claimed from this documentation review.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma FreePBX Filestore module ↗
- Sangoma FreePBX Backup and Restore Version 15+ ↗
- FreePBX Filestore release/17.0 source ↗
- FreePBX Filestore release/17.0 module metadata ↗
- FreePBX Backup & Restore release/17.0 source ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.