Rsync: jaká volba pro bezchybný přesun souboru po síti

[Honza1Ubuntu]

Prenos souboru mezi soubory delam pomoci rsync. Kdyz pouziju volbu -ahvc tak c znamena, ze se obsahy souboru ve zdroji a v cili porovnavaji pomoci kontrolnich souctu, ne podle datumu posledni zmeny. Kdyz dam jen -ahv znamena, ze se soubory ve zdroji-cili porovnavaji podle datumu posledni zmeny, co se ma aktualizovat, a co ne.

Otazkou ale je, zdali pri samotnem presnosu po siti ma vliv volba -ahv vs. -ahvc na spranost prenosu dat. (jestli c, jez pocita ve zdroji a cili kontrolni soucty, kontroluje pomoci kontrolnich souctu i spravnost prenosu po siti pri zapisu do cilove slozky).

Zdroj a cil je na jinem serveru, takze prenos je po siti.

[Reklama]

[_Jenda]

Kód: [Vybrat]

       --checksum, -c
(...)
              Note that rsync always verifies that each transferred  file  was
              correctly  reconstructed  on  the  receiving  side by checking a
              whole-file checksum that is generated  as  the  file  is  trans‐
              ferred,  but  that automatic after-the-transfer verification has
              nothing to do with this option's before-the-transfer "Does  this
              file need to be updated?" check.


[TWVzc2E]

Tak ten rsync spusť prostě dvakrát?

[turista-]

Tak ten rsync spusť prostě dvakrát?

I když se při druhém běhu nic nepřenáší, tak znovu spočítat checksum na obou stranách chvíli trvá a zatěžuje systém. Tak proč to dělat, pokud je to zbytečné.

[Ondrej Nemecek]

Takže dotaz zní, zda je rsync protokol odolný proti poškození dat během síťového přenosu, případně během čtení či zápisu na disk? Bude asi záležet na přenosovém médiu - já většinou přenáším přes ssh a navíc s kompresí a tam bych automaticky čekal kontrolní součty a tedy jistotu bezchybného přenosu. Že by ovšem rsync opětovným čtením kontroloval, že se na disk zapsalo to, co se zapsat mělo, o tom bych si dovolil pochybovat.

[Reklama]

[aaa158]

Takže dotaz zní, zda je rsync protokol odolný proti poškození dat během síťového přenosu, případně během čtení či zápisu na disk? Bude asi záležet na přenosovém médiu - já většinou přenáším přes ssh a navíc s kompresí a tam bych automaticky čekal kontrolní součty a tedy jistotu bezchybného přenosu. Že by ovšem rsync opětovným čtením kontroloval, že se na disk zapsalo to, co se zapsat mělo, o tom bych si dovolil pochybovat.

Ja myslim ze

Kód: [Vybrat]

man rsync (Jenda) je vcelku jasny:

Note that rsync always verifies that each transferred  file  was correctly  reconstructed  on  the  receiving  side

[Ondrej Nemecek]

Takže dotaz zní, zda je rsync protokol odolný proti poškození dat během síťového přenosu, případně během čtení či zápisu na disk? Bude asi záležet na přenosovém médiu - já většinou přenáším přes ssh a navíc s kompresí a tam bych automaticky čekal kontrolní součty a tedy jistotu bezchybného přenosu. Že by ovšem rsync opětovným čtením kontroloval, že se na disk zapsalo to, co se zapsat mělo, o tom bych si dovolil pochybovat.

Ja myslim ze

Kód: [Vybrat]

man rsync (Jenda) je vcelku jasny:

Note that rsync always verifies that each transferred  file  was correctly  reconstructed  on  the  receiving  side

Takže pokud se jednou už přenáší, je zkontrolován jako soubor na disku. Pokud není -c a souhlasí velikosti a časy, není přenášen a tudíž nemusí být nutně stejný. Je to tak?

[Honza1Ubuntu]

Diky, to jsem potreboval vedet. Jestli je ma smysl davat -c nebo poustet rsync 2x i v pripade, ze o (ne)prenosu souboru staci ridit se casem posledni zmeny souboru. -c tedy nema vliv na odolnost proti pozkozeni dat po siti a pri zapisu  v cili. Jenda mi potvrdil presne to co jsem potreboval vedet.

Takže dotaz zní, zda je rsync protokol odolný proti poškození dat během síťového přenosu, případně během čtení či zápisu na disk? Bude asi záležet na přenosovém médiu - já většinou přenáším přes ssh a navíc s kompresí a tam bych automaticky čekal kontrolní součty a tedy jistotu bezchybného přenosu. Že by ovšem rsync opětovným čtením kontroloval, že se na disk zapsalo to, co se zapsat mělo, o tom bych si dovolil pochybovat.

Prave na to jsem se ptal, -c rozhoduje, zdali bude soubor prenesen nebo ne, podle kontrolnich souctu, pokud to tam nedam, tak podle datumu a casu. Zajimalo me, jestli je i v pripade volby BEZ -c rsync odolny proti poskozeni dat pri sitovem prenosu a take zapisu na disk. Protokol take pouzivam ssh, i kvuli bezpecnosti. Parametr pouzivam takto, aby byl vzdy cil stejny jako zdroj:

Kód: [Vybrat]

rsync -ahvc -e ssh --delete --progress ZDROJ CIL

A otazkou je smysl pouzit -c v parametrech, nebo pustit rsync vicekrat, jestli to ma smysl. Pri velkem obemu dat kontrolni soucty uz vyznameji zatezuji system (cteni na disku) ve zdroji a cili, a nejaky cas to trva, az hodiny pri velkem mnozstvi dat. A podle vseho samotne -c a nebo sposteni rsync 2x nezvysi odolnost proti poskozeni pri prenosu po siti nebo zapisu v cili. I kdyz u opravdu dulezitych dat je to mozna lepsi 2x spustit s -c.

[Ondrej Nemecek]

Bez -c se může chybně vyhodnotit nutnost soubor přenášet. S -c se nutnost vyhodnotí na základě checksumu, takže je záruka, že se přenese vše, co se změnilo. Přenos a zápis do souboru se pak provede i s kontrolou konzistence. Takže při -c by nemělo být potřeba zadávat příkaz 2x. Tak tomu rozumím já.

[Honza1Ubuntu]

Bez -c se může chybně vyhodnotit nutnost soubor přenášet. S -c se nutnost vyhodnotí na základě checksumu, takže je záruka, že se přenese vše, co se změnilo. Přenos a zápis do souboru se pak provede i s kontrolou konzistence. Takže při -c by nemělo být potřeba zadávat příkaz 2x. Tak tomu rozumím já.

Taky tomu rozumim tak, ze -c akorat vyhodnocuje pomoci kontrolnich souctu, zdali je nutne soubor prenaset. Bez -c se nutnost prenosu hodnoti podle toho, jestli se shoduje timestamp, jmeno a umisteni souboru. Takze -c odhali soubory s jinym checksumem (tedy i obsahem, byt nepatrne odlisnym), ale se zaludne stejnou casovou znamkou, jmenem i umistenim (jak se neco takoveho stane ?)

Ta kontrola konzistence zapisu v cili a prenosu po siti by snad mela podle vseho probehnout vzdy, nezavisle na -c, tak tomu rozumim.

2x rsync spoustet nejdriv bez -c a pak s -c by snad melo odhalit jen soubory zdanlive stejne (jmeno, cas, umisteni) ale s jinym checksumem. Stejne tak, pustim li rsync jen jednou s -c. Spousteni 2x (podruhe s -c) by odhalilo i chybny zapis s cili, ktery by nemel kvuli kontrole konzistence VZDY nastat.

Pokud je datovy soubor velky (stovky GB) a soubory, ktere se maji prenest jednotky GB, tak samotny prenos muze trvat minuty, kontrola checksumu na obou stranach i par hodin.

[k3dAR]

[...]Takze -c odhali soubory s jinym checksumem (tedy i obsahem, byt nepatrne odlisnym), ale se zaludne stejnou casovou znamkou, jmenem i umistenim (jak se neco takoveho stane ?)

napr. tak:

Kód: [Vybrat]

cp -a soubor soubor.bak
echo "neco" >>soubor
touch -r soubor.bak soubor

[arrange]

...
2x rsync spoustet nejdriv bez -c a pak s -c by snad melo odhalit jen soubory zdanlive stejne (jmeno, cas, umisteni) ale s jinym checksumem. Stejne tak, pustim li rsync jen jednou s -c. Spousteni 2x (podruhe s -c) by odhalilo i chybny zapis s cili, ktery by nemel kvuli kontrole konzistence VZDY nastat.
...

Nepochopil jsem, co znamená "by nemel kvuli kontrole konzistence VZDY nastat", ale co vím, tak rsync NEkontroluje, jestli byl soubor správně ZAPSÁN na disk, ale jestli byl správně přenesen, bez ohledu na volbu -c. Tedy se může stát, že při chybném sektoru na disku v cíli bude cílový soubor jiný, než originál, i když rsync hlásí vše v pořádku.

Pokud ti tedy jde s kontrolu souboru na disku, pak by dávalo smysl spustit rsync s volbou -c dvakrát. Anebo spíš podruhé spustit s variantou "--verbose --dry-run --checksum" a podívat se, jestli má rsync snahu soubor přenášet znova (= checksum výchozího a cílového souboru nesouhlasí).

[Honza1Ubuntu]

Arrange

O to prave jde, spravnost prenosu po siti se resi vzdy pomoci kontrolnich souctu. At uz s -c nebo bez. Ale to tu prave resime, jestli je kontrolovano, zdali jsou spravne i soubory zapsany v cili (spravny zapis na disk, vadne sektory).

Na druhou stranu volba s -c muze prenest poskozeny soubor ze zdroje a prepsat v cili OK soubor, pokud je vadny sektor ve zdroji.

O chybnem zapisu na disk (zmena dat) se tu uz tusim diskutovalo, jestli se to muze stat. S tim ze by to nehlasilo chybu disku a precetl by se ve zdroji nebo zapsal v cili oubor chybne. Otazka je, jak casto, snad se pocita jedna zmena bitu (bit-flip) za X TB nebo dokonce X PB tusim. S urcitou, byt malou pravdepodobnosti se to muze stat jak ve zdroji tak v cili, tak ani spustit po druhe rsync s -c neni stoprocentni.

Pokud v cili nejde neco prepsat-zmenit (zmenit casy, prava, prepsat soubory), protoze napr. uzivatel nema opravneni, tak to rsync hlasi - ze nejde synchronizovat  kompletne a vypise chybu. A jestli kontrolouje i spravnost zapisu na disk v cili pri kazdem behu, to tu resime.

[...]Takze -c odhali soubory s jinym checksumem (tedy i obsahem, byt nepatrne odlisnym), ale se zaludne stejnou casovou znamkou, jmenem i umistenim (jak se neco takoveho stane ?)

napr. tak:

Kód: [Vybrat]

cp -a soubor soubor.bak
echo "neco" >>soubor
touch -r soubor.bak soubor

Presne tak

Jestli je soubor nepatrne, nebo kompletne odlisny, to uz se neresi, checksumy by se mely lisit prakticky vzdy, i pri nepatrne zmene (neni to uplne pravda, ale pravdepodobnost odlisnych souboru se stejnym checksumem je naprosto minimalni).

Pri beznem provozu, praci a zalohovani me nenapadlo, jak by se to mohlo stat.  Ale pokud nekdo bude ve zdroji nebo cili delat nepravosti a umyslne skodit, tak to mozne je. Nedopatrenim se to taky muze stat pri zpracovani dat, ale ne uplne snadno.

[arrange]

... A jestli kontrolouje i spravnost zapisu na disk v cili pri kazdem behu, to tu resime.

Nekontroluje.

Pri beznem provozu, praci a zalohovani me nenapadlo, jak by se to mohlo stat.

Mně se to stalo na Raspberry Pi - systém (Raspbian) se choval divně, a díky tomu, že jsem ho zálohoval přes rsync BEZ varianty -c, tak jsem měl k dispozici nepoškozenou kopii, díky které jsem zjistil, že se mi náhodně mění celé bloky dat na RPi. V syslogu žádné chyby disku, rsync taky nehlásil žádné chyby. Memtest v pořádku, dal jsem tam jinou SD kartu, přeinstaloval systém, nic nepomohlo.

Vyřešeno až reklamací celé Maliny. Díky záloze (bez -c!) jsem o nic nepřišel.

[Honza1Ubuntu]

arrange

... A jestli kontrolouje i spravnost zapisu na disk v cili pri kazdem behu, to tu resime.
Urcite nekontroluje bez -c kontrolni soucty zdroj-cil u souboru, ktere se neprenasi - jmeno a timestamp zdroj-cil souhlasi, tak se ty soubory neresi. Ale jestli kontroluje spravnost zapisu na disk prenasenych souboru ? Urcite kontroluje spravnost prenosu po siti. Kontrolni soucty pak by mel kontrolovat nejmene sam proces zapisu na HDD.

Az takhle jo, to se ti fakt menil obsah souboru, to velke zmeny, nebo jen zmeny par bajtu ?

Ja pouzivam klasicky HDD na notasu, popr. extreni HDD. Zatim se mi to nikdy nestalo - zmena dat bez toho, aby to hodilo chybu cteni-zapisu. Kdyz se zacal podelavat disk a byla chyba cteni-zapisu, tak se to cele hodilo do read-only, nebo proste soubor nejde precist. Zatim jsem nezazil ODHALENOU zmenu dat na HDD. U archivu napriklad i mala zmena odrovna cely archiv, u textu, obrazku, videa malou zmenu nepoznas. Zmenu bit jen jednoho bajtu ve skriptu nemusime rozebirat, muze udelat paseku:

Kód: [Vybrat]

cd ${cesta}
rm -fr *

nebo

Kód: [Vybrat]

cd ${cista}
rm -fr *

HDD, SDD, USB klice by meli mit pri cteni-zapisu kontrolni soucty, ktere odhali vadny sektor a chybny zapis-cteni, tedy pozkozena data (data corrupt). Nechytnou ale vsechno, pri velkem mnozstvi dat se obcas bit-flip (zmena bajtu-bitu) obevi. Snad jednou za X stovek GB jsem nasel. SD karty snad ani tyto kontrolni soucty nemaji (nebo jiny mechanizmus nemaji), nebo jsou ty kontrolni soucty maji SD karty slabsi bych spis rekl. To uz je ale mimo rsync.

Verze s -c ochrani-odhali spatne soubory v cili (podelany disk), bez -c neprenese podelane soubory ve zdroji a v cili zustanou spravne. Ale Pri vadnem sektoru by se mela ozvat chybn hlaska ze nejde cist-zapisovat, pri chybnem zapisu se disk hodni do read-only a stop. NE zapsat jina data.