Gemenskapslösning

ZimaOS-säkerhetskopiering fastnar vid beräkning av OneDrive-rot: fel i källa kontra destination

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.

Den här tråden är värdefull eftersom den till slut skiljde på två symtom som såg ut som ett enda fel i Backup-appen: en stor OneDrive-rot förblev länge i Calculating, medan valet av Zima Storage som lokal destination utlöste ett separat problem i väljaren/användargränssnittet.

ZimaOS Backup-appen har fastnat i beräkningen av en OneDrive-rotkälla i version 1.5.1 beta
Den ursprungliga rapporten visade att OneDrive-rotkällan förblev i läget Calculating.
Destinationsväljaren i ZimaOS Backup-appen kunde inte öppna Zima Storage medan OneDrive beräknades
Felet i destinationsväljaren uppstod när användaren försökte välja lokal Zima Storage.
Test av ZimaOS Backup med en mindre OneDrive-mapp för att avgöra om datasetets storlek orsakade problemet
En mindre källa beräknades korrekt, vilket hjälpte till att skilja beräkningstid från felet vid val av destination.
ZimaOS Backup-appen visar att gränssnittet för lokal Zima Storage-destination inte fungerar vid val
Källtråden återskapade problemet vid val av destination med lokal Zima Storage.
ZimaOS Backup-appen väljer framgångsrikt en ansluten USB-NVMe-destination under jämförelsetestning
En ansluten USB-NVMe-destination återskapade inte samma problem med väljaren för lokal Zima Storage.

Det kan vara resurskrävande att räkna upp stora molnrötter

Källanvändaren testade ungefär 400 GB i OneDrive-roten. Microsoft Graphs lista över enheter visar att rotens innehåll räknas upp som DriveItems och kan kräva sidindelning. En säkerhetskopieringsapp måste därför identifiera och ta hänsyn till många objekt innan den kan visa en korrekt källstorlek.

Det aktuella arbetsflödet för ZimaOS-säkerhetskopiering är den bättre referensen för normalt säkerhetskopieringsbeteende i produktion, medan ZimaOS molnintegration förklarar det aktuella integrationslagret för molndiskar som används innan en fjärranslutning kan bli källa eller destination för en säkerhetskopiering.

Testet med den lilla mappen är den mest användbara diagnostiken

Användaren testade en mapp med 11 objekt, och den beräknades korrekt. Det är ett bra isoleringstest: om en liten molnmapp slutförs men en stor rot tar mycket längre tid, är tiden för källans uppräkning en av variablerna. Om destinationsväljaren fortfarande inte fungerar efteråt är det ett separat problem med användargränssnittet eller lagringsvalet.

Alternativa destinationer hjälper till att skilja på felet

En ansluten USB-NVMe-destination och en Google Drive-destination återskapade inte samma beteende i väljaren för lokal Zima Storage. Därför framstod ett problem i destinationsgränssnittet som mer sannolikt än ett allmänt fel i Backup-motorn.

Översikten över Zima Client är användbar när du ska avgöra om en arbetsstationsbaserad säkerhetskopiering eller en säkerhetskopiering från ZimaOS till molnet är den bättre arkitekturen för ett visst dataset.

Kopiera inte felsökningskommandon från betaversionen till aktuella system

Tråden innehåller utvecklarkommandon som lsblk, lspci, lsusb och en intern begäran till ett lokalt lagrings-API. Dessa var diagnostiska förfrågningar för ett problem i version 1.5.1 beta och är inte nödvändiga steg för att använda Backup aktuellt.

För själva OneDrive-autentiseringen förklarar den aktuella rclone-konfigurationen för OneDrive hur webbläsarbaserad auktorisering och konfiguration av fjärranslutningar fungerar på den underliggande nivån. En fördröjning vid uppräkning av källan och ett OAuth-fel är olika problem.

Sammanfattning

Diagnostisera inte ”fastnat i beräkningen” och ”kan inte välja Zima Storage” som ett enda fel. Testa en mindre molnmapp, testa en annan destination och identifiera vilket steg som faktiskt misslyckas. Tråden gällde ZimaOS 1.5.1 beta, så aktuella system bör använda det senaste beteendet för Backup och molnintegration innan gamla lösningar återskapas.