rsync VPN-en át: újrapróbálkozás, amely újrahasznosítja a megszakadt átvitelt

A feltöltés megakad egy tizenkét gigabájtos archívum négy gigabájtjánál, és a letöltéskezelőktől tanult szokás azt mondja, hogy nyomd meg a folytatást. Az rsync nem folytatja a TCP-folyamot, mert az a folyam eltűnt az alagút utolsó újraküldésével. Amit tehet, hogy megtartja a már megkapott bájtokat, és alapként használja őket a következő próbálkozáshoz, ami egy másik mechanizmus, más szabálykészlettel. A választott kapcsolók döntik el, hogy ez az újrafelhasználás egyáltalán megtörténik-e.

Az újrapróbálkozás állapotot épít újra, nem folytatja a folyamot

Amikor az SSH-munkamenet megszakad, a távoli oldalon csak az marad, amit sikerült a lemezre írnia, és semmi más. Nincs munkamenet-token, amihez újra csatlakozni lehetne, és nincs sorszám, amit újra le lehetne játszani. A következő futás új kapcsolatot nyit, újraolvassa a forrást, és megkérdezi a fogadót, mi van már nála.

Ez az utolsó kérdés magyarázza, miért érdemes megtartani egy részleges fájlt. A fogadó példánya ad valamit az rsyncnek, amihez hasonlíthat, és az algoritmus csak azokat a különbségeket küldi el, amelyeket fel tud ismerni. Ez még mindig új metaadat-átvitel és új végigolvasás a forráson, ezért a megtakarított idő arányos azzal, hogy a fájl mekkora része egyezik, nem azzal, hogy meddig jutott az előző kapcsolat. Ha a fogadó semmit nem tartott meg, a következő próbálkozás teljes másolat, akárhány gigabájtot mozgatott is az első.

Döntse el, hol lakik az újrahasznosítható töredék

Az alapértelmezett viselkedés a részleges fájlt a célútvonalra írja, ami a félig megírt archívumot a végleges néven teszi láthatóvá. A --partial-dir egy Ön által választott könyvtárba mozgatja, és a kézikönyv ezt a könyvtárat úgy írja le, mint amelyet egy későbbi átvitel adatként való felhasználásra megőriz. A relatív név a célkönyvtár alatt oldódik fel, ami pontosan az, amit akkor szeretne, ha a két vég elrendezése eltérő lehet.

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

A sorrend a célon is számít: a részleges könyvtárnak elég hely kell a töredéknek, és a kötetnek elég hely kell a befejezett fájlnak is. A célkötet félig tele írása az átvitel közben olyan hibát okoz, amely hálózati problémának látszik, de nem az, és a megőrzött töredéket csonkán hagyhatja. Ellenőrizze a szabad helyet a fogadó hoszton a futás előtt, ne azután, hogy elhasalt. Néhány másodperc a df -h paranccsal ugyanazon az SSH-útvonalon a terv lehető legolcsóbb próbája.

Az engedélyek kisebb, de valós aggodalom. Egy részleges könyvtár, amelybe nem kapcsolódó fiókok írhatnak, lehetővé teszi, hogy valaki más helyettesítse azt a tartalmat, amelyet a következő futás már megkapottként kezel. Tartsa az átviteli fiók tulajdonában, és ne tegye olyan helyre, ahonnan más szolgáltatások publikálnak.

Ugyanazt a másolatot futtassa, ne egy okosabbat

Az újrafelhasználás csak akkor érvényes, ha a forrás és a cél továbbra is ugyanazt az objektumot írja le. Ugyanaz az útvonal, ugyanaz a név, ugyanaz a fájl. A forrás átnevezése vagy egy másik célkönyvtárra mutatás új összehasonlítást kezd semmi hasznos ellenében.

Ne adja hozzá a --whole-file kapcsolót, miközben a delta-viselkedésre számít. Ez a kapcsoló azt mondja az rsyncnek, hogy az egész fájlt a gördülő ellenőrzőösszeg összehasonlítása nélkül másolja, ami gyors helyi kapcsolaton ésszerű választás, és pontosan a rossz egy sikertelen nagy távolságú feltöltés után. A --inplace is megváltoztatja a történetet: közvetlenül a célfájlba ír, így a megszakítás olyan fájlt hagy, amely régi és új tartalmat kever, külön töredék nélkül, amire vissza lehetne esni.

A folyamatjelző sor az átvitel összesített előrehaladását jelenti. Ez nem befejezési jelzés. Egy szám, amely száz százalékot ér el, miközben a kapcsolat még nyitva van, azt jelenti, hogy az adatokat átnyomták, nem azt, hogy a fogadó átnevezett, szinkronizált vagy elfogadott valamit.

Csak akkor fogadja el az objektumot, ha egyezik

Először erősítse meg a kilépési állapotot, majd hasonlítsa össze az eredményt ahelyett, hogy a hibák hiányában bízna. A méretellenőrzés a legtöbb csonkolt átvitelt elkapja; az ellenőrzőösszeg-összehasonlítás a többit, és mindkettő olcsó a feltöltés újrafuttatásához képest.

Ha az archívumot egy alsóbb folyamat teszi közzé, várja meg az a folyamat az elfogadott fájlt. A megőrzött töredék, amely a végleges néven egy figyelt könyvtárba kerül, a következő vizsgálat áldozatává válik, és a fogyasztó hibája a sérült bemenetről szól, nem egy átvitelről, amely soha nem fejeződött be.

Hagyja békén a forrást, amíg a fogadó meg nem erősíti. Az archívum próbálkozások közötti újragenerálása megváltoztatja az összehasonlítás alapját, és a következő futás vagy szinte mindent átvisz, vagy olyan fájlt készít, amely sem a régi, sem az új forrással nem egyezik.

Amikor a kapcsolat, nem a kapcsoló a határ

A fejléc- és protokoll-többlet az átvitel egyik költsége, és ritkán ez dönti el, mennyi ideig tart egy nagy fájl. Az újraindítási viselkedés többet számít: egy módszer, amely kézi lépések nélkül túléli a megszakadást, hamarabb ad használható fájlt, mint egy gyorsabb módszer, amelynek újra kell kezdenie. A tárhely mindkét végén és a hitelesítési útvonal ugyanabba az összehasonlításba tartozik.

Hasonlítsa össze az engedélyezett alternatív útvonalakat ugyanazzal a fájllal és ugyanazzal a céllal, és jegyezze fel, honnan indul újra mindegyik egy megszakítás után. Az az egyetlen oszlop többet mond a VPN-en átmenő tizenkét gigabájtos feltöltésről, mint bármely rövid tesztben mért csúcssebesség.