FreePBX restore completes but module settings or files are missing

Preserve the transaction and archive identity before retrying

Record the restore transaction or job identifier, start and end time, operator, target versions, selected options, final banner, warnings and complete output and error logs. Preserve the original archive bytes, size, creation hash, source job identity, storage destination and custody trail. A completed progress screen proves neither that every module handler ran nor that each restored object reached runtime.

FreePBX's 2026 restore advisories direct administrators to update Backup & Restore before use, restrict restore access, deny hostile networks and review archive authenticity and custody. Confirm the target's installed Backup & Restore version, signature and repository channel before another import. Do not keep uploading an archive of uncertain origin or alter the only copy while diagnosing it.

Compare the source job scope with the archive manifest

Inventory the source modules, selected job items and supported additional paths, then inspect the archive manifest and metadata for the missing owner. FreePBX 15 and later make modules responsible for their backup and restore content; Sangoma's Backup Information page describes module inclusion in terms of the module's backup and restore class. If the source job omitted the module or path, changing the target cannot recreate it.

Keep Filestore evidence separate: it can prove the storage destination and artifact location, not the archive payload. Record missing recordings, voicemail, certificates, provisioning files, commercial-module data and custom scripts individually instead of adding a broad filesystem root to the next job without reviewing size, sensitivity and restore behavior.

Prove the target module owns a compatible restore handler

For each missing item, identify the target module that owns it and record whether that module is installed, enabled, signed, licensed where applicable, and compatible with the target FreePBX and Asterisk versions. Match the archived module name and version to the handler reported in the restore log. A missing handler, unavailable target version or commercial activation gap is not evidence that the whole archive is corrupt.

Do not force-install a retired module, bypass dependency or signature checks, or uninstall Backup & Restore while its own transaction runs. The release/17.0 restore implementation explicitly protects the running Backup & Restore module from uninstall/reinstall during a restore. Route a named module failure to that module's supported migration or licensing path.

Follow one item from restored data to loaded runtime

Choose one representative missing setting or file and trace it through four distinct layers: restored database or module data, restored filesystem object, generated FreePBX configuration, and loaded Asterisk or application state. Record the expected key, path, owner, permissions, timestamp and generator before applying configuration. A row in the database does not prove a file was generated; a file on disk does not prove the service loaded it.

Use Apply Config and the module's supported controls after correcting persistent state. Preserve the before-and-after generated diff and relevant logs. Do not edit generated Asterisk files, recursively change ownership, or copy an old module tree over the target to make one screen appear complete.

Account for preserve switches, conversions and target paths

Re-read the exact fwconsole backup --restore options recorded for the transaction. Flags that preserve target bind ports, DNS, remote NAT or module handling intentionally change the result; they are not generic recovery switches. On a FreePBX 17 migration, keep chan_sip-to-PJSIP conversion and unsupported reverse-version restore separate from an ordinary missing-file diagnosis.

Compare the source and target path variables, temporary directory, free space and inodes, service identity, parent-directory permissions and security controls. If the log reports extraction but the expected path is empty, prove the archive member, extraction destination and post-restore move or generator rather than widening filesystem access.

Close with a bounded reconciliation and acceptance record

Reconcile the complete source inventory against the target: module state, extensions, trunks, routes and order, DIDs, schedules and timezone, recordings, voicemail, certificates, firewall state, provisioning ownership, custom files and external integrations. Mark every absent, converted, skipped or manually restored item with an owner and evidence. Keep the target isolated from production carriers, phones and scheduled destinations during this work.

After the persistent and generated state agree, run the restore-testing procedure with internal endpoints and a bounded call matrix. Admit an external path only through a provider-approved test identity or separately authorized route. Do not place an emergency call as a generic test, and do not call the restore accepted merely because the final job status says complete.

Do not confuse destination success with archive completeness

A Filestore transfer can succeed for an archive whose job omitted a module or custom path. Reconcile the destination evidence with the backup manifest before changing restore handlers or broadening filesystem scope.