Waarom uploadt een cloudsynchronisatietaak eerder verwijderde bestanden opnieuw nadat de statusdatabase is hersteld?
Een herstelde synchronisatiedatabase kan verwijderde bestanden opnieuw uploaden wanneer deze niet langer de verwijderingsregistraties bevat die opzettelijke verwijdering onderscheidden van nieuw ontdekte lokale gegevens.
Tweerichtingssynchronisatie steunt op meer dan alleen de momenteel zichtbare bestanden. De synchronisatie houdt een index of database bij met eerdere paden, versies, apparaat-ID's, tombstones en de synchronisatiestatus. Wanneer je een oudere database herstelt terwijl nieuwere lokale bestanden of cloudgegevens behouden blijven, ontstaat er een tijdsverschil: de client kan een overgebleven lokale kopie als nieuw scannen of de verwijdering op afstand als een conflict interpreteren. Pauzeer elke synchronisatiedeelnemer voordat je bepaalt welke tijdlijn leidend is.
Bevestig welke database en bestandsstructuur zijn hersteld
Leg het tijdstip van de databaseback-up, het tijdstip van de lokale bestandsstructuur, de cloudstatus, de clientconfiguratie, de apparaatidentiteit en de eerste gebeurtenis van opnieuw uploaden vast. Controleer of de database en bestanden afkomstig zijn van hetzelfde herstelpunt.
Volgens de herstelprocedure van Nextcloud moeten de database en gegevensmap als één consistent systeem worden hersteld, omdat het herstellen van slechts één laag metadata oplevert die niet langer overeenkomt met de opgeslagen bestanden.
Als de database ouder is dan de verwijdering, maar de lokale structuur een oudere overgebleven kopie bevat, is opnieuw uploaden voorspelbaar. Bewaar alle drie de statussen voordat je opnieuw een automatische synchronisatie toestaat.
Controleer of verwijderingstombstones zijn teruggedraaid
Ga na of de herstelde status de verwijderingsgebeurtenis, bestandsversie, externe item-ID en het apparaat bevat dat het bestand oorspronkelijk heeft verwijderd. Vergelijk de logboeken van vlak voor en na de verwijdering.
Syncthing houdt een lokale indexdatabase bij en waarschuwt dat het resetten van de database een volledige herscan en hersynchronisatie afdwingt; als er later een oudere aangekoppelde bestandsstructuur verschijnt, kunnen inconsistente versies ontstaan.
Een verwijdering die alleen in de nieuwere database bestond, ontbreekt na het terugdraaien. De volgende scan ziet het overgebleven bestand, maar mist de historische informatie dat het verwijderd moet blijven.
Controleer statusafhankelijke Bisync- of tweerichtingslijsten
Zoek bij tools zoals Rclone Bisync beide vorige lijsten, de werkmap, de vergrendelingsstatus en de laatste succesvolle uitvoering. Behandel een nieuwe hersynchronisatie niet alsof deze gelijkstaat aan doorgaan vanuit een geldige status.
Rclone documenteert dat Bisync status behoudt tussen opeenvolgende uitvoeringen en werkgegevens afzonderlijk van de gesynchroniseerde mappen opslaat.
Door deze lijsten te herstellen of te verwijderen, kan het onderscheid verdwijnen tussen “sinds de vorige uitvoering verwijderd” en “bestaat alleen aan deze kant”. Gebruik een proefuitvoering en bewaar beide lijsten voordat je de status opnieuw opbouwt.
Werk de serverfingerprint bij na het herstellen van een database
Controleer of het serverplatform een herstelmarkering biedt die clients laat weten dat de database is hersteld. Pas deze toe voordat clients opnieuw verbinding maken.
OwnCloud geeft beheerders de instructie om maintenance:data-fingerprint na het herstel uit te voeren, zodat desktop- en mobiele clients de herstelde serverstatus kunnen herkennen.
Zonder een gewijzigde herstelfingerprint kunnen clients doorgaan vanuit aannames die tegen de latere database zijn gemaakt. Dit kan leiden tot conflicten, opnieuw uploaden of pogingen om objecten te verwijderen die op de server zijn hersteld.
Identificeer lokale kopieën die de verwijdering uit de cloud hebben overleefd
Doorzoek elk gesynchroniseerd apparaat, elke offline map, uitgesloten locatie, prullenbak, conflictenmap en tijdelijke herstelmap naar kopieën van het verwijderde bestand.
Dropbox legt uit dat het verwijderen van een item dit op gesynchroniseerde apparaten kan verwijderen, maar dat kopieën die elders eigendom zijn of niet langer aan dezelfde gesynchroniseerde status deelnemen, kunnen blijven bestaan.
Een overgebleven lokaal bestand wordt een kandidaat voor upload wanneer de herstelde database het niet langer herkent als het oude verwijderde object. Bereken de hash en plaats het bestand buiten de synchronisatiewortel in quarantaine voordat je de statussen afstemt.
Pauzeer clients voordat je de synchronisatiestatus reset of opnieuw opbouwt
Stop synchronisatiewerkers op de server en pauzeer elke desktop-, mobiele, container- en geplande synchronisatieclient. Verbind eerst één leidend eindpunt opnieuw.
In de resetprocedure voor OneDrive van Microsoft staat dat de client zijn lokale DAT-bestand opnieuw opbouwt. Dit illustreert waarom een reset de clientstatus wijzigt zonder te bepalen welke historische bestandsversie leidend moet zijn.
Resetten vervangt niet het kiezen van de juiste tijdlijn. Als meerdere clients gelijktijdig opnieuw scannen, kan de ene een oude lokale kopie uploaden terwijl de andere de verwijdering verspreidt.
Stem één map af met een proefuitvoering en een onafhankelijke back-up
Exporteer de herstelde database, kopieer alle conflicterende lokale bestanden buiten de synchronisatiewortels, kies de leidende status en test één kleine map voordat je de volledige bibliotheek hervat.
De 3-2-1-back-upgids van ZimaSpace vormt de aangrenzende veiligheidsgrens: een synchronisatiestatus is geen onafhankelijke herstelkopie wanneer deze verwijderingen kan reproduceren of verouderde gegevens opnieuw kan uploaden.
Het probleem is opgelost wanneer verwijderde bestanden verwijderd blijven, bedoelde overgebleven bestanden eenmaal worden geüpload, conflicten zijn gedocumenteerd en een tweede gecontroleerde synchronisatie geen onverwachte wederopstanding oplevert.
Veelgestelde vragen
Herstelt het herstellen van de database ook de verwijderingsgeschiedenis?
Alleen tot het tijdstip van de databaseback-up. Verwijderingen die daarna zijn geregistreerd, ontbreken tenzij een ander logboek of eindpunt deze bewaart.
Moeten alle synchronisatieclients tijdens het herstel verbonden blijven?
Nee. Pauzeer ze en verbind eerst één leidend eindpunt opnieuw, zodat oudere clients niet onmiddellijk verouderde bestanden opnieuw kunnen introduceren.
Lost een volledige herscan het probleem veilig op?
Een herscan bouwt opnieuw op wat momenteel bestaat, maar kan ontbrekende historische intentie niet afleiden. Overgebleven bestanden kunnen opnieuw worden geüpload tenzij eerst de leidende status wordt gekozen.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Waarom herstelt een Docker-volume de bestandsinhoud, maar gaan uitgebreide bestandskenmerken verloren?
Een diagnose van volumeterugzetting met een inventaris van xattrs, tar- en Rsync-opties, naamruimten, ondersteuning voor bestemmingen, machtigingen, labels, app-metagegevens en tests.
Waarom behoudt een actieve container zijn oude geheugenlimiet nadat het Compose-bestand is gewijzigd?
Een diagnose van geheugenlimieten met aandacht voor actieve cgroups, herstarten versus opnieuw aanmaken, Compose-velden, harde en zachte limieten, bovenliggende scopes, swap en runtime-heaps.
Waarom maakt het herstarten van een reverse proxy elke sessie voor één zelfgehoste app ongeldig?
Een diagnose van sessieverlies met aandacht voor de reikwijdte van herstarts, cookie-eigenaarschap, geheimenrotatie, cachegestuurde sessies, sticky routing, authenticatiegateways en herstel.
