rsync su VPN: un nuovo tentativo che riusa il trasferimento interrotto

Il tuo caricamento si blocca a quattro gigabyte di un archivio da dodici gigabyte, e l’abitudine appresa dai gestori di download dice di premere riprendi. rsync non riprenderà il flusso TCP, perché quel flusso è sparito con l’ultima ritrasmissione del tunnel. Quello che può fare è conservare i byte già ricevuti e usarli come base per il tentativo successivo, un altro meccanismo con un altro insieme di regole. I flag che scegli decidono se questo riutilizzo avviene o no.

Il nuovo tentativo ricostruisce lo stato, non riprende il flusso

Quando la sessione SSH cade, all’estremità remota resta solo ciò che è riuscita a scrivere su disco, e nient’altro. Non c’è nessun token di sessione a cui riagganciarsi né numero di sequenza da riprodurre. L’esecuzione successiva apre una nuova connessione, rilegge la sorgente e chiede al destinatario cosa ha già.

È quest’ultima domanda a spiegare perché vale la pena conservare un file parziale. La copia del destinatario dà a rsync qualcosa con cui confrontarsi, e l’algoritmo invia solo le differenze che riesce a identificare. È comunque un nuovo trasferimento di metadati e una nuova passata sulla sorgente, quindi il tempo risparmiato è proporzionale a quanto del file coincide, non a quanto era avanzata la connessione precedente. Se il destinatario non ha conservato nulla, il tentativo successivo è una copia completa, quanti gigabyte abbia spostato il primo.

Decidi dove vive il frammento riutilizzabile

Il comportamento predefinito scrive il file parziale sul percorso di destinazione, il che rende visibile un archivio scritto a metà sotto il nome finale. --partial-dir lo sposta in una directory a tua scelta, e il manuale descrive quella directory come conservata per essere usata come dati da un trasferimento successivo. Un nome relativo viene risolto sotto la directory di destinazione, che è esattamente ciò che vuoi quando le due estremità possono avere disposizioni diverse.

rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
  large-archive.bin [email protected]:/srv/incoming/

Anche a destinazione conta l’ordine: la directory parziale ha bisogno di spazio sufficiente per il frammento, e il volume ha bisogno di spazio sufficiente anche per il file completato. Riempire il volume di destinazione a metà trasferimento produce un errore che sembra un problema di rete ma non lo è, e può lasciare il frammento conservato troncato. Controlla lo spazio libero sull’host ricevente prima che l’esecuzione inizi, non dopo che è fallita. Qualche secondo con df -h sullo stesso percorso SSH è il test più economico possibile del piano.

I permessi sono una preoccupazione minore ma reale. Una directory parziale scrivibile da account non correlati permette a qualcun altro di sostituire contenuto che la tua prossima esecuzione tratterà come già ricevuto. Tienila di proprietà dell’account di trasferimento e non metterla dove altri servizi pubblicano.

Esegui la stessa copia, non una più astuta

Il riutilizzo si applica solo quando sorgente e destinazione descrivono ancora lo stesso oggetto. Stesso percorso, stesso nome, stesso file. Rinominare la sorgente o puntare a un’altra directory di destinazione avvia un nuovo confronto contro nulla di utile.

Non aggiungere --whole-file aspettandoti il comportamento delta. Quell’opzione dice a rsync di copiare l’intero file senza il confronto del checksum scorrevole, che è una scelta ragionevole su un collegamento locale veloce e esattamente quella sbagliata dopo un caricamento a lunga distanza fallito. --inplace cambia anch’esso la storia: scrive direttamente nel file di destinazione, quindi un’interruzione lascia un file che mescola contenuto vecchio e nuovo senza un frammento separato su cui ripiegare.

La riga di avanzamento riporta l’avanzamento aggregato del trasferimento. Non è un segnale di completamento. Un numero che arriva al cento per cento mentre la connessione è ancora aperta significa che i dati sono stati spinti, non che il destinatario abbia rinominato, sincronizzato o accettato qualcosa.

Accetta l’oggetto solo dopo che corrisponde

Conferma prima lo stato di uscita, poi confronta il risultato invece di fidarti dell’assenza di errori. Un controllo di dimensione intercetta la maggior parte dei trasferimenti troncati; un confronto di checksum intercetta il resto, ed entrambi costano poco rispetto a rieseguire il caricamento.

Se l’archivio è pubblicato da un processo a valle, fai attendere a quel processo il file accettato. Un frammento conservato che finisce in una directory sorvegliata sotto il nome finale viene raccolto dalla scansione successiva, e l’errore del consumatore riguarderà input corrotto e non un trasferimento che non è mai finito.

Lascia stare la sorgente finché il destinatario non conferma. Rigenerare l’archivio tra un tentativo e l’altro cambia la base di confronto, e l’esecuzione successiva o trasferisce quasi tutto o produce un file che non corrisponde né alla sorgente vecchia né a quella nuova.

Quando il limite è il collegamento, non il flag

L’overhead di intestazione e protocollo è un costo del trasferimento, e raramente è quello che decide quanto tempo impiega un file grande. Il comportamento di riavvio conta di più: un metodo che sopravvive a una caduta senza passaggi manuali consegna un file utilizzabile prima di un metodo più veloce che deve ricominciare. Lo spazio su entrambe le estremità e il percorso di autenticazione appartengono allo stesso confronto.

Confronta i percorsi alternativi consentiti con lo stesso file e la stessa destinazione, e annota da dove ciascuno riparte dopo un’interruzione. Quella singola colonna ti dice più su un caricamento di dodici gigabyte via VPN di qualsiasi velocità di punta misurata in un test breve.