Dieser Thread ist wertvoll, weil er schließlich zwei Symptome voneinander getrennt hat, die zunächst wie ein einziger Fehler der Backup-App aussahen: Ein großes OneDrive-Stammverzeichnis blieb lange bei Wird berechnet, während die Auswahl des lokalen Zima Storage als Ziel ein separates Problem mit der Auswahloberfläche auslöste.
Große Cloud-Stammverzeichnisse können aufwendig zu erfassen sein
Der Benutzer aus dem Ausgangsbeitrag testete am OneDrive-Stammverzeichnis ungefähr 400 GB. Die Microsoft-Graph-Auflistung von Laufwerken zeigt, dass die Inhalte des Stammverzeichnisses als DriveItems erfasst werden und möglicherweise mehrere Seiten benötigen. Eine Backup-Anwendung muss daher zunächst viele Objekte entdecken und berücksichtigen, bevor sie eine genaue Quellgröße anzeigen kann.
Der aktuelle ZimaOS-Backup-Ablauf ist die bessere Referenz für das normale Backup im Produktivbetrieb, während die ZimaOS-Cloud-Integration die aktuelle Integrationsschicht für Cloud-Laufwerke erklärt, die verwendet wird, bevor eine Remote-Verbindung zu einer Backup-Quelle oder einem Backup-Ziel werden kann.
Der Test mit einem kleinen Ordner ist die nützlichste Diagnose
Der Benutzer testete einen Ordner mit 11 Elementen, der erfolgreich berechnet wurde. Das ist ein guter Eingrenzungstest: Wenn ein kleiner Cloud-Ordner abgeschlossen wird, ein großes Stammverzeichnis jedoch deutlich länger benötigt, ist die Zeit für die Quellenerfassung eine mögliche Variable. Wenn die Zielauswahl anschließend weiterhin fehlschlägt, handelt es sich um ein separates Problem der Oberfläche oder der Speicherauswahl.
Alternative Ziele helfen dabei, den Fehler einzugrenzen
Ein angeschlossenes USB-NVMe-Ziel und ein Google-Drive-Ziel zeigten nicht dasselbe Verhalten wie die Auswahl von lokalem Zima Storage. Dadurch erschien ein Problem mit der Zieloberfläche plausibler als ein allgemeiner Fehler der Backup-Engine.
Die Übersicht zum Zima Client ist hilfreich, wenn entschieden werden soll, ob für einen bestimmten Datensatz ein Backup vom Arbeitsplatz aus oder ein Backup von ZimaOS in die Cloud die bessere Architektur ist.
Beta-Debug-Befehle nicht in aktuelle Systeme übernehmen
Der Thread enthält Entwicklerbefehle wie lsblk, lspci, lsusb sowie eine interne Anfrage an eine lokale Speicher-API. Dabei handelte es sich um Diagnoseanfragen für ein Problem in der Beta-Version 1.5.1 und nicht um erforderliche Schritte für die aktuelle Nutzung von Backup.
Für die OneDrive-Authentifizierung selbst erklärt die aktuelle rclone-OneDrive-Konfiguration, wie die browserbasierte Autorisierung und die Konfiguration von Remote-Verbindungen auf der unteren Ebene funktionieren. Eine Verzögerung bei der Quellenerfassung und ein OAuth-Fehler sind unterschiedliche Probleme.
Fazit
„Wird berechnet“ und „Zima Storage kann nicht ausgewählt werden“ sollten nicht als ein einziger Fehler diagnostiziert werden. Testen Sie einen kleineren Cloud-Ordner und ein anderes Ziel und ermitteln Sie, in welcher Phase der Fehler tatsächlich auftritt. Der Thread bezog sich auf die Beta-Version ZimaOS 1.5.1. Daher sollten aktuelle Systeme vor dem erneuten Anwenden alter Workarounds zunächst das aktuelle Verhalten von Backup und der Cloud-Integration verwenden.
