Mennyire fail-safe az rsync?

Segédprogramok

Adott egy sokmillio kismeretu allomanyt tartalmazo fajlrendszer, amirol celszeruen es jelenleg rsync -el vegzek szinkronizalast (nyilvan ez nem lesz egzakt, mert 4-5 napig teker szerencsetlen, a source pedig kis mertekben, de kap irast).
Eddig meg nem probaltam, de hatha van mar tapasztalat: mi tortenik, ha fajlrendszer hiba lep fel source oldalon, mikozben en --delete kapcsoloval futtatom az rsync -et? Elvileg el kell hasalnia, de valoban ez tortenik?

( _ventura_ v | 2021. 03. 29., h – 13:17 )

rsync veszett lassu mar sok millio filenal :/ Probáld meg a burp ot, igaz akkor burp el is lehet visszaallitani, majd a kivant filet.

Fedora 40, Thinkpad x280

Itt az a nagy problema, hogy abandoned projektek feltoltesei mennek ide, tehat nem is tudok +1 feltoltest interpretalni a "kliens" oldalon, ugyanakkor szukseges lehet a kiszolgalas is a masik oldalon.

Most, hogy ezt leirtam, eszembe jutott, hogy bind -olhatok egy eventet a befejezett FTP folyamatra  (belso halon/VPN -en megy, keretik nem tulzottan elkepedni :)), majd ezzel mar a tulparton egyesevel is meg tudom csinalni a modositasokat es akkor nem kell ezt a hihetetlen eroforrasigenyes/lassu modszert alkalmazni...

Error: nmcli terminated by signal Félbeszakítás (2)

ja itt jon be az hogy amikor es aki ezt a rendszert megtervezte elgge elbaszta az architekturat es kb. irattszekrenykent tekintett a diszkre, azaz semmi affinitasa nem volt az informatikahoz. Mar bocs. :D

sok millio kis allomanyt nem tarolunk semmilyen fajlrendszeren. Erre valo  noSQL documentstore típusa (eg.: ElasticSearch).

De ugye mindegy, mert el van baszva. Bar lehet hogy lehetne migralni.

Ha tudom a file-ok schema-jat, akkor mondjuk egy rdbms-t inkabb backend-nek, a frontend maradhatott volna a fileshare az uploadra a lekerdezesre meg ott az sql vagy egy custom UI, a middleware meg egy process lett volna, ami feldolgozza az allomanyokat amikor valamit odaratak, aztan delete ha lehet. De mivel nem tudom a business igenyeket csak talalgatok. De nem hiszem hogy az lett volna "taroljunk tobbmillio mini allomanyt a fajlrendszeren". Valami olyanra tippelek "taroljuk a bekuldott mini adatokat X evig". De az is lehet hogy az elejen (20 eve) csak napi 3 kis allomanyra szamitottak aztan ebbol lett napi 3millio. Amikor ez elkezdodott, akkor kellett volna az IT-nak szolnia a business-nek es itt elkezdodott volna a kor. Szoval itt az is kerdes, hogy ha ez husz eves es (architekturalis) problemak voltak/vannak vele, miert nem tortent meg a refactoring szepen lepcsozetesen. Pl. a fenti megoldassal kezdve, aztan az egyes layereket atalakitva/kiveve egy modern megoldas fele a 20 ev alatt.

En mondjuk az elmult 20 ev alatt eleg sok refactoring/redesign/reimlement/greenfield projektben reszt vettem, szoval azert van igeny arra hogy az ilyen megoldasokat jobba tegyek. Persze ez penzugyi kerdes nem technologiai. Ha a cegnek olcsobb 3-4 embert erre fentartania, mint egyszeri beruhazsaal megjavitania, akkor tenyleg nincs ertelme meg a muszaki problemakat sem megoldani. Attol hogy lehetne jobb, nem biztos hogy penzugyileg megeri.

