Hatékony, biztos másolás hálózaton

Fórumok

Sziasztok!

Szeretném az ötleteiteket, segítségetek kérni, abban, hogy miként tudok biztosan ellenőrzötten másolni fájlokat.

Adott egy nagy cég, sok telephellyel. Minden telephelyen van 10-15 mérőgép(Suse) illetve egy telephelyi gyűjtő szerver(Red Hat 6.8), a központban pedig egy nagy gyűjtő szerver(CentOS 7).

Hogy miért más disztrik abba ne menjünk bele... :)

A mérő gépek küldenek néhány, 2-3 MB-os fájlokat naponta, akár többször a telephelyi gyűjtő szervernek, majd onnan éjjel átmásolódnak a központi budapesti nagy gyüjtő szerverre, értelem szerűen az összes telephelyről.

Szóval a probléma az, hogy kimaradnak fájlok a telephelyi és a központi gyűjtő szerver között. scp-vel másolok.

A telephelyek és a központ között 30Mbit bérelt vonal van. Lokálisan a mérőgépek és a telephelyi szerver között a hálózat gigabit, ott nem fordul elő msolási hiba.

Ötletként első körben arra gondoltam, hogy a telephelyi gyűjtő szerveren becsomagolom az összes fájl egy fájlba és azt küldöm be a központba neten keresztül, a központba pedig kicsomagolom.

Van egyéb ötletetek erre esetleg?
Köszönöm!

Hozzászólások

Szóval a probléma az, hogy kimaradnak fájlok a telephelyi és a központi gyűjtő szerver között. scp-vel másolok.

gondolom nem kézzel másolgatod, hanem valami script csinálja... ettől erősen függ a dolog :)

 

- pontosan mit jelent az hogy kimaradnak?

- van hibaüzenet másolás közben?

- hogy veszed észre hogy kimaradt valami?

Így van, itt feltehetőleg nem az scp és esetleges hálózati hiba van, hanem valami más, akár jogosultságprobléma pl.

Ezt stílusosan olyan scripttel illene csinálni, ami logolja, hogy épp mit csinált, a meghívott scp (de lehet rsync is) logjait is szépen összeszedi. Ezekből elég sokminden kiderülne. Az is ha mégis átviteli hiba akad. Mi több, azt meg a scriptből le is lehet kezelni.

szerintem a script ismerete (és a kérdésemre adott válaszok) nélkül nem tudunk rajtad segíteni.

 

 Akkor szerintetek az lenne a biztos, hogy először másolás majd egy rsync-el végigpásztázni, hogy minden átment -e?

ilyen itt nem hangzott el, és nincs is túl sok értelme...

Ha rsync-et használsz nem kell előtte más 'copy', mert értelmetlen.

 

szerintem.

Szerkesztve: 2021. 03. 11., cs – 11:51

Ameddig kicsik a számok a hálózati sávszélhez képest, addig én is rsync-et csinálnék. Az rsync hátránya, hogy az éppen nem új historikus fájlok is viszik az erőforrást, mennél több van annál többet, mert mindig végig kell néznie, hogy megvan-e a másolat a másik oldalon. (Amennyire tudom, nem vagyok az rsync szakértője.)

Ha korlátozod az rsync-elt folder méretét, akkor nem lesz skálázódási gondod. De lehet, hogy korlátozás nélkül is annyira soká lenne ebből gond, hogy praktikusan nem számít.

Egyébként meg elvben ha belegondolsz a logok sorban keletkeznek, mindet el kell küldeni sorban és nem szabad kihagyni belőle: logikailag tehát egy üzenetsorról beszélünk, amit megbízhatóságot garantáló message queue-val lehet testhezállóan megvalósítani. Vannak ilyen MQ-k, amiket telepítesz, bokonfolsz és garantálja, hogy egy üzenet (ami egy fájl az esetedben) pontosan egyszer megy át. Ez volna erőforrás szempontból az optimális, de ameddig az rsync elviszi, addig felesleges komplikálni.

Ja, és ha MQ-t csinálnál, akkor azzal már érdemes egyből online-ra konfigurálni a rendszert, azaz nem napi egy mentés volna, hanem folyamatosan azonnal menne a mentendő adat a központba.

A kérdés az, hogy sikeres feltöltsé után törölhető-e helyben a fájl, mert ha igen, akkor a --remove-source-files kapcsolóval ez is "pipa" (ha biztosra akar menni, akkor egy szimpa rsync elsőször, aztán ha a $?=0, akkor mehet --remove-source-files kapcsolóval ismét), illetve ha egy már felküldött fájl nem változik lokálisan, akkor a --ignore-existing csak addig foglalkozik vele, amíg megnézi, hogy létezik-e a receiver oldalon, utána a tartalmával már nem.

Szerkesztve: 2021. 03. 11., cs – 12:13

Esetleg (s)ftp és a másolás után a script-ből átnevezés és md5 létrehozása mellé. Innen lehetne tudni, hogy a script végig lefutott, nem szakadt meg. Opcionálisan lehetne az md5-öt nézni.

Nyilván csak akkor járható, ha tényleg nincs túl sok file.

Az nem lehet, hogy a kimaradó fájlok exclusive lockkolva vannak mert valami ír éppen bele?

Torrent? Azaz  Bittorrent sync? Azaz resilio sync?

 

Ha valami odakerül és lockolva can, ha vége a locknak, akkor majd elmásolódik.

Az rsync a legegyszerubb valoban. Egyszer atnezed a parameterezeset, beallitod, beteszed egy scriptbe, es el is felejtheted, hogy ott van. A telefonomon (ehhez megfelelo eroforrasokkal) a 256GB-os SD kartyat szinkronizalja egy script a desktop gepemre, problema nelkul (laptoprol is, de az kevesbe erdekes, van eroforrasa). Szerintem pont eroforraskimelesben eros nagyon az rsync.

A strange game. The only winning move is not to play. How about a nice game of chess?

Szerintem pont eroforraskimelesben eros nagyon az rsync.

szerintem ez csak a hálózatra igaz, a diszk I/O-ra korántsem

Van egy kirívó esetem, a laptopomat (is) rendszeresen rsyncelem a NAS-ra, és megfigyeltem, hogy kb 10 perccel tovább tart a teljes munka, ha a virtuális windows diszkje változott az utolsó futás óta, ezért az rsync előtt kiadok egy törlést a NAS-on, és gigabites hálón gyorsan áttolja az image-t. Nem mellesleg így nem kell +100 GB ideiglenes hely a NAS-on.

a.: ha fontos, akkor érdemes tolni rá egy tesztet, hogy miért. Gyanús, hogy a NAS egyszerre olvassa a régi fájlt, és írja az újat, ami ugye tipikusan nem szokott őrülten gyors lenni, illetve:

b.: man rsync, inplace, és lehet hogy meg van oldva a probléma.

c.: a forrás sparse file, mondjuk 400G, amiből 40 van használva. Másoláskor sparse file-t másol, az rsync meg a teljeset, man rsync, sparse (plusz ugye az inplace)

d.: passz.

A 100 GB-os virt.gép diszk bitlockerrel van titkosítva, így pár nap munka után kb minden blokkja meg lett változtatva, ezért az eredeti fájlból alig tud felhasználni valamit, na meg nem csak ez az egyetlen funkciója a NAS-nak. Kösz az inplace tippet, rá fogok keresni.

Szoval ha jol ertem, az rsync nalad gyenge vason lassan masol - tenylegesen - 100GB-os file-okat. Hat jo, oke. Esetleg a VM-en is futtathatsz rsyncet a szukseges file-okra, az image-et meg exclude-olhatod, ha ennyire megterhelo a gepnek.

Nalam nem valtozik egyszerre ennyi adat, szoval nincs ilyen problemam.

A strange game. The only winning move is not to play. How about a nice game of chess?

Nem mondtam, hogy megterhelő, azt állítottam (mérések alapján), hogy ha a kliens gigabites hálózaton van, és ha nagy a másolandó fájl (100 GB nálam), és sok változás történt azon a nagy fájlon (bitlockeres windows hdd image), akkor sokkal hamarabb kész a teljes laptop rsyncelése, ha előtte törlöm a NAS-on azt az egy nagy fájlt.

Igazság szerint ugye régi esetén se kell, elég megmondani neki, hogy öcsi, csak a dátumot nézd. Ezzel persze az összes vélt előnyét elveszti, de ezek a dolgok úgy néz ki, hogy az adott esetben inkább hátrányok. Szóval le lehet butítani kb. a cp szintjére, és mégis gyorsabb lesz. Persze a kérdés akkor az, hogy minek az rsync :D.

Szerkesztve: 2021. 03. 13., szo – 14:52

rsync --checksum parameterrel. Ha nem kell a forras, akkor  --remove-source-files

 

Teljesen paranoid hozzaallashoz ez az ajanlott :)

 

rsync -avr --checksum --ignore-times source destination

 

A resilio sync is jo otlet, ugye  atorrent protokoll alapbol checksumol, mar csak a felepitese miatt is.