このスレッドが有用なのは、最終的に、1つのBackupアプリの障害に見えた2つの症状を切り分けられたためです。大容量のOneDriveルートは長時間計算中のままになりましたが、保存先としてローカルのZima Storageを選択すると、別のピッカー/UI問題が発生しました。
大規模なクラウドルートの列挙には時間がかかることがある
元のユーザーは、OneDriveのルートで約400 GBをテストしていました。Microsoft GraphのMicrosoft Graphのドライブ一覧取得では、ルートの内容はDriveItemとして列挙され、ページングが必要になる場合があります。そのため、バックアップアプリが正確なソースサイズを表示するには、多数のオブジェクトを検出して集計する必要があります。
通常の本番バックアップの動作を確認するには、現在のZimaOSバックアップワークフローがより適切な参考資料です。一方、ZimaOSクラウド統合では、リモートをバックアップのソースまたは保存先にする前に使用される、現在のクラウドドライブ統合レイヤーについて説明しています。
小さいフォルダーのテストが最も有用な診断方法
ユーザーは11個の項目を含むフォルダーを試し、正常に計算できました。これは有効な切り分けテストです。小さいクラウドフォルダーは完了するのに、大きなルートでは大幅に時間がかかる場合、ソースの列挙時間が1つの要因になります。その後も保存先ピッカーが失敗するなら、それは別のUI/ストレージ選択の問題です。
別の保存先を使うと問題を切り分けやすい
接続したUSB NVMe保存先とGoogle Drive保存先では、ローカルのZima Storageで発生したものと同じピッカーの動作は再現されませんでした。そのため、Backupエンジン全体の障害よりも、保存先UIの問題である可能性が高くなりました。
特定のデータセットで、ワークステーション側のバックアップとZimaOSからクラウドへのバックアップのどちらが適した構成かを判断する際には、Zima Clientの概要が役立ちます。
ベータ版のデバッグコマンドを現在のシステムにそのままコピーしない
このスレッドには、lsblk、lspci、lsusb、および内部localhostストレージAPIへのリクエストなど、開発者向けのコマンドが含まれています。これらは1.5.1 betaの問題を診断するための依頼であり、現在のBackup利用に必要な手順ではありません。
OneDriveの認証については、現在のrclone OneDrive設定で、ブラウザベースの認証とリモート設定が低いレイヤーでどのように動作するかを確認できます。ソースの列挙が遅い問題とOAuthの失敗は別の問題です。
結論
「計算中のまま」と「Zima Storageを選択できない」を、1つの不具合として診断しないでください。小さいクラウドフォルダーを試し、別の保存先も試して、実際にどの段階で失敗しているのかを特定してください。このスレッドはZimaOS 1.5.1 betaに関するものなので、現在のシステムで再現を試みる前に、最新のBackupとクラウド統合の動作を使用してください。