Akkortájt volt szerencsém nagyon sok képet kezelő rendszerhez, és ott bizony szépen, több szintű könyvtárstruktúrában voltak a képek (ha jól rémlik legalább 3 szint volt), a "melyik kié és hol van" adatokat tárolta egy szintén szép nagy mysql (shardinggal szétdobva néhány gépre).
Mondjuk ott a fájlok nagyságrendje volt ekkora...

Abszolut nem regi rendszerrol beszelunk, az uzemeltetesnek kellett athelyeznie ide az allomanyokat ~0 fejlesztoi tamogatassal (ertsd: annyira el voltak foglalva a fejlesztok, hogy a konfigokat is mi irkaltuk az adott projektekben es toltuk fel git ala). 10+ kiszolgalobol lett 2 (ezek kozott letezik az ominozus topicnyito rsync alapu inkonzisztens attoltes) + dirvish alapu backup. (Elotte ez sem letezett; raid1, vagy raid5, oszt mogy, minek nyuljunk hozza)

A struktura erintetlenul hagyasanak is jo oka volt: az egyik statikus backend storage ~2700 nap uptime utan elkezdett ECC hibakat dobalni; parhuzamosan pedig megjelent egy rakat offline uncorrectable szektor. Magyarul: azzal kellett foznunk, amink volt es nem lassu tuzon, hanem termittel :)

A fentiek alapjan nagyobb faszsag lett volna ugy hagyni.

Error: nmcli terminated by signal Félbeszakítás (2)

Hát... őszintén szólva ilyen esetben 200+ milló fájl, már gyanús, hogy nincs jobb megoldás.

Még az *fsdump is gyanús, hogy tekerne vagy 8-20 órát.

Aztán ha lenne mód valami csiribúra, akkor áttenném az egészet drbd fölé. Már nem feltétlen mentésként, hanem lenne egy olyan block device, amit helyben lehetne macerálni.

Vagy, felteszem a 13T az lvm-en lakik, snapshot, és https://github.com/vog/bscp/blob/master/bscp csak a változásokat átvinni.

Egyiket se tartom alapvetően jó, vagy tökéletes megoldásnak, de a jelen helyzetben már csak ötletelek.

( enpassant v | 2021. 03. 29., h – 16:52 )

Én btrfs snapshot + send/receive-et ajánlok.

A snapshot <1mp alatt meg van. Ha kevés volt a változás, akkor a send/receive is pár mp.

Biztosan konzisztens és fail-safe.

hat ize, nem.

Egyreszt nem muszaj secure connection-on keresztul hasznalni.

Mesreszt csak a kulonbsegeket viszi at, mivel ket stream-et nyit. Az egyiken folyamatosan lepked a buffermeretben es osszehasonlitja azellenorzo osszegeket, hogy de azt at kell e vinni, a masikon atviszi ha kell az adott buffert. Erdemes beleolvasni a forraskodjaba, mert nagyon szep es latni lehet hogy mit csinal :D

The sender computes the checksum for each rolling section in its version of the file having the same size as the chunks used by the recipient's. While the recipient calculates the checksum only for chunks starting at full multiples of the chunk size, the sender calculates the checksum for all sections starting at any address. If any such rolling checksum calculated by the sender matches a checksum calculated by the recipient, then this section is a candidate for not transmitting the content of section, but only the location in the recipients file instead. In this case the sender uses the more computationally expensive MD5 hash to verify that the sender's section and recipient's chunk are equal. Note that the section in the sender must be not at the same start address as the chunk at the recipient. This allows efficient transmission of files which differ by insertions and deletions. The sender then sends the recipient those parts of its file that did not match, along with information on where to merge existing blocks into the recipient's version. This makes the copies identical.

De ettol fuggetlenul is erdemes elolvasni a forraskodjat ha tenyleg szep kodot akarsz latni. Ugyes megoldasok vannak benne nagyon.

