Freeze one run and name the missing evidence
Record the PBX, installed Backup & Restore and Filestore versions, job ID, schedule or manual trigger, start and finish times, selected modules and custom paths, named destination, expected archive name, local spool path, reported result and the exact remote account, path or bucket inspected. Redact credentials and personal data.
Classify the earliest gap as job not started, archive creation failed, local archive created, handler not invoked, connection rejected, transfer interrupted, remote object written elsewhere, object deleted by retention or retrieval denied. A passing destination test is evidence only for that probe.
Prove archive creation before changing the destination
Inspect the job log and local filesystem for the expected archive, its size, timestamp and stable hash. Confirm that the job included the intended modules and paths and had enough local capacity to assemble the file. A destination cannot receive bytes that the backup job never created.
Sangoma documents a local spool fallback for several destination failures. Preserve that file and the error before rerunning the job. Repeated retries can fill the PBX filesystem, overwrite useful evidence or create several differently named objects without correcting the transfer boundary.
Match the selected handler to its exact configuration
Verify that the job references the intended Filestore instance, then compare its protocol, host, port, path, region, bucket, account and credential owner with the destination service. For FTP distinguish plain FTP, TLS and SFTP; for SSH preserve host-key and private-key evidence; for S3 preserve region, endpoint, object key and authorization result; for Dropbox preserve application-folder scope; for email preserve message size and server rejection.
Do not replace a scoped identity with root or administrator access as a diagnostic shortcut. Make one reversible correction to the earliest demonstrated mismatch and rerun the same bounded job.
Find the object independently of the PBX success label
Inspect the destination through an authorized independent view and search for the exact path or key, job-name subdirectory setting, archive name, timestamp and size. Record whether a partial object, alternate prefix, storage class, quarantine, mail rejection or lifecycle deletion exists. If the service exposes request or object identifiers, correlate them with the PBX log.
A transfer-complete message is not proof that retention kept the object, and an object list is not proof that the bytes match the local archive. Compare the hash where the service permits it, or retrieve to a contained system and calculate the hash there.
Close with retrieval and restore evidence
After the same archive is present, verify that the authorized recovery operator can retrieve it without using the production PBX credential. Preserve the original, verify its hash and test the archive only on an isolated restore target. Confirm that monitoring catches a future missing object and that stale local fallback files are removed under an approved retention rule.
Restore narrow credentials and network rules after diagnosis. Do not call the incident resolved solely because a test button turns green or a new object appears. No PBX, destination, credential, archive, restore or live call was inspected or tested for this documentation-derived workflow.
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.