Perché Remote Sync ricopia un'intera cartella dopo la riconnessione?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Why Does Remote Sync Recopy an Entire Folder After Reconnecting? - Zima Store Online

La sincronizzazione remota ricopia un'intera cartella quando il client non può più dimostrare che i file locali e remoti sono gli stessi.

Dopo che un laptop, NAS, condivisione montata o peer remoto si riconnettono, il motore di sincronizzazione può ricostruire il suo indice, vedere un'identità del filesystem diversa, perdere gli hash memorizzati, rilevare timestamp modificati, trattare file rinominati come nuovi oggetti o confrontare con un database obsoleto. La diagnosi corretta protegge prima entrambe le copie, quindi determina se il client sta rieseguendo la scansione, ricalcolando gli hash, riscaricando o effettivamente ritrasferendo dati prima di resettare qualsiasi libreria.

Confermare se il Client Sta Scansionando, Calcolando Hash o Trasferendo

Registra la velocità di rete, le letture del disco, l’uso della CPU, lo stato del client e i messaggi di log durante la presunta ricopia. Una scansione completa o un passaggio di checksum può sembrare impegnativo per ore senza inviare l’intera cartella su internet.

Una discussione su rclone descrive come la modalità checksum possa ripetere l’elaborazione del checksum ad ogni esecuzione. Questo comportamento consuma spazio di archiviazione e CPU ma differisce da una vera ritrasmissione di rete.

Usa contatori di trasferimento per file o totali di pacchetti per classificare l’evento. Se vengono letti solo metadati e hash, ottimizza lo stato della scansione; se invece i byte del payload completo si spostano di nuovo, continua con i test di identità, indice, timestamp e rinomina.

Verificare se il Database o l’Indice di Sincronizzazione Sono Stati Ricostruiti

Ispeziona i log del client intorno alla riconnessione per messaggi di migrazione del database, corruzione, indice mancante, reset, riesecuzione della scansione o prima esecuzione. Confronta la directory di configurazione del client e il timestamp del database con l’ultima sincronizzazione riuscita.

Un caso di supporto Syncthing spiega che un database indice corrotto potrebbe dover essere ricostruito, facendo comportare il dispositivo come se le cartelle fossero state appena aggiunte e potenzialmente causando una grande riesecuzione iniziale della scansione.

Effettua un backup del database prima di eliminarlo o resettarlo. Se la ricopia è iniziata subito dopo una reinstallazione dell’app, la ricreazione del container, il reset del profilo o la perdita del database, conserva i dati buoni e usa il flusso di lavoro supportato dal client per riconnettersi a una cartella esistente.

Confrontare l’Identità del File Oltre al Nome

Seleziona diversi file che il client vuole ricopiare e confronta dimensione, ora di modifica, checksum, permessi, proprietà, maiuscole/minuscole, attributi estesi e percorso su entrambi i lati. Registra quale campo differisce.

Gli utenti di FreeFileSync discutono di memorizzare checksum perché dimensioni e timestamp da soli potrebbero non sempre dimostrare che i file abbinati rimangono identici, mentre i database di checksum aggiungono i propri requisiti di stato. Questo illustra perché i metadati per il confronto dei file sono importanti dopo la riconnessione.

Se gli hash del contenuto corrispondono ma differiscono timestamp o permessi, correggi l’orologio, le impostazioni di conservazione dei metadati o di confronto invece di ritrasferire il contenuto. Se gli hash differiscono, identifica quale lato è autorevole prima di consentire la sovrascrittura automatica.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

Verificare se la Cartella Si è Riconnessa con un’Identità Diversa

Confronta il percorso montato, UUID del filesystem, nome della condivisione di rete, lettera di unità, identificatore del volume, bind mount del container e sensibilità alle maiuscole/minuscole prima e dopo la disconnessione. Un percorso di cartella familiare può indicare un mount diverso o una directory locale vuota.

Gli strumenti di sincronizzazione spesso memorizzano l’identità della cartella in un database locale invece di fidarsi solo del percorso visualizzato. Una condivisione NAS rimontata, un disco USB sostituito, un volume Docker modificato o un profilo client ricreato possono quindi sembrare una destinazione completamente nuova.

Interrompi la sincronizzazione se il mount previsto è assente o la cartella punta a uno storage locale di fallback. Ripristina il mount originale e verifica i file di esempio prima di ricollegare la libreria per evitare cancellazioni o download duplicati.

Testare se Spostamenti e Rinomine Vengono Rilevati

Scegli una piccola cartella, rinominala mentre entrambi i peer sono connessi e osserva se il client esegue uno spostamento dei metadati o carica ogni file come nuovo contenuto. Ripeti dopo una disconnessione e riconnessione.

Una discussione sulle funzionalità di Syncthing nota che spostamenti o rinomine possono essere trattati come nuovi trasferimenti quando lo strumento non riesce a far corrispondere i percorsi modificati tramite il suo indice esistente, producendo un comportamento di cancellazione e ricaricamento.

Se la ricopia segue una rinomina di cartella di alto livello, lascia che il client completi lo scambio dell’indice prima di apportare ulteriori modifiche. Per librerie grandi, evita rinomine di massa simultanee su più peer e mantieni attiva la versione o la protezione di backup.

Riconnettersi in Sicurezza Senza Resettare la Copia Buona

Crea un backup o uno snapshot del lato autorevole, metti in pausa la sincronizzazione e testa una piccola sottocartella usando la funzione di cartella esistente o di ricollegamento del client. Non cliccare un pulsante generico di reset o risincronizzazione prima di comprenderne la direzione.

La guida ZimaSpace per ripristinare in sicurezza una cartella condivisa fornisce lo stesso principio di contenimento per proteggere i dati non interessati.

Il problema si risolve solo quando la riconnessione preserva l’indice, confronta i file esistenti senza trasferire payload, applica solo modifiche genuine e sopravvive a un’altra disconnessione. Se il database si corrompe o scompare ripetutamente, risolvi il problema di storage, spegnimento, persistenza del container o installazione del client invece di accettare sincronizzazioni complete ricorrenti.