rsync över VPN: ett nytt försök som återanvänder den avbrutna överföringen

Din uppladdning stannar vid fyra gigabyte av ett arkiv på tolv gigabyte, och vanan från nedladdningshanterare säger att du ska trycka återuppta. rsync återupptar inte TCP-strömmen, eftersom den strömmen försvann med tunnelns sista omsändning. Vad den kan göra är att behålla de byte den redan har tagit emot och använda dem som grund för nästa försök, vilket är en annan mekanism med en annan uppsättning regler. De flaggor du väljer avgör om den återanvändningen sker över huvud taget.

Det nya försöket bygger upp tillstånd, det återupptar inte strömmen

När SSH-sessionen faller finns bara det som hann skrivas till disk kvar på fjärrsidan, och inget annat. Det finns ingen sessionstoken att knyta an till och inget sekvensnummer att spela upp. Nästa körning öppnar en ny anslutning, läser källan igen och frågar mottagaren vad den redan har.

Den sista frågan är anledningen till att en delvis fil är värd att behålla. Mottagarens kopia ger rsync något att jämföra mot, och algoritmen skickar bara de skillnader den kan identifiera. Det är fortfarande en ny överföring av metadata och en ny genomgång av källan, så den sparade tiden är proportionell mot hur mycket av filen som stämmer, inte mot hur långt den förra anslutningen hade kommit. Om mottagaren inte behöll något är nästa försök en full kopia, hur många gigabyte den första än flyttade.

Bestäm var det återanvändbara fragmentet bor

Standardbeteendet skriver den delvisa filen på målvägen, vilket gör ett halvskrivet arkiv synligt under det slutliga namnet. --partial-dir flyttar den till en katalog du väljer, och handboken beskriver den katalogen som bevarad för att användas som data av en senare överföring. Ett relativt namn löses under målkatalogen, vilket är precis vad du vill när de två ändarna kan ha olika layouter.

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

Ordningen spelar roll på målet också: den delvisa katalogen behöver tillräckligt med plats för fragmentet, och volymen behöver tillräckligt med plats för den färdiga filen också. Att fylla målvolymen mitt i överföringen ger ett fel som ser ut som ett nätverksproblem men inte är det, och det kan lämna det bevarade fragmentet avkortat. Kontrollera ledigt utrymme på mottagarvärden innan körningen börjar, inte efter att den misslyckats. Några sekunder med df -h över samma SSH-väg är det billigaste möjliga testet av planen.

Behörigheter är en mindre men verklig oro. En delvis katalog som orelaterade konton kan skriva i låter någon annan ersätta innehåll som din nästa körning kommer att behandla som redan mottaget. Håll den ägd av överföringskontot, och lägg den inte där andra tjänster publicerar från.

Kör samma kopia, inte en smartare

Återanvändningen gäller bara när källan och målet fortfarande beskriver samma objekt. Samma väg, samma namn, samma fil. Att byta namn på källan eller peka på en annan målkatalog startar en ny jämförelse mot ingenting användbart.

Lägg inte till --whole-file medan du förväntar dig deltabeteendet. Det alternativet säger åt rsync att kopiera hela filen utan jämförelsen med rullande kontrollsumma, vilket är ett rimligt val på en snabb lokal länk och precis fel efter en misslyckad långdistansuppladdning. --inplace ändrar också historien: det skriver direkt i målfilen, så ett avbrott lämnar en fil som blandar gammalt och nytt innehåll utan ett separat fragment att falla tillbaka på.

Förloppsraden rapporterar sammanlagt förlopp för överföringen. Det är inte en färdigsignal. En siffra som når hundra procent medan anslutningen fortfarande är öppen betyder att data har skjutits ut, inte att mottagaren har bytt namn, synkat eller accepterat något.

Acceptera objektet först när det stämmer

Bekräfta först utstatus, jämför sedan resultatet i stället för att lita på att inga fel finns. En storlekskontroll fångar de flesta avkortade överföringar; en kontrollsummejämförelse fångar resten, och båda är billiga jämfört med att köra uppladdningen igen.

Om arkivet publiceras av en nedströms process, låt den processen vänta på den accepterade filen. Ett bevarat fragment som landar i en bevakad katalog under det slutliga namnet plockas upp av nästa genomsökning, och konsumentens fel kommer att handla om skadad indata och inte om en överföring som aldrig blev klar.

Låt källan vara tills mottagaren bekräftar. Att återskapa arkivet mellan försök ändrar jämförelsebasen, och nästa körning antingen överför nästan allt eller producerar en fil som varken passar den gamla eller den nya källan.

När länken, inte flaggan, är gränsen

Overhead för header och protokoll är en kostnad för en överföring, och det är sällan den som avgör hur lång tid en stor fil tar. Omstartsbeteende betyder mer: en metod som överlever ett avbrott utan manuella steg levererar en användbar fil tidigare än en snabbare metod som måste börja om. Lagring i båda ändar och autentiseringsvägen hör till samma jämförelse.

Jämför tillåtna alternativa vägar med samma fil och samma mål, och notera var var och en startar om efter ett avbrott. Den enda kolumnen säger dig mer om en uppladdning på tolv gigabyte över ett VPN än någon topphastighet som mätts i ett kort test.