Community Solution

ZimaOS Backup Stuck Calculating OneDrive Root: Source vs Destination Bugs

A beta tester found that a 400 GB OneDrive root could take a long time to calculate, while choosing local Zima Storage as the destination triggered a separate UI problem that did not occur with an attached USB NVMe or Google Drive.

This thread is valuable because it eventually separated two symptoms that looked like one Backup app failure: a large OneDrive root remained in Calculating for a long time, while selecting local Zima Storage as the destination triggered a separate picker/UI problem.

ZimaOS Backup app stuck calculating a OneDrive root source in version 1.5.1 beta
The original report showed the OneDrive root source remaining in Calculating.
ZimaOS Backup app destination picker failing to open Zima Storage while OneDrive is being calculated
The destination picker bug appeared when the user tried to choose local Zima Storage.
ZimaOS Backup test using a smaller OneDrive folder to isolate whether dataset size caused the issue
A smaller source calculated successfully, helping separate calculation time from the destination-selection bug.
ZimaOS Backup app showing the local Zima Storage destination interface failing during selection
The source thread reproduced the destination-selection problem with local Zima Storage.
ZimaOS Backup app selecting an attached USB NVMe destination successfully during comparison testing
An attached USB NVMe destination did not reproduce the same local Zima Storage picker problem.

Large Cloud Roots Can Be Expensive to Enumerate

The source user was testing roughly 400 GB at the OneDrive root. Microsoft Graph's Microsoft Graph drive listing shows that root contents are enumerated as DriveItems and may require paging. A backup application must therefore discover and account for many objects before it can present an accurate source size.

The current ZimaOS backup workflow is the better reference for normal production backup behavior, while ZimaOS cloud integration explains the current cloud-drive integration layer used before a remote can become a backup source or destination.

The Small-Folder Test Is the Most Useful Diagnostic

The user tried an 11-item folder and it calculated successfully. That is a good isolation test: if a small cloud folder completes but a large root takes much longer, source enumeration time is one variable. If the destination picker still fails afterward, that is a separate UI/storage-selection problem.

Alternate Destinations Help Separate the Failure

An attached USB NVMe destination and a Google Drive destination did not reproduce the same local Zima Storage picker behavior. That made the destination UI a more plausible issue than a universal Backup engine failure.

The Zima Client overview is useful when deciding whether a workstation-side backup or a ZimaOS-to-cloud backup is the better architecture for a particular dataset.

Do Not Copy Beta Debug Commands into Current Systems

The thread contains developer commands such as lsblk, lspci, lsusb, and an internal localhost storage API request. Those were diagnostic requests for a 1.5.1 beta issue, not required steps for current Backup use.

For OneDrive authentication itself, the current rclone OneDrive configuration explains how browser-based authorization and remote configuration work at the lower layer. A source-enumeration delay and an OAuth failure are different problems.

Bottom Line

Do not diagnose “stuck calculating” and “cannot select Zima Storage” as one defect. Test a smaller cloud folder, test another destination, and identify which stage actually fails. The thread was tied to ZimaOS 1.5.1 beta, so current systems should use the latest Backup and cloud-integration behavior before reproducing old workarounds.