ja emlexem mar miert nem tudtam a /dev/vg0/guest-root.snap -ot a /dev/vgbackup/guest-root.bak-ra rsync-elni, mert disket nem hajlando (vagy en benaztam el valamit), pedig jo lenne ha kevesebbet kellene irni az ssd-re

erre van valami otletetek?

legyen benne a debianban a program, ne kelljen programot forditanom hozza, olyat talaltam en is

csinaltam hozza egy masik forumot hogy ne ezt turjuk szet:

https://hup.hu/node/173315

neked aztan fura humorod van...

rsync-kel fájlokat lehet másolni hatékonyan.

Van a guest-root.snap snapshotod, felmountolod egy temp könyvtárba, ráereszted az rsync-et és csak az utolsó rsync óta történt változásokat másolja át a másik helyre. Ha az utolsó rsync az előző snapshotból készült, akkor az új snapshot teljes tartalmát (mert csak a változás van a snapshotban és csak a változást másolja az rsync).

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Nem azt mondtam, hogy ezt kell csinálnod, hanem azt, hogy az rsync erre való. Fájlok másolására, nem másra.

Ha nem akarod felmountolni, hát ne mountold fel. Ha nem tetszik ez a megoldás, akkor csináld máshogy. Úgy, ahogy tetszik.

Mondjuk én a döntéseket máshogy szoktam meghozni. Ha van két működő megoldás, akkor azok közül kiválasztom azt, amelyik szimpatikusabb. De ha csak egy működő megoldás van meg egy nem működő, akkor a működő megoldást használom akkor is, ha nem tetszik (és esetleg utána játszom egy kicsit a másikkal, hátha meggyógyul, de túl sokat nem vacakolok vele).

Amúgy meg szabad kérdezni, hogy mi a baj a felmountolással?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

allitolag linux alatt minden fajl, ezert probaltam az lv-t rsync-el masolni.

ha senkinek sem mukodik vele keresek mas megoldast.

nincs baj a felmountolassal, de a fajlokrol mar van rsync-el mentesem ezert felesleges.

ezzel az lv-rol akartam egy olyan snapshotot csinalni ahol nem minden szektort masol csak ami valtozott.

mar sikerult: https://hup.hu/comment/2611619#comment-2611619

neked aztan fura humorod van...

hagyjuk mert mar irtad a masikban hogy megoldottad, de azert szogezzuk mar le, hogy egy lvm snapshot-ban csak az van ami valtozik, semmi mas. Ha csinalsz egy lvm snapshot-ot, abban nincs olyan ami NEM a valtozas. Sot semmi mas nincs benne CSAK a valtozas. Ugyhogy annak a megfogalmazasnak, hogy egy snapshotbol csak  avatozast akarod menteni NINCS ertelme. 

egy lvm snapshotban az lv egy pillanatnyi allapota van, az az allapota amikor az lvm snapshotot letrehoztam

ebbol kell nekem egy snapshot (az lvm snapshot masolata, ami nem lvm snapshot), hogy az lvm snapshotot le tudjam torolni

amikor az lvm snapshotbol masolom a snapshotot (a regi snapshotra ramasolom), ami a ketto kozott nem valtozott azt nem akarom masolni

nem tudom igy ertheto-e

neked aztan fura humorod van...

akkor ez nem linux lvm2 kotet ezek szerint...azt hittem bocsi, azert ertetlenkedtem.

Merthogy a linxos lvm snapshot egy COW reteg az eredeti LVM folott, amiben semmi sincs csak mutat az eredeti LVM kotetre.

Ha aztan irsz valamit az LVM-re, akkor az a snapshot-ba kerul es nem az eredeti kotetre. Ilynkor pl lehet egy jo kis db backup az eredeti kotetre, mert igy nem lesz benne az eppen aktualis valtozas, nem lesz partial data benne.

Ha elegedett vagy a valtozasokkal, akkor meg mergeled a spashot-ot es kesz.

