Varför laddar ett molnsynkroniseringsjobb upp tidigare raderade filer igen efter att dess tillståndsdatabas har återställts?
En återställd synkroniseringsdatabas kan ladda upp raderade filer igen när den inte längre innehåller de raderingsposter som skiljde avsiktlig borttagning från nyupptäckta lokala data.
Tvåvägssynkronisering bygger på mer än de filer som för närvarande visas. Den lagrar ett index eller en databas över tidigare sökvägar, versioner, enhets-ID:n, borttagningsmarkeringar och synkroniseringsstatus. Om en äldre databas återställs samtidigt som nyare lokala filer eller molnstatus lämnas kvar uppstår en tidsmässig avvikelse: klienten kan skanna en kvarvarande lokal kopia som ny eller tolka borttagningen på fjärrsidan som en konflikt. Pausa alla synkroniseringsdeltagare innan du avgör vilken tidslinje som ska vara den auktoritativa.
Bekräfta vilken databas och vilket filträd som återställdes
Notera tidpunkten för databassäkerhetskopian, tiden för det lokala filträdet, molnstatus, klientkonfiguration, enhetsidentitet och den första händelsen med återuppladdning. Kontrollera om databasen och filerna kommer från samma återställningspunkt.
Nextclouds återställningsprocedur kräver att databasen och datakatalogen återställs som ett sammanhängande system, eftersom en återställning av endast ett lager skapar metadata som inte längre stämmer överens med de lagrade filerna.
Om databasen är äldre än borttagningen, men det lokala trädet innehåller en äldre kvarvarande kopia, är en återuppladdning förväntad. Bevara alla tre tillstånden innan du tillåter ytterligare en automatisk synkroniseringsomgång.
Kontrollera om borttagningsmarkeringarna rullades tillbaka
Ta reda på om det återställda tillståndet innehåller borttagningshändelsen, filversionen, ID:t för fjärrobjektet och enheten som ursprungligen tog bort filen. Jämför loggar från direkt före och efter borttagningen.
Syncthing använder en lokal indexdatabas och varnar för att en databasåterställning tvingar fram en fullständig omskanning och omsynkronisering. Om ett äldre monterat filträd senare blir synligt kan inkonsekventa versioner uppstå.
En borttagning som endast fanns i den nyare databasen saknas efter återställningen. Nästa skanning ser den kvarvarande filen, men saknar den historiska information som visar att den ska förbli borttagen.
Granska tillståndsbaserade Bisync- eller tvåvägslistfiler
För verktyg som Rclone Bisync ska du hitta båda tidigare listorna, arbetskatalogen, låsstatusen och den senaste lyckade körningen. Behandla inte en ny omsynkronisering som om den vore en fortsättning från ett giltigt tillstånd.
Rclone dokumenterar att Bisync är tillståndsbaserat mellan efterföljande körningar och lagrar arbetsdata separat från de synkroniserade mapparna.
Om dessa listor återställs eller tas bort kan skillnaden mellan ”raderad sedan den senaste körningen” och ”finns endast på den här sidan” försvinna. Använd en testkörning och spara båda listorna innan du bygger om tillståndet.
Uppdatera serverns fingeravtryck efter en databasåterställning
Kontrollera om serverplattformen tillhandahåller en återställningsmarkör som meddelar klienterna att databasen har återställts. Tillämpa den innan klienterna ansluter igen.
OwnCloud instruerar administratörer att köra maintenance:data-fingerprint efter återställningen så att dator- och mobilklienter kan känna igen serverns återställda tillstånd.
Utan ett ändrat återställningsfingeravtryck kan klienterna fortsätta utifrån antaganden som skapats mot den senare databasen. Det kan leda till konflikter, återuppladdningar eller försök att ta bort objekt som har återställts på servern.
Identifiera lokala kopior som överlevde borttagningen i molnet
Sök på alla synkroniserade enheter, i offline-mappar, undantagna sökvägar, papperskorgar, konfliktkataloger och tillfälliga återställningsmappar efter kopior av den borttagna filen.
Dropbox förklarar att en borttagning kan ta bort ett objekt på synkroniserade enheter, men kopior som ägs någon annanstans eller inte längre deltar i samma synkroniserade tillstånd kan finnas kvar.
En kvarvarande lokal fil blir en möjlig uppladdning när den återställda databasen inte längre känner igen den som det tidigare borttagna objektet. Beräkna dess hash och placera den i karantän utanför synkroniseringsroten innan avstämningen.
Pausa klienterna innan du återställer eller bygger om synkroniseringstillståndet
Stoppa serverns synkroniseringsarbetare och pausa alla synkroniseringsklienter på datorer, mobiler, containrar och schemalagda jobb. Anslut först en auktoritativ slutpunkt igen.
Microsofts procedur för återställning av OneDrive anger att klienten bygger om sin lokala DAT-fil, vilket visar varför en återställning ändrar klientens tillstånd utan att avgöra vilken historisk filversion som ska vara auktoritativ.
En återställning ersätter inte valet av rätt tidslinje. Om flera klienter skannar samtidigt kan en av dem ladda upp en gammal lokal kopia medan en annan sprider borttagningen.
Stäm av en mapp med en testkörning och en separat säkerhetskopia
Exportera den återställda databasen, kopiera alla motstridiga lokala filer utanför synkroniseringsrötterna, välj det auktoritativa tillståndet och testa en liten mapp innan du återupptar synkroniseringen av hela biblioteket.
ZimaSpaces guide till säkerhetskopiering enligt 3-2-1 visar den närliggande gränsen: synkroniseringstillstånd är inte en separat återställningskopia när det kan återskapa borttagningar eller återuppladda föråldrade data.
Problemet är löst när borttagna filer förblir borttagna, avsedda kvarvarande filer laddas upp en gång, konflikter dokumenteras och en andra kontrollerad synkronisering inte leder till någon oväntad återkomst.
Vanliga frågor
Återställer databasen även borttagningshistoriken?
Endast fram till tidpunkten för databassäkerhetskopian. Borttagningar som registrerades efter den tidpunkten saknas, om inte någon annan logg eller slutpunkt bevarar dem.
Ska alla synkroniseringsklienter förbli anslutna under återställningen?
Nej. Pausa dem och anslut först en auktoritativ slutpunkt så att äldre klienter inte omedelbart kan återinföra föråldrade filer.
Kommer en fullständig omskanning att lösa problemet på ett säkert sätt?
En omskanning bygger om en bild av det som finns för närvarande, men den kan inte sluta sig till saknad historisk avsikt. Den kan återuppladda kvarvarande filer om det auktoritativa tillståndet inte väljs först.
Rekommenderade produkter
Support och tips
Mer att läsa
Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.
Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.
Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En sessionsförlustdiagnos som omfattar omstartens omfattning, cookie-ägarskap, rotation av hemligheter, cachebaserade sessioner, sticky routing, autentiseringsgatewayer och återställning.
