Varför kopierar Remote Sync om en hel mapp efter att ha återanslutit?

Fjärrsynkronisering kopierar om en hel mapp när klienten inte längre kan bevisa att de lokala och fjärrfilerna är desamma.

Efter att en laptop, NAS, monterad delning eller fjärrpeer återansluter kan synkmotorn bygga om sitt index, se en annan filsystemidentitet, förlora lagrade hashvärden, upptäcka ändrade tidsstämplar, behandla omdöpta filer som nya objekt eller jämföra mot en föråldrad databas. Den korrekta diagnosen skyddar båda kopiorna först och avgör sedan om klienten skannar om, räknar om hashvärden, laddar ner på nytt eller faktiskt överför data igen innan någon bibliotek återställs.

Bekräfta om klienten skannar, räknar hash eller överför

Registrera nätverkets genomströmning, diskavläsningar, CPU-användning, klientstatus och loggmeddelanden under den uppenbara omkopieringen. En fullständig skanning eller kontrollsummegenomgång kan se upptagen ut i timmar utan att skicka hela mappen över internet.

En rclone-diskussion beskriver hur kontrollsumme-läget kan upprepa kontrollsummebehandling vid varje körning. Det beteendet förbrukar lagring och CPU men skiljer sig från en verklig nätverksöverföring.

Använd överföringsräknare per fil eller paketantal för att klassificera händelsen. Om endast metadata och hashvärden läses, optimera skanningsstatus; om fulla data bytes flyttas igen, fortsätt med tester för identitet, index, tidsstämpel och namnändring.

Kontrollera om synkdatabasen eller indexet byggdes om

Granska klientloggar runt återanslutningen för databas-migrering, korruption, saknat index, återställning, omskanning eller första körningsmeddelanden. Jämför klientens konfigurationskatalog och databasens tidsstämpel med den senaste lyckade synkroniseringen.

En Syncthing-supportärende förklarar att en korrupt indexdatabas kan behöva byggas om, vilket får enheten att bete sig som om mappar nyligen lagts till och potentiellt orsakar en stor initial omskanning.

Säkerhetskopiera databasen innan du raderar eller återställer den. Om omkopieringen startade omedelbart efter en app-ominstallation, containeråterställning, profilåterställning eller databasförlust, bevara de bra data och använd klientens stödda arbetsflöde för återanslutning till befintlig mapp.

Jämför filidentitet bortom filnamnet

Välj flera filer som klienten vill kopiera om och jämför storlek, ändringstid, kontrollsumma, behörigheter, ägarskap, versalisering, utökade attribut och sökväg på båda sidor. Notera vilket fält som skiljer sig.

Användare av FreeFileSync diskuterar att lagra kontrollsummor eftersom storlek och tidsstämplar inte alltid kan bevisa att parade filer förblir identiska, medan kontrollsumme-databaser tillför egna tillståndskrav. Detta illustrerar varför filjämförelsemetadata är viktigt efter återanslutning.

Om innehållshashar matchar men tidsstämplar eller behörigheter skiljer sig, korrigera klocka, metadata-bevarande eller jämförelseinställningar istället för att överföra innehållet på nytt. Om hashvärden skiljer sig, identifiera vilken sida som är auktoritativ innan automatisk överskrivning tillåts.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Kontrollera om mappen återanslöts under en annan identitet

Jämför monteringsväg, filsystemets UUID, nätverksdelningsnamn, enhetsbokstav, volymidentifierare, containerbindmontering och versal-/gemen-känslighet före och efter frånkopplingen. En bekant mappsökväg kan peka på en annan montering eller en tom lokal katalog.

Synkverktyg lagrar ofta mappidentitet i en lokal databas istället för att enbart lita på den visade sökvägen. En omonterad NAS-delning, utbytt USB-disk, ändrad Docker-volym eller återställd klientprofil kan därför se ut som ett helt nytt mål.

Stoppa synkroniseringen om den förväntade monteringen saknas eller mappen pekar på lokal reservlagring. Återställ den ursprungliga monteringen och verifiera provfiler innan biblioteket återansluts för att förhindra borttagningar eller dubbla nedladdningar.

Testa om flyttningar och namnändringar upptäcks

Välj en liten mapp, byt namn på den medan båda parter är anslutna och observera om klienten utför en metadata-flyttning eller laddar upp varje fil som nytt innehåll. Upprepa efter frånkoppling och återanslutning.

En Syncthing-funktionsdiskussion noterar att flyttningar eller namnändringar kan behandlas som nya överföringar när verktyget inte kan matcha de ändrade sökvägarna genom sitt befintliga index, vilket ger borttagnings- och uppladdningsbeteende.

Om omkopieringen följer en övergripande mappnamnändring, låt klienten slutföra sin indexutbyte innan fler ändringar görs. För stora bibliotek, undvik samtidiga massnamnändringar på flera parter och behåll versionshantering eller backupskydd aktiverat.

Återanslut säkert utan att återställa den bra kopian

Skapa en säkerhetskopia eller snapshot av den auktoritativa sidan, pausa synkroniseringen och testa en liten undermapp med klientens funktion för befintlig mapp eller återlänkning. Klicka inte på en generell återställnings- eller resynkroniseringsknapp innan du förstår dess riktning.

ZimaSpace-guiden för säker återställning av en delad mapp ger samma isoleringsprincip för att skydda opåverkade data.

Problemet löses först när återanslutningen bevarar indexet, jämför befintliga filer utan dataöverföring, tillämpar endast verkliga ändringar och klarar ytterligare en frånkoppling. Om databasen upprepade gånger korruptas eller försvinner, åtgärda lagringen, avstängning, containerpersistens eller klientinstallationsproblemet istället för att acceptera återkommande fulla synkroniseringar.