Perché un processo di sincronizzazione cloud ricarica i file precedentemente eliminati dopo il ripristino del database del suo stato?
Un database di sincronizzazione ripristinato può ricaricare i file eliminati quando non contiene più i record di eliminazione che distinguevano la rimozione intenzionale dai dati locali appena rilevati.
La sincronizzazione bidirezionale si basa su più elementi dei soli file attualmente visibili. Mantiene un indice o un database dei percorsi precedenti, delle versioni, degli ID dei dispositivi, dei tombstone e dello stato di sincronizzazione. Il ripristino di un database più vecchio lasciando invariati file locali più recenti o lo stato del cloud crea una discrepanza temporale: il client può analizzare una copia locale ancora presente come nuova oppure interpretare l’eliminazione remota come un conflitto. Metti in pausa ogni partecipante alla sincronizzazione prima di decidere quale sequenza temporale considerare autorevole.
Conferma quale database e quale albero dei file sono stati ripristinati
Registra l’orario del backup del database, l’orario dell’albero dei file locali, lo stato del cloud, la configurazione del client, l’identità del dispositivo e il primo evento di ricaricamento. Verifica se il database e i file provengono dallo stesso punto di ripristino.
La procedura di ripristino di Nextcloud richiede di ripristinare il database e la directory dei dati come un unico sistema coerente, perché il ripristino di un solo livello crea metadati che non corrispondono più ai file archiviati.
Se il database è precedente all’eliminazione ma l’albero locale contiene una copia più vecchia ancora presente, il ricaricamento è prevedibile. Conserva tutti e tre gli stati prima di consentire un altro ciclo di sincronizzazione automatica.
Verifica se i tombstone delle eliminazioni sono stati ripristinati a uno stato precedente
Determina se lo stato ripristinato contiene l’evento di eliminazione, la versione del file, l’ID dell’elemento remoto e il dispositivo che originariamente ha rimosso il file. Confronta i log immediatamente precedenti e successivi all’eliminazione.
Syncthing mantiene un database di indice locale e avverte che un ripristino del database forza una scansione completa e una nuova sincronizzazione; se in seguito compare un albero di file montato più vecchio, possono verificarsi versioni incoerenti.
Un’eliminazione presente solo nel database più recente non è disponibile dopo il ripristino a uno stato precedente. La scansione successiva vede il file rimasto, ma non dispone delle informazioni storiche che indicavano di mantenerlo eliminato.
Esamina i file di elenco di Bisync con stato persistente o della sincronizzazione bidirezionale
Per strumenti come Rclone Bisync, individua entrambi gli elenchi precedenti, la directory di lavoro, lo stato del lock e l’ultima esecuzione completata correttamente. Non considerare una nuova sincronizzazione equivalente alla prosecuzione da uno stato valido.
Rclone documenta che Bisync conserva lo stato tra un’esecuzione e l’altra e archivia i dati di lavoro separatamente dalle cartelle sincronizzate.
Il ripristino o l’eliminazione di questi elenchi può cancellare la distinzione tra “eliminato dall’ultima esecuzione” ed “esiste solo su questo lato”. Esegui una simulazione e salva entrambi gli elenchi prima di ricostruire lo stato.
Aggiorna l’impronta digitale del server dopo il ripristino di un database
Verifica se la piattaforma server fornisce un indicatore di ripristino che informi i client del ripristino del database. Applicalo prima che i client si riconnettano.
OwnCloud ordina agli amministratori di eseguire maintenance:data-fingerprint dopo il ripristino, in modo che i client desktop e mobili possano riconoscere lo stato recuperato del server.
Senza un’impronta di ripristino modificata, i client possono continuare a basarsi su presupposti creati rispetto al database più recente. Ciò può causare conflitti, ricaricamenti o tentativi di eliminare oggetti ripristinati sul server.
Individua le copie locali sopravvissute all’eliminazione nel cloud
Cerca su ogni dispositivo sincronizzato, cartella offline, percorso escluso, cestino, directory dei conflitti e cartella temporanea di ripristino eventuali copie del file eliminato.
Dropbox spiega che l’eliminazione di un elemento può rimuoverlo dai dispositivi sincronizzati, ma le copie appartenenti ad altri utenti o che non partecipano più allo stesso stato sincronizzato possono rimanere.
Un file locale sopravvissuto diventa candidato al caricamento quando il database ripristinato non lo riconosce più come il vecchio oggetto eliminato. Calcolane l’hash e mettilo in quarantena fuori dalla radice sincronizzata prima della riconciliazione.
Metti in pausa i client prima di reimpostare o ricostruire lo stato di sincronizzazione
Arresta i processi di sincronizzazione del server e metti in pausa ogni client di sincronizzazione desktop, mobile, containerizzato e pianificato. Riconnetti prima un unico endpoint autorevole.
La procedura di reimpostazione di OneDrive di Microsoft indica che il client ricostruisce il proprio file DAT locale, mostrando perché una reimpostazione modifica lo stato del client senza stabilire quale versione storica del file debba essere considerata autorevole.
La reimpostazione non sostituisce la scelta della sequenza temporale corretta. Se più client eseguono la scansione contemporaneamente, uno può caricare una vecchia copia locale mentre un altro propaga l’eliminazione.
Riconcilia una cartella con una simulazione e un backup indipendente
Esporta il database ripristinato, copia tutti i file locali in conflitto fuori dalle radici sincronizzate, scegli lo stato autorevole e testa una piccola cartella prima di riprendere la sincronizzazione dell’intera libreria.
La guida al backup 3-2-1 di ZimaSpace definisce il limite complementare: lo stato di sincronizzazione non è una copia di ripristino indipendente quando può riprodurre un’eliminazione o ricaricare dati obsoleti.
Il problema è risolto quando i file eliminati restano eliminati, i superstiti intenzionali vengono caricati una sola volta, i conflitti sono documentati e una seconda sincronizzazione controllata non produce alcuna ricomparsa imprevista.
Domande frequenti
Il ripristino del database ripristina anche la cronologia delle eliminazioni?
Solo fino alla data del backup del database. Le eliminazioni registrate dopo quel momento non sono presenti, a meno che non siano conservate da un altro log o endpoint.
Tutti i client di sincronizzazione devono rimanere connessi durante il ripristino?
No. Mettili in pausa e riconnetti prima un unico endpoint autorevole, così i client più vecchi non potranno reintrodurre immediatamente file obsoleti.
Una scansione completa risolverà il problema in modo sicuro?
Una nuova scansione ricostruisce ciò che esiste attualmente, ma non può dedurre l’intento storico mancante. Potrebbe ricaricare i file sopravvissuti, a meno che lo stato autorevole non venga scelto prima.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Perché il ripristino di un volume Docker ricrea il contenuto dei file, ma elimina gli attributi estesi?
Una diagnosi del ripristino del volume che copre l’inventario degli xattr, le opzioni di tar e Rsync, gli spazi dei nomi, il supporto della...
Perché un container in esecuzione mantiene il vecchio limite di memoria dopo la modifica del file Compose?
Una diagnosi dei limiti di memoria che copre i cgroup attivi, il riavvio rispetto alla ricreazione, i campi di Compose, i limiti rigidi e...
Perché il riavvio di un proxy inverso invalida ogni sessione per una determinata app self-hosted?
Una diagnosi della perdita di sessione che copra l’ambito dei riavvii, la gestione dei cookie, la rotazione dei segreti, le sessioni basate sulla cache,...
