Skip to main content

Troubleshooting

Backup Job Failed — Network Timeout​

Symptom: Job status shows failed with error: Upload timed out or Connection reset during transfer

Causes and fixes:

  1. Unstable internet connection — Check the device's network connectivity during the backup window. If the device is on a cellular failover or VPN with packet loss, backups will fail intermittently.
  2. Upload bandwidth throttled too aggressively — If bandwidth throttling is enabled in the policy, reduce the throttle ceiling or expand the off-peak window. A 1 Mbps cap on a device with a 500 MB incremental will time out.
  3. Firewall blocking backup traffic — Ensure the endpoint has outbound HTTPS access to *.blob.core.windows.net (Azure Blob storage) and api.theonebackups.com. Some enterprise firewalls block unknown Azure blob URLs.

The agent automatically retries failed jobs with exponential backoff. If a job fails three times consecutively, an alert is created and (if configured) a PSA ticket is opened.

Backup Missed Schedule — Device Offline During Backup Window​

Symptom: Job status shows missed or no job appears for the scheduled time

Causes and fixes:

  1. Device was offline — The agent cannot run a backup if the device is off or asleep. Check if the device was powered on during the backup window. For laptops, consider setting the policy backup window to business hours when the device is likely to be on.
  2. Agent not running — Check RMM for the agent status on the device. If the agent is not running, restart it via RMM Remote Actions → Restart Agent.
  3. Schedule conflict — If a previous job was still running when the next one was scheduled, the new job is skipped. Check the job log for overlapping jobs.

The agent does not attempt to back up data that was "missed" retroactively — it waits for the next scheduled window.

Restore Failed — Backup Corrupted​

Symptom: Restore fails with error: Hash verification failed or Decryption authentication error

Causes and fixes:

  1. Corrupted backup object in storage — Run a DR test on the device to identify which snapshots are corrupt. If only recent snapshots are affected, try an older snapshot.
  2. Encryption key rotation issue — If the tenant's Key Vault KEK was rotated without re-wrapping the backup DEKs, restores of encrypted SaaS data will fail. Contact support to initiate a re-wrap operation.
  3. Incomplete incremental chain — If a base full backup is missing, incrementals built on top of it cannot be restored. Look for a valid full backup snapshot in the catalog. If the catalog shows no valid full, a new full backup must be run.
ℹ️If a DR test fails with a hash verification error, open a support ticket immediately. Corrupted backups are a critical issue requiring investigation before the problem spreads to additional snapshots.

SaaS Backup Not Connecting to M365 — Consent Not Granted​

Symptom: M365 connection shows status Setup or Consent Expired; SaaS jobs fail with Unauthorized

Causes and fixes:

  1. Admin consent not yet granted — Click Authorize on the connection and complete the admin consent flow as a Global Administrator.
  2. Wrong admin account used — The consent must be granted by a Global Administrator of the M365 tenant being connected, not a general user or the MSP's own admin account.
  3. Conditional Access blocking consent — Some organizations have Conditional Access policies requiring consent to be performed from compliant/managed devices. Have the client's Global Admin perform the consent from a managed device.
  4. App registration blocked — Some tenants have a policy blocking third-party app consent entirely. The client's Azure AD admin must whitelist the Backups app registration or temporarily disable the consent blocking policy.

To re-authorize an expired connection, click Authorize on the connection in the SaaS tab. This starts a fresh OAuth flow.

Archive Restore Taking Too Long — Rehydration Delay​

Symptom: Archive restore request submitted but data is not available after several hours

Causes and fixes:

  1. Standard priority rehydration — Standard rehydration can take up to 15 hours. If you need data faster, cancel the standard rehydration request and submit a new one with High Priority rehydration (premium fee applies, completes in under 1 hour).
  2. No rehydration request submitted — The restore request only shows the estimated time. You must click Request Rehydration to actually start the process.
  3. Azure service degradation — Check Azure Service Health for blob storage in East US 2. During periods of Azure degradation, rehydration times can exceed the standard estimate.

Plan for archive tier rehydration time in your DR runbooks. Never rely on archive-tier data for same-day recovery scenarios.

Storage Usage Higher Than Expected​

Symptom: Storage dashboard shows much more data than expected based on device count

Causes and fixes:

  1. Large exclusion list missing — Check the policy's exclusion rules. Common culprits: node_modules directories not excluded (can be 5–20 GB per developer machine), VM disk files not excluded (*.vmdk, *.vhd), local media libraries included.
  2. First backup included unexpected paths — Review the policy's included paths. A custom source type with a broad path like C:\ will capture everything.
  3. Versioned files changing frequently — Frequently modified files (databases, log files with high write rates) generate large incremental backups. Exclude log files or database files that should be backed up at the application level instead.
  4. Retention set too high — Compare current storage usage to the retention settings. If you have 365-day daily retention enabled, you have 365 versions of every changed file.

Use the Storage tab on the device to see a breakdown by directory and identify which paths are consuming the most space.

Backup Health Score Low — Old Backup or Failed Restore Test​

Symptom: Device shows health score below 70 despite recent successful backup jobs

Causes and fixes:

  1. Failed DR test dragging down score — A failed restore test has significant weight in the health score. Check DR Testing for the device and resolve any failing tests.
  2. Backup is slightly overdue — If the device's last successful backup is outside the expected policy window (e.g., policy runs hourly but last backup was 3 hours ago), the score degrades. Check if the device was offline.
  3. Storage approaching quota — Devices near storage quota get a reduced health score as a warning. Increase the storage quota or clean up unnecessary backup data.

Bare Metal Restore Not Booting​

Symptom: After BMR completes, the machine fails to boot (blue screen, boot loop, or black screen)

Causes and fixes:

  1. Boot media creation issue — Recreate the boot media. Download a fresh ISO from Catalog → Create Boot Media and write it to a new USB drive.
  2. Target hardware incompatible — Restoring a backup from one hardware platform to different hardware (different storage controller, different BIOS mode) may require driver injection. Use the advanced BMR mode to inject chipset/storage drivers during restore.
  3. Firmware mismatch (UEFI vs BIOS) — Ensure the restore target's firmware mode (UEFI or Legacy BIOS) matches the original machine. Check the BMR options for the boot configuration mode.
  4. Incomplete image — If the backup source was user_data only (not full_image), a bare metal restore cannot be performed. Confirm the policy includes the full_image source type.

Policy Change Not Applying to Devices​

Symptom: Policy was updated but devices are still running with the old settings

Causes and fixes:

  1. Agent not yet checked in — Policy updates propagate on the next agent check-in (typically within 5 minutes for online devices). Wait for the next check-in and verify the device's effective policy in Devices → [device] → Policy.
  2. Device offline — If the device is offline, it will not receive the policy update until it reconnects. The next backup job after reconnection uses the updated policy.
  3. Scope conflict — lower-priority policy still winning — The new policy may be at a lower scope level than an existing device-level policy. Use the Resolve Policy tool to confirm which policy is winning for the device and adjust priority or scope accordingly.

SaaS Backup Not Capturing Teams Data​

Symptom: SaaS backup jobs show Exchange and OneDrive items but Teams channel messages are missing

Causes and fixes:

  1. Teams scope not selected — Confirm the SaaS connection has teams selected in the enabled scopes. Go to the connection → Edit → add Teams to the scope list. Re-authorize if needed.
  2. Missing M365 permission — Teams backup requires ChannelMessage.Read.All and TeamSettings.Read.All. If these were not granted during the initial consent flow, re-authorize the connection to trigger a new consent with the updated permission list.
  3. Teams message archiving not licensed — Some M365 license tiers do not allow third-party archiving of Teams messages. Confirm the tenant has a license that permits compliance export of Teams data (E3 or E5, or a Compliance add-on).

After resolving the permissions issue, trigger a manual backup job to backfill Teams data.