Troubleshoot QCBM Off-Site Export Failures

An off-site export failure is not automatically a backup failure. QCBM creates and verifies the local Recovery Package first, then records the remote export as a separate operation. Start troubleshooting from the exact destination and export error while preserving the valid local Backup Set.

Do not replace every credential or re-create the destination at once. The current error usually identifies which layer failed: plan/settings, destination configuration, connection/authentication, path/permission, transfer, or remote verification.

1. Read the Exact Export Result

Open the relevant Backup Set/export information and record the failure message. QCBM tracks grouped export runs and file attempts separately from the local Backup Set.

Typical early blocks include off-site export disabled in Settings, no usable destination, a non-complete Backup Set, a concurrent operation lock, or failed package-health verification.

2. Test the Destination Directly

Open Settings > Export Destinations and run Test for the failed destination. The Test performs provider-specific connection/write/verification/cleanup work with a small temporary object.

If the Test fails, fix that provider problem before retrying a full Recovery Package export.

3. Match the Error to the Provider

  • Local / Server Path: check path safety, existence/writability, mounted-storage availability, free space, and permissions.
  • SFTP: check PHP ssh2 support, host/port, username/password, remote folder, and the independently verified SSH host-key SHA-1 fingerprint.
  • FTP/FTPS: check PHP FTP/SSL support, host/port, login, passive mode, firewall/data ports, and remote-folder permissions. Plain FTP also requires the insecure-transport acknowledgement.
  • Google Drive: check OAuth application credentials, exact redirect URI, Drive API availability, current authorization, account/folder access, and quota.
  • OneDrive: check Application ID/Secret Value, account-type registration, exact Web redirect URI, delegated Graph permissions, current authorization, and quota.

4. Check Write and Cleanup Rights

Destination testing and production export require more than read access. QCBM may need to create folders, upload files, verify uploaded objects, and remove temporary test objects.

A provider account that can browse a folder but cannot create or remove objects can still fail QCBM's Test or export workflow.

5. Distinguish Transfer Failure from Verification Failure

If upload begins but QCBM reports a size or checksum failure, treat that as a data-integrity problem rather than merely marking the job successful. Google Drive requires remote size and MD5 agreement; OneDrive requires remote size and verifies SHA-1 when returned; remote-server backup exports verify remote size.

Do not delete the local package after a remote verification failure.

6. Preserve the Local Backup While You Fix Remote Storage

A completed, verified local Recovery Package can remain usable even when its export state is failed or partial. Keep it until the remote problem is resolved and a new export succeeds.

7. Retry One Controlled Export

After the destination Test passes, manually export one completed Backup Set. Confirm the correct destination, successful result, and expected remote account/folder before returning automatic export to normal operation.

If repeated failures continue with a healthy destination Test, preserve the exact export message and use it with the QuantaCade support system rather than repeatedly changing unrelated settings.

Community Discussion

Want to compare workflows, share practical tips, or discuss how you use this QCBM feature? Visit the QC Backup Manager Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.