rsync prin VPN: o nouă încercare care reutilizează transferul întrerupt
Un tunel căzut încheie conexiunea, nu datele. Păstrează fragmentul cu --partial-dir, rulează din nou aceeași copie și verifică fișierul înainte de a-l publica.
Încărcarea ta se blochează la patru gigabaiți dintr-o arhivă de doisprezece gigabaiți, iar obiceiul învățat de la managerii de descărcare spune să apeși reia. rsync nu va relua fluxul TCP, pentru că acel flux a dispărut odată cu ultima retransmisie a tunelului. Ce poate face este să păstreze octeții deja primiți și să-i folosească drept bază pentru următoarea încercare, ceea ce este un alt mecanism cu alt set de reguli. Opțiunile pe care le alegi decid dacă această reutilizare are loc deloc.
Noua încercare reconstruiește starea, nu reia fluxul
Când sesiunea SSH cade, la capătul îndepărtat rămâne doar ce a apucat să scrie pe disc, și nimic altceva. Nu există nici un token de sesiune la care să te reapuci și nici un număr de secvență de redat. Următoarea rulare deschide o conexiune nouă, recitește sursa și întreabă receptorul ce are deja.
Ultima întrebare este motivul pentru care merită păstrat un fișier parțial. Copia receptorului îi dă lui rsync ceva cu care să compare, iar algoritmul trimite doar diferențele pe care le poate identifica. Este totuși un transfer nou de metadate și o nouă trecere peste sursă, așa că timpul economisit este proporțional cu cât din fișier se potrivește, nu cu cât de departe ajunsese conexiunea anterioară. Dacă receptorul nu a păstrat nimic, următoarea încercare este o copie completă, indiferent câți gigabaiți a mutat prima.
Decide unde locuiește fragmentul reutilizabil
Comportamentul implicit scrie fișierul parțial pe calea de destinație, ceea ce face vizibilă o arhivă scrisă pe jumătate sub numele final. --partial-dir îl mută într-un director ales de tine, iar manualul descrie acel director ca păstrat pentru a fi folosit ca date de un transfer ulterior. Un nume relativ este rezolvat sub directorul de destinație, exact ceea ce vrei când cele două capete pot avea dispuneri diferite.
rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
large-archive.bin [email protected]:/srv/incoming/
Ordinea contează și la destinație: directorul parțial are nevoie de spațiu suficient pentru fragment, iar volumul are nevoie de spațiu suficient și pentru fișierul finalizat. Umplerea volumului țintă la mijlocul transferului produce o eroare care pare o problemă de rețea dar nu este, și poate lăsa fragmentul păstrat trunchiat. Verifică spațiul liber pe gazda receptoare înainte de începerea rulării, nu după ce eșuează. Câteva secunde cu df -h pe aceeași cale SSH este cel mai ieftin test posibil al planului.
Permisiunile sunt o grijă mai mică dar reală. Un director parțial în care conturi nelegate pot scrie permite altcuiva să înlocuiască conținut pe care următoarea ta rulare îl va trata ca deja primit. Ține-l în proprietatea contului de transfer și nu îl pune acolo de unde publică alte servicii.
Rulează aceeași copie, nu una mai deșteaptă
Reutilizarea se aplică numai când sursa și destinația descriu încă același obiect. Aceeași cale, același nume, același fișier. Redenumirea sursei sau indicarea altui director de destinație începe o comparație nouă cu nimic util.
Nu adăuga --whole-file în timp ce aștepți comportamentul delta. Acea opțiune îi spune lui rsync să copieze întregul fișier fără comparația sumei de control glisante, ceea ce este o alegere rezonabilă pe o legătură locală rapidă și exact cea greșită după o încărcare eșuată pe distanță lungă. --inplace schimbă și el povestea: scrie direct în fișierul de destinație, așa că o întrerupere lasă un fișier care amestecă conținut vechi și nou fără un fragment separat pe care să te retragi.
Linia de progres raportează progresul agregat al transferului. Nu este un semnal de finalizare. Un număr care ajunge la o sută la sută în timp ce conexiunea este încă deschisă înseamnă că datele au fost împinse, nu că receptorul a redenumit, sincronizat sau acceptat ceva.
Acceptă obiectul doar după ce se potrivește
Confirmă mai întâi starea de ieșire, apoi compară rezultatul în loc să te bazezi pe absența erorilor. O verificare a dimensiunii prinde majoritatea transferurilor trunchiate; o comparație de sume de control prinde restul, și ambele sunt ieftine față de reluarea încărcării.
Dacă arhiva este publicată de un proces din aval, pune acel proces să aștepte fișierul acceptat. Un fragment păstrat care ajunge sub numele final într-un director supravegheat este preluat de următoarea scanare, iar eroarea consumatorului va fi despre intrare coruptă și nu despre un transfer care nu s-a terminat niciodată.
Lasă sursa în pace până când receptorul confirmă. Regenerarea arhivei între încercări schimbă baza de comparație, iar următoarea rulare fie transferă aproape tot, fie produce un fișier care nu se potrivește nici cu sursa veche, nici cu cea nouă.
Când limita este legătura, nu opțiunea
Supraîncărcarea antetului și a protocolului este un cost al transferului și rareori este cel care decide cât durează un fișier mare. Comportamentul la repornire contează mai mult: o metodă care supraviețuiește unei căderi fără pași manuali livrează un fișier utilizabil mai devreme decât o metodă mai rapidă care trebuie să înceapă din nou. Stocarea la ambele capete și calea de autentificare fac parte din aceeași comparație.
Compară căile alternative permise cu același fișier și aceeași destinație și notează de unde reia fiecare după o întrerupere. Acea singură coloană îți spune mai multe despre o încărcare de doisprezece gigabaiți printr-un VPN decât orice viteză de vârf măsurată într-un test scurt.