Ez jo megoldas lehet release-ek eseten is egy gyors rollback-re. Mielott release-el az ember nyom egy snapshot-ot, aztan release, aztan ha gaz van gyorsan eldobja a snapshot-ot es vissza is all a regi allapot. Ha meg jo lett, akkor mehet a merge (ami szinten eldobja a snapshot-ot).

Azaz egy linux-os LVM2-es snapshot mindig csakis a valtoztatasokat tartalmazza valojaban, az eredeti kotet tartalmat nem (csak mutat ra). Eezert is nem hasznalunk long-live snapshot-okat vagy snapshot-olunk ujra es ujra, mivel az ujabb es ujabb COW retegekkel neheziti meg a rendszert. A snapshot lifecycle: create->store changes->(examine, ha kell)->merge_or_drop 

de, a linux lvm2-rol beszelek en is

az ssd-n valoban csak a valtozasok vannak elmentve metadata-kent

https://github.com/mpalmer/lvmsync#theory-of-operation

de ha a /dev/vg0/guest-root.snap-ot olvasom akkor nem a metadatat kapom vissza hanem a /dev/vg0/guest-root lvm snapshot pillanataban letezo tartalmat

neked aztan fura humorod van...

Hat en igy csinalnam:

# lvcreate -L 500m test_vg -n test_lv
# mkfs.ext4 /dev/mapper/test_vg-test_lv
# mkdir /data && mount /dev/mapper/test_vg-test_lv /data
# # create data on original volume
# echo "this is alma" > /data/alma.txt
# # create the snapshot to store the original state
# lvcreate -s -n test_snap -L 100m /dev/mapper/test_vg-test_lv
# # now add some new data to the volume
# mkdir /data/snap_data
# echo "this is korte" > /data/snap-data/korte.txt
# # mount the original volume without the changes
# mkdir /origdata
# mount /dev/mapper/test_vg-test_snap /origdata
# # test the differences
# rsync -nav /data/ /origdata/
sending incremental file list
./
snap_data/
snap_data/korte.txt

Mint latod igy pont latszik a kulonbseg, ami neked kell es ezt a listat mar at tudod masolni. Csinalsz egy file listat vagy valamit es atmasolod amivel akarod.

ez jo, szerintem wladek1-nek sokat fog segiteni.

nalam nincs annyi fajl, nekem az is eleg ha a backup szerverrol inditom az rsync-eket

en nem akarom igy mert a napi menteshez egesz nap mennie kellene az lvm snapshotnak ami sokat lassit az lv-n

neked aztan fura humorod van...

személyre szabott keresési eredmények.
Korábbi tevékenységeidből felépített profilod alapján rendezi sorba a találatokat a keresésekkor.

Alapjában véve nem rossz, mert az esetek többségében sokkal gyorsabban lehet releváns eredményt kapni, de időnként piszkosul idegesítő, ha valami új szemszögből akarok egy dolgot megvizsgálni, mert olyan eredményt nem ad, ami a korábbiak alapján engem nem érdekelhet.

Gyakorlatilag bezár egy olyan információs buborékba, ami szerinte rád illik.

Drbd - t még nem konfiguráltam új szolgáltatásként production env - ben [használni használtam, de nem úgy, hogy sokadik lépésként aktív kiszolgálás mellett módosítsak] , ez leghamarabb a jelenlegi target kiszolgálón lesz. 

Error: nmcli terminated by signal Félbeszakítás (2)

ja ertem akkor semmi konkret, csak azert kerdeztem mert en is most akarom drbd-siteni az eles szervert,

es abban biztos vagyok hogy a virtualis gepeket egyenkent le kell majd allitanom hogy az lv-ket es a configokat drbd-sitsem de az virtualis gepenkent par perc ami itt belefer.

illetve mivel mar hasznalatban vannak a diskek a meta-disk nem internal lesz hanem egy lv-n lesznek es indexekkel oldom meg igy lv-nkent 128MB-ot fog hasznalni a metadata, ez max. 4TB-s lv-re lenne eleg de nalam osszesen nincs ennyi tar

neked aztan fura humorod van...

( x-daemon | 2021. 03. 29., h – 17:55 )

Szerkesztve: 2021. 03. 29., h – 17:56

es ha lenne

--backup

es

--backup-dir=

parameter is?

aztan majd torlod a backup direket a hely fuggvenyeben

egyebkent checksumos a mentes vagy anelkul is ennyire lassu?

neked aztan fura humorod van...

( Elbandi v | 2021. 03. 29., h – 22:39 )

ugye nem egy dirben vannak a fajlok? nekem az a tapasztalaom hogy ext4 kb 15-20k fajl/dir birja utana kezd belassulni.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( cstamas | 2021. 03. 29., h – 23:02 )

Szerkesztve: 2021. 03. 29., h – 23:04

Hogy a kérdésre is válaszoljak:

IO error encountered -- skipping file deletion

hibaüzenettel nem törli a fájlokat hiba esetén.
Persze ha valamiért pl. nincs ott a forrás oldalon pl. a könyvtár vagy mount nincs a helyén akkor simán törölheti a backupot.
cp -al backup backup.$(date +%F) módszerrel hardlinkkel tudsz tárolni 2 backupot, ami nem foglal 2x helyet.
Ezek után a "backup" könyvtárba ha rsync-elsz akkor ott lesz egy friss backupod és csak a módosított tartalom fog helyet foglalni, mert a többi hardlink. (a fentihez hasonló, hatékonyabb, de tovább tart elmagyarázni az rsync --link-dest kapcsolója)

( x-daemon | 2021. 03. 31., sze – 19:49 )

Szerkesztve: 2021. 03. 31., sze – 19:54

wladek1, mekkora taron van a 83 millio fajl? tudsz a gepbe meg egyszer akkora tarat beletenni? nem kell hogy raid legyen, eleg egy egyszeru disk. illetve kerdes hogy ha meglenne az eredeti snapshotja golgota modszerevel kevesebb ido alatt csinalna-e meg a fajl listat az rsync mint a mostani modszereddel

https://hup.hu/comment/2612080#comment-2612080

ja a tervezesi hiba most jutott eszembe hogy nem lvm-en van

akkor viszont lvm-esiteni kellene, ha van ra lehetoseg

neked aztan fura humorod van...

Szamszakilag valoszinuleg nagyon alabecsultem a dolgot:

54064905 csak a konyvtarak szama, kb 3 fajl legalabb minden konyvtarra az atlag. Nem szamolok ra megegyszer, mert a konyvtarak osszeszamolasa is 2 napig tartott :D

13T -rol beszelunk; a hasznalatban levo inode -ok szama 324755224. A storage foglaltsag 80%, es nem is bovitheto (hetzner dedikalt gep; helyileg nem bovitheto a dolog).

Error: nmcli terminated by signal Félbeszakítás (2)

mondanam hogy bind mounttal egy nagyobb konyvtarat fel tudsz csatolni tobb kis konyvtarra hogy az utvonal megmaradjon, de egyreszt ekkora meretben ez sem 2 perc, masreszt minden kis konyvtarban latszananak a nagyobb konyvtar osszes fajlja ami lehet problemas

neked aztan fura humorod van...

lvm-esiteni egy preallocate (dd seek-el kell letrehozni vagy fallocate-el https://linux.die.net/man/1/fallocate ) loopback fajllal lehetne elvileg, de nem probaltam, nem tudom hogy viselkedik amikor letrehozod rajta a pv-t, vg-t,  lv-t

probald ki egy masik gepen elotte, akar vmware playerben

ha mukodik ettol meg ott lesz az a problema, amikor a fajlokat atmozgatod az uj helyukre az sok ideig fog tartani, erre talan egy overlayfs-t lehetne hasznalni ideiglenesen, ha nem nagyon sok fajl modosul naponta

neked aztan fura humorod van...

325M inode - 54M directory = 271M fájl

13T / 271M = ~48KB/fájl

Ezek mini fájloknak semmiképpen nem nevezhetők, a fentebb felvetett "tároljuk a fájlokat RBDMS-ben" c. megoldás sem lesz hatékonyabb. Ha jelentős a szórás (sok 4KB alatti fájl is van, meg jó pár nagy is), akkor lehet hibrid a rendszer: a kicsi fájlok mehetnek egy DB oszlopba, ami 4KB felett van, az maradhat fájlrendszerben.

Viszont a darabszám alapján felmerül a kérdés, hogy vajon ez nem egy archívum-e véletlenül, ahol a múltbéli fájlok már nem tudnak változni, mindig csak a legfrissebbek, amik viszont az idővel arányosan termelődnek.

Mert ha igen, akkor megfelelő strukturálással (tipikusan napi/havi bontásban) egyszerűen kezelhető a dolog: pl. a lezárt napok/hónapok read-onlyba mennek, és egy full szinkronizálás után tudni lehet, hogy többet nem kell szinkronizálni/menteni, hiszen változni már nem fognak a fájlok. Sőt, ha olyan az adat, akkor még transzformációknak is lehet értelme: pl. tömörítés.

Médiaalomanyok, elsősorban képek az adott időszakban elérhető legjobb tömörítéssel. A hozzá kapcsolódó aktív és inaktív userek miatt a módosulás akármelyik állományt érintheti. GDPR miatt a törlés sem megkerulheto, sem nem elodazhato. 

Az állományok nagyrészt 10x10 - és mezőben vannak, vagyis ez alapján nem beazonosíthatóak. Íme egy példa : img.site.tld/1/2/3/4/5/6/7/8/9/0/$uid-1234567890avatar.jpg ahol a 1234567890 a média id, de ez csak az adott projektben unique... 

Error: nmcli terminated by signal Félbeszakítás (2)

Médiaalomanyok, elsősorban képek

Akkor miért változhatnak? Nekem ez tipikusan immutable fájlnak tűnik, ami egyszer elkészült, és soha többet nem akarok beleírni, legfeljebb csak törölni.

A hozzá kapcsolódó aktív és inaktív userek miatt a módosulás akármelyik állományt érintheti.

Mi van az állományban még, ami miatt változtatni kéne? Ha metaadat, akkor azt adatbázisban kéne tárolni a fájlokon kívül.

GDPR miatt a törlés sem megkerulheto, sem nem elodazhato.

Ez kezelhető, ha a metaadatok adatbázisban vannak. Pl. a törlendő állapotba került adatokat külön táblába írni, és az alapján takarítani - a törlés szinkronizálását meg ezen tábla alapján csinálni.

A másik tipikus GDPR-megoldás, ha a minden fájlhoz (vagy a kívánt törlési granularitásnak megfelelő adathalmazhoz) rögzítéskor generálsz egy random kulcsot, amit beraksz az adatbázisba, és azzal titkosítva kerül a diszkre a fájl. A törlés első körben a kulcsmező törléséből áll - aztán majd egy néha lefutó takarító processz le is törli a fájlt, de így ugye megteheted, hogy baromi ritkán fut a takarítás, ennek ellenére nem vagy hozzákötve GDPR határidőkhöz.

( micsa v | 2021. 04. 01., cs – 17:22 )

Szerkesztve: 2021. 04. 01., cs – 17:34

ennyi file esetén fs szinten semmi nem fogja hatékonyan megoldani...

fent említették a btrfs snapshot diff-et: ha fontos az adat, én nem bíznám btrfs-re... bár sok éve azt használok laptopon, home szerveren, stb.

a filerendszerek tényleg nem erre valók... erre még egy mysql innodb is jobb megoldás: simán az elérési út (string) a primary key és blob a data...

szerk:

tudtommal a rsync amikor másolja a file-it, temporális file-ba menti alapból...  és a destination-nél csak akkor fogja átnevezni, amikor teljesen megérkezett

a --delete pedig le fogja törölni a fölösleges file-okat...