rsync over VPN: een nieuwe poging die de afgebroken overdracht hergebruikt

Je upload blijft steken bij vier gigabyte van een archief van twaalf gigabyte, en de gewoonte van downloadbeheerders zegt dat je op hervatten drukt. rsync hervat de TCP-stroom niet, want die stroom is verdwenen met de laatste hertransmissie van de tunnel. Wat het wel kan, is de bytes die het al heeft ontvangen bewaren en ze als basis voor de volgende poging gebruiken, wat een ander mechanisme met een andere set regels is. De flags die je kiest bepalen of die hergebruik überhaupt plaatsvindt.

De nieuwe poging bouwt toestand op, hij hervat de stroom niet

Wanneer de SSH-sessie wegvalt, blijft aan de andere kant alleen over wat er naar schijf is weggeschreven, en niets anders. Er is geen sessietoken om weer aan te haken en geen volgnummer om opnieuw af te spelen. De volgende run opent een nieuwe verbinding, leest de bron opnieuw en vraagt de ontvanger wat die al heeft.

Die laatste vraag is de reden waarom een deelbestand het waard is om te bewaren. De kopie van de ontvanger geeft rsync iets om mee te vergelijken, en het algoritme stuurt alleen de verschillen die het kan herkennen. Het blijft een nieuwe overdracht van metadata en een nieuwe doorgang over de bron, dus de bespaarde tijd is evenredig met hoeveel van het bestand overeenkomt, niet met hoe ver de vorige verbinding was gekomen. Als de ontvanger niets heeft bewaard, is de volgende poging een volledige kopie, hoeveel gigabyte de eerste ook heeft verplaatst.

Bepaal waar het herbruikbare fragment woont

Het standaardgedrag schrijft het deelbestand op het doelpad, waardoor een half geschreven archief onder de definitieve naam zichtbaar wordt. --partial-dir verplaatst het naar een map naar keuze, en de handleiding beschrijft die map als bewaard om door een latere overdracht als data te worden gebruikt. Een relatieve naam wordt onder de doelmap opgelost, wat precies is wat je wilt wanneer de twee kanten verschillende indelingen kunnen hebben.

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

Ook aan de doelkant is de volgorde belangrijk: de partiële map heeft genoeg ruimte nodig voor het fragment, en het volume heeft ook genoeg ruimte nodig voor het voltooide bestand. Het doelvolume midden in de overdracht vullen levert een fout op die op een netwerkprobleem lijkt maar het niet is, en het kan het bewaarde fragment afgekapt achterlaten. Controleer vrije ruimte op de ontvangende host voordat de run begint, niet nadat die is mislukt. Een paar seconden met df -h over hetzelfde SSH-pad is de goedkoopst mogelijke test van het plan.

Rechten zijn een kleinere maar echte zorg. Een partiële map waarin onbetrokken accounts kunnen schrijven, laat iemand anders inhoud vervangen die je volgende run als al ontvangen behandelt. Houd hem in eigendom van het overdrachtsaccount, en zet hem niet waar andere diensten publiceren.

Draai dezelfde kopie, niet een slimmere

Het hergebruik geldt alleen wanneer de bron en het doel nog hetzelfde object beschrijven. Hetzelfde pad, dezelfde naam, hetzelfde bestand. De bron hernoemen of naar een andere doelmap wijzen begint een nieuwe vergelijking tegen niets nuttigs.

Voeg --whole-file niet toe terwijl je het deltagedrag verwacht. Die optie zegt rsync het hele bestand te kopiëren zonder de vergelijking van rollende checksums, wat een redelijke keuze is op een snelle lokale verbinding en precies de verkeerde na een mislukte langeafstands-upload. --inplace verandert het verhaal ook: het schrijft direct in het doelbestand, dus een onderbreking laat een bestand achter dat oude en nieuwe inhoud mengt zonder een apart fragment om op terug te vallen.

De voortgangsregel meldt de totale voortgang van de overdracht. Het is geen voltooiingssignaal. Een getal dat honderd procent bereikt terwijl de verbinding nog open is, betekent dat de gegevens zijn geduwd, niet dat de ontvanger iets heeft hernoemd, gesynchroniseerd of geaccepteerd.

Accepteer het object pas als het overeenkomt

Bevestig eerst de exitstatus en vergelijk dan het resultaat in plaats van te vertrouwen op de afwezigheid van fouten. Een groottecontrole vangt de meeste afgekapte overdrachten; een checksumvergelijking vangt de rest, en beide zijn goedkoop vergeleken met de upload opnieuw draaien.

Als het archief door een stroomafwaarts proces wordt gepubliceerd, laat dat proces dan wachten op het geaccepteerde bestand. Een bewaard fragment dat onder de definitieve naam in een bewaakte map belandt, wordt door de volgende scan opgepikt, en de fout van de consument gaat over beschadigde invoer en niet over een overdracht die nooit is afgerond.

Laat de bron met rust tot de ontvanger bevestigt. Het archief tussen pogingen opnieuw genereren verandert de vergelijkingsbasis, en de volgende run draagt ofwel bijna alles over ofwel levert een bestand op dat noch bij de oude noch bij de nieuwe bron past.

Wanneer de verbinding, niet de flag, de grens is

Header- en protocoloverhead is één kostenpost van een overdracht, en het is zelden diegene die bepaalt hoe lang een groot bestand duurt. Herstartgedrag telt zwaarder: een methode die een onderbreking overleeft zonder handmatige stappen, levert eerder een bruikbaar bestand dan een snellere methode die opnieuw moet beginnen. Opslag aan beide kanten en het authenticatiepad horen in dezelfde vergelijking.

Vergelijk toegestane alternatieve paden met hetzelfde bestand en dezelfde bestemming, en noteer waar elk na een onderbreking opnieuw begint. Die ene kolom vertelt je meer over een upload van twaalf gigabyte via een VPN dan welke pieksnelheid dan ook die in een korte test is gemeten.