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.





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.
