rsync --noatime

rsync (3.1.1-1) unstable; urgency=low
[...]
* add noatime patch which adds the --noatime option, which adds the O_NOATIME
[...]

Hogy mik vannak...

( uid_6201 v | 2015. 10. 06., k – 10:39 )

Nekem jól jött volna már ez az opció.

Ami még jól jönne: block device másolása, pl /dev/sda3 átmásolása másik gépre rsync segítségével.

És ott az adat konzisztenciát hogy garantálod? Vagy azt majd rsync-en kívül megoldod?
Illetve itt mi az elképzelés? Hogy 1 az 1ben simán áttolni a teljes adattömeget a hálón, vagy valamiféle inkrementumot generálni és azt áttolni?
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

??? Normálisan konfigurált rendszeren a /dev-en kívül mi keresnivalója van egy device-fájlnak? Azt meg ugye a linuxos világ manapság udev-vel szereti turkálni. Ha nagyon muszáj, akkor még mindig lehetne mknod-ot futtatni a távoli gépen - persze igaz, az rsync jó lenne az automatikus létrehozáshoz.

Ez is egy megoldás. Viszont ehhez sokkal több időre esik ki a szolgáltatás. Ezért szeretném a leállítás után csak a differenciát a háttértár tempójánál sokkal lassabb hálózaton áttolni.

És így az alapkérdés marad: "rsync ... /dev/sda3" valahogy megoldható-e? Végülis a /dev/sda3 egy partícióméret hosszúságú fájl.

Kevered a konzisztencia biztosítást a konzisztencia ellenőrzéssel: Attól még hogy checksumokat gyártasz nem garantálod azt, hogy az adat ténylegesen konzisztens is marad, max képes vagy leellenőrizni, hogy a mentett adat megegyezik e a mentés utánival.
A chunkonkénti checksumolás meg halva született ötlet, mert a chunkokat szekvenciálisan kéne lekezelned, ami viszont magában hordozza azt a problémát, hogy egy már lementett adat utólag módosúl egy már lementett chunkban, és egy még lementendő chunkban is: Abban az esetben, ha nem történik írás a "backup" futtatásakkor, akkor ezt az állapotot a te megoldásod konzisztensként könyvelné el, viszont a valóságban a backupod nem lenne konzisztens.
Szóval nem olyan triviális ez, mint amilyennek látszik (főleg ha még beleszámolod azt is, hogy a block device adatának 1 része simán lehet még a memóriában).
Személy szerint én erre csak 2 megoldást látok:
- Offline backup: Biztosítani, hogy a block device egyáltalán nincs használatban (tehát garantáltan semmi nem piszkálja az adatot)
- Snapshot based (online) backup: Valamiféle snapshotting technikával snapshotot készíteni block szinten az adott block device-ról, majd az immár konzisztensé vált snapshotról készíteni egy backupot

Az első verzióban az rsync még talán képes is lenne backupot készíteni (sőt akár incrementalt is számolni), viszont ott több értelmét látnám egy sima dd-nek inkább már.
A 2. verzió meg garantáltan nem az rsync hatáskörébe tartozna (de amúgy snapshot után egy sima dd ott is menne)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

"egy már lementett chunkban, és egy még lementendő chunkban is: Abban az esetben, ha nem történik írás a "backup" futtatásakkor, akkor ezt az állapotot a te megoldásod konzisztensként könyvelné el, viszont a valóságban a backupod nem lenne konzisztens"

Pingvin, ez a problema most is fennall, ha egy 100 GB-s fajlt mentesz at a halozaton, es az rsync jelenleg sem biztosit ilyen szintu garanciakat, mert nem is ez a feladata neki! A temaban lasd meg: MySQL es ibdata1.

Szerintem itt nem is backuprol van szo (a kollega meg sem emlitette a backup szot a problema felvetese soran), hanem egy kicsit megerositett blockdevice-klonozasrol a halozaton at, pl. kesz rendszerek diszk szintu deploymentjehez. Az rsyncben sok olyan feature van, ami hasznos lenne az ilyen folyamatok soran.

--
Blog | @hron84
Üzemeltető macik

Kiindulási pont: "És ott az adat konzisztenciát hogy garantálod? Vagy azt majd rsync-en kívül megoldod?"

Válasz1: Konzisztencia: parszaz blokkonkent checksum?
Válasz2: "az rsync jelenleg sem biztosit ilyen szintu garanciakat, mert nem is ez a feladata neki!"

Tehát (ahogy írtam is), nem biztosít adat konzisztenciát, viszont akkor hogy képzelitek el egy block-device másolását ez nélkül?

"Ezek a dolgok amugy mar most is reszei az rsync-nek, szoval nincs uj a nap alatt".
-> Mint látható az rsync erre nincs felkészítve, és pont a konzisztencia biztosítás hiánya miatt nem is fog ilyet tudni.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Attol fugg, mit nevezel adat-konzisztencianak. Az rsync jelen pillanatban is csak olyan szinten biztosit adat konzisztenciat, hogy feltetelezi, hogy sem a forras- sem pedig a celfajl nem fog modosulni a masolas egesz idotartama alatt. Ezen a megszoritason belul o a kis checksumjai menten biztositja azt, hogy a masolt adat (hacsak kulso modositas nem tortenik) bitre megegyezzen mindket oldalon. Az rsync erre szerzodott, nem tobbre es nem kevesebbre.

Jelenleg egy block device "klonozasa" leginkabb a dd paranccsal tortenik, vagy valamivel, aminek a mukodese rettenetes modon hasonlit a dd parancshoz, ami viszont - elegge el nem itelheto modon - csak az egyik oldalat latja a problemanak. Az rsynccel vegre megvalosulhatna az, hogy mindket oldalon egy ilyen meretu adatok halozati atvitelere felkeszitett szoftver fut, amely kepes kiszurni pl. az atviteli hibakat (melyre mondjuk egy NetCat-tal TCP portra raengedett dd aligha kepes), raadasul opcionalisan kepes az adatok tomoritesere is, melyre a dd onerobol szinten alkalmatlan.

Ha innen nezzuk, az rsync klasszisokkal tobbet tehetne a konzisztenciaert, mint a jelenleg scriptbol osszedobalhato megoldasok tobbsege. Ezert es nem masert lenne hasznos, ha az rsync kezelne blokkeszkozoket is.

Off: Valamikor osszefuthatnank, tobmillio eve nem beszeltunk f2f
--
Blog | @hron84
Üzemeltető macik

Parancsolj: ssh user@server "dd if=/dev/sda | gzip -1 -" | dd of=/backup/sda_image.gz
SSH-n keresztül normál TCP/IP csatornán, tömörítéssel egybekötve biztonságos csatornán. Mondjuk konzisztenciát biztosítani ez is képtelen.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Probalok cizellallt lenni: A dd-t en is emlitettem, es megemlitettem azt is, miert nem jo: mert nem kepes ellenorizni, hogy az atvitel soran nem serult-e meg a packet, erre az (lib)rsync kepes.

Egyebkent nem szeretem ssh-n attolni, mert nem mindig tudom maxon kihajtani a halot vele. Az nc ilyen feladatokra jobb.
--
Blog | @hron84
Üzemeltető macik

Packet résülést nem is a dd-nek kéne néznie. Arra ott van a TCP/IP, a maga checksumjaival, meg packet orderingjével, plusz az SSH aminek szintén ellenőriznie kell a csomagokat, hgy a titkosítást normálisan fenn tudja tartani.
Nc-től ilyet ne várj (főleg ha UDP-n keresztül kommunikálsz)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

fcntl vagy flock -> exclusive lock.
Bár tény, hogy ha épp egy app közben írná, akkor annak ez nagyon nem fog tetszeni, cserébe viszont garantáltan nem piszkál bele más a file-ba amíg a lockot el nem engedem.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nem, meg értelme sem lenne, mert amint ezt megjátszanám nyomban beállna/crashelne az összes progi ami az adott device-t használja.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..