A configuration restore did not restore calls or audio
Identify what the configuration archive actually contains and which separate backups are required for full recovery.
Recognize the symptom
Users and settings returned after a restore, but historical reports, analysis or recordings did not. Alternatively, a restored server still uses its own database and AMI connections. These outcomes can reflect the archive’s intended scope rather than a failed configuration restore.
Possible causes
Configuration backup includes users, permissions, 2FA associations, preferences, operational views and supported application settings and catalogues. It excludes SQL history, source CDR/queuelog, audio, analysis, license and custom SQL routine definitions. Destination connections, paths and IP/proxy rules are intentionally preserved.
Check before changing anything
Identify the missing item and locate the backup that covers it. Review the configuration restore preview separately from any SQL dump or audio archive. For a whole-server recovery, inventory database objects, protected keys, license, recording storage, installer state and scheduled jobs before restoring.
Take a targeted action
Follow the dedicated restore procedure for each backup type. Restore-test on an isolated destination where jobs and SQL events cannot act on production; a second database on the same server is not sufficient isolation. Preserve the external 2FA key and the destination connection settings deliberately.
Verify the result
After configuration restore, sign in with an administrator from the restored configuration and replace old recovery codes. Verify settings, permissions, report data and audio as separate checks. A successful configuration import proves only that scope; it does not certify a complete PBX or disaster recovery.