Távoli gépről disk másolás

Fórumok

Nagyon lerágott csont, de nem igazán találok megoldást.
A távoli gépről, amihez van ssh hozzáférésem és sudo/root hozzáférésem kellene átmásolni az egész home -t (nem csak az én de úgy egy tucat felhasználóét). Mit kellene erre használni scp, rsync esetleg sftp, és hogy nézne ki a parancs?

Hozzászólások

Scp, rsync, bármi. Ha a user nevek és a helyük nem változik akkor egyszerűbb a helyzet. 

Szerintem nem így gondolta... de amúgy kérdés, hogy mit szeretnél. Elég egy backup? Elég, hogy megvannak a fájlok? Teljesen klónozni szeretnéd a rendszert, az új gépen belépni a távoli gép felhasználóival, jogosultságok és .xyz konfig fájlok is megtartsák helyüket, jelentőségüket és értelmüket?

...az utóbbi a necces. Az előbbi kettő meg tényleg csak egy drag'n'drop művelet vagy a már említett rsync parancs: https://hup.hu/comment/2422939#comment-2422939

Rsync lesz a barátod. Kb így:

$ rsync -avHAC -e "ssh -p<port>" user@ip:/home/ /target/to/copy/

"A megoldásra kell koncentrálni nem a problémára."

Elvileg az sftp megosztást fel lehet mountolni... én ebből az irányból indulnék ki, aztán használnám a kedvenc fájlkezelőmet, vagy írnék egy célirányos scriptet.

Szerveroldalon meg csinálnék egy felhasználót, ami olvasási joggal hozzáfér minden felhasználó cuccához, és azzal a felhasználóval végezném a dolgot.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

-1

Nem tudjuk mennyire távoli a gép, és milyen a kapcsolat (LANon van kicsit odébb van, vagy nagyon távoli...), valamint sok file esetén (ezt sem tudjuk) igen csak nehézkes a mountos-filekezelős megoldás.

Az rsync azért is jó, mert ha megszakad a kapcsolat, vagy többször is neki kell menni (pl költözés) akkor nem kezdi újra az egészet.

A mountos-filekezelős megoldás szerintem usernek való napi munkához LAN-on, pl samba-val.

"A megoldásra kell koncentrálni nem a problémára."

Én is az rsync -re gondoltam, de mondom hátha. Lokálisan, ha egy szűz diszkre másolsz ez egy jó megoldás.
INFO:
A két gép csak interneten kapcsolódik, a távoli szerver ck. 15Mb/sec uupload az én downloadom a csillagos ég. 254GB köztük Maildir -ek ami irtó sok kis fájl kellene átcígölni (nem számoltam utána, de lehet nem elég rá 24 óra ezen a sebességen).

* Én egy indián vagyok. Minden indián hazudik.

Nah, a sok kicsibe fog belerohadni a filekezelő. Rsync folytatja, ha ő is megsuvadna, és nem nulláról mész.

Ha annyira sok, és összességében annyira nagy, akkor tényleg gondolkodj egy adathordozó futáros továbbításán. :D

"A megoldásra kell koncentrálni nem a problémára."

Szerkesztve: 2020. 01. 07., k - 18:43

Az rsync nem rossz, de én jobban szoktam szeretni, ha egyetlen fájl megy át.

Ezt pedig így csinálnám:

tar -cv /home/ | ssh <user>@host 'dd of=home.tar'

vagy

tar -cvz /home/ | ssh <user>@host 'dd of=home.tar.gz'

szerk:

távoli gépről indítva:

ssh <user>@host 'tar -cvz /home/' > home.tar.gz

Ki kell? Mi sem egyszerűbb:

ssh <user>@host 'tar -cvz /home/' | tar -xz

:)

De én el szoktam lenni a tar fájlokkal, ha mentésről van szó, és az előnye az, hogy nem kell uid/gid konverzió a két rendszer között. Marad úgy, ahogy be lett tömörítve, bármikor vissza lehet állítani.

Ez világos, de amit a hálózaton nyersz időt az egy file, tömörített átvitelén, az elveszted a CPU-n.

Természetesen ettől még működik amit írsz. Csak komolyan kell mérlegelni, hogy jobban járunk-e tar-gzip-ssh-dd-gunzip-untar lánccal, -- amit nem nagyon tudsz folytatni, vagy különbségekre megismételni --, mint egy szimpla rsync-kel, aminek ez természetes képessége.

"A megoldásra kell koncentrálni nem a problémára."

Nagyon régen csináltam ilyet, de akkor sokszor. A sima tar-os jött be nekem a legjobban. A gzip-elés elvitte processzor időben, amit nyert az ember átviteli sebességben. Legalábbis nálam, sok évvel ezelőtti vasakon. De sok pici fájl esetén feltétlen gyorsabb volt, mint az rsync.

 

Igaz, ha megszakad közben a háló, akkor baj van. Ha ennek veszélye fennáll, akkor rsync vagy hasonló, fájlonként másoló a biztos.

A gzip helyett érdemes pigz-t használni, főleg szerver to szerver átvitel esetén, ha mindkét végen bőven van procimag.

cd backupdir; ssh root@mentendo 'tar -s /home | pigz' | pv -W -t -r -b | unpigz | tar -x

A pv-t itt csak monitorozásra használom, de ha hagyni kell másnak is sávszélességet, akkor a -L kapcsolóval rate-limit is beállítható.
Esetleg a pigz helyett van pbzip2 is, de szerintem annak rosszabb a cpuhasználat/tömörítés aránya.

Ja, és ha valós a veszélye, hogy megszakad a kapcsolat, akkor a "tar over ssh" esetében annyit tudunk tenni, hogy apróbb részekre bontjuk az átvitelt. Pl. a felhasználónevek kezdőbetűje szerint:

for i in {a..z}; do
  cd backupdir; ssh root@mentendo 'tar -s /home/${i}* | pigz' | pv -W -t -r -b | unpigz | tar -x
done

Hát eddig úgy tűnik marad az eBay pendrive, helyett odamegyek és áttöltöm a PATA-s backup driveról - lehet USB -n.
Másként, ha ott vagyok mellette helyben akkor LAN -on hogy oldhatnám meg?
(Nagyon antik gép, úgy kell vele bánni mint a hímes tojással)

* Én egy indián vagyok. Minden indián hazudik.

Az rsync gyengéd. :)

Ha a forrásnak közben szolgáltatni is kell, akkor nice és ionice még jól jöhet. Ettől még tovább fog tartani, de semmi nem áll meg.

Sebesség vs. SLA. :)

 

Szerk: mennyire sürgős? Mekkora az össz adat? Kb mennyifile?.

"A megoldásra kell koncentrálni nem a problémára."

Jó kérdés. Ha leállítom akkor legfeljebb a hétvége. 254GB benne Maildir és samba megosztott mappák, keresztül kasul linkelve.
A lényeg, hogy LAN szempontjából tök mindegy milyen messze is lennél, már ami a parancsot illeti, csak a sebesség a lényeg.

* Én egy indián vagyok. Minden indián hazudik.

Hát, ez akármivel csinálva is igen lassú lesz. Általánosságban nem lehet megmondani, hogy a Te esetedben mi lesz a szűk keresztmetszet, de lehetnek ezek:

  • IOPS --> Az rsync-nek is kell minimum az, hogy a fájl méretét és *time értékét megnézze, azaz fájlonként kell legalább 1 db IO művelet ahhoz, hogy eldöntse, kell-e átvinni a fájlt, a maildirben meg tipikusan sok fájlod van. A gyakorlatban egy sima HDD-ből kb. 100, egy sima SSD-ből kb. 1000 IOPS tud kijönni tartósan (újabb NVMe és hasonló csodákból több). Oszd el a fájlok számát ezzel, és legalább annyi másodperc fog kelleni csak ahhoz, hogy eldőljön, mit kell átvinni, amennyi így kijön. Ezen olyan nagyon nem tudsz segíteni, IO elevator állítással lehet picit hangolni, de átütő eredményekre ne számíts nagyon.
  • IO sávszélesség --> Kis fájloknál valószínűleg nem ez lesz a szűk, de legalább segíteni se tudsz rajta, szóval mindegy is :-)
  • hálózati sávszélesség --> ha marad CPU-d, akkor ezen jól lehet spórolni, ha a hálózati átvitelhez hozzácsapsz egy tömörítőt, akár az rsync -z kapcsolójával, akár úgy, hogy egy pipe-ba rsync-elsz, majd onnan egy pl. egy tar + tetszőleges tömörítővel olvasol a tényleges átvitel előtt
  • CPU --> ha a CPU-d fogy el, akkor egy picit tudsz spórolni azzal, ha az SSH-hoz "olcsóbb" ciphert használsz
  • szálak száma --> ha van minden fentebbiből még tartalék, akkor megpróbálhatsz két kézzel indított szálon csinálni dolgokat, mondjuk fele-fele könyvtárat kezelni a /home alatt két szálon

Írta, hogy valami régi PATA diszk, úgyhogy a darabszám/100 is optimista becslés arra, hogy hány s kell a fájlok átnézésére.

Az rsync -e ssh esetén nekem az a tapasztalatom, hogy a -z használata nem jelent releváns különbséget a tényleges adatátvitel idejében - ellenben a tömörítés viszi az erőforrást. A cipher választás ellenben tényleg nem mindegy, egy "-c arcfour" emlékeim szerint ;-) szinte csodákra képes :-)
PATA diszk, úgyhogy iops-ból nem lesz tartalék arra, hogy több szálon paralel olvassa a fájlrendszert :-)

root-ként futtatva rscync.

Hogy nézzen ki a parancs? A felparaméterezéséhez javaslom a man olvasgatását. Van egy csomó különféle opció (pl. mit csináljon symlink esetén, mit csináljon hardlink esetén, van-e olyan fájl (backup fájlok, stb), amit nem kell másolni, stb. stb.

Én személy szerint valami ilyesmivel indulnék:

# rsync -a root@távoligép:/home /itt/backup/távoligép/

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.

Én meg "visszafelé" csinálánám: ssh mezitlabasuser@tavoligep majd sudo -iu root utána screen, majd screen-ben ízlés szerinti paraméterezéssel :-) rsync - ctrl+a d, ctrl+d ctrl+d, aztán a helyi gépen lehet figyelni, hogy hogy halad a szinkron izélés, illetve a távoli gépre ssh mezitlabasuser, sudo -iu root; screen -r, hogy megnézd, ott hogyan áll.

Ezzel nem kell a túloldalt "kinyitni" root usernek, ami azért hasznos dolog.

Kicsit zavaros ez nekem. Az OK hogy csinálsz egy screen folyamatot (ilyet szoktam használnia lokális backuphoz is), azt is érteni vélem, hogy miután eleresztetted az rsync parancsot (ízlés szerinti paraméterezéssel :)  ctrl+a d - vagyis detouch. Viszont mi az a két ctrl+d ?
Ráadásul, az rsync -et itt is root -ként kéne futtatni, így az általa megnyitott port szintén root jogosultságokkal bír, vagy valamit félre értek?
Mindenképpen feltételezi, hogy az rsync dedikált porton működjön, így ki is kell nyitni a routert/tűzfalat. Valahogy mégis csak az ssh -n keresztül kéne ezt intézni - na nem mintha az adatokat félteném, inkább a portot.

* Én egy indián vagyok. Minden indián hazudik.

Bemész mezitlábas userként a mentendő gépre ssh-val - nincs szükség arra, hogy root-ként közvetlenül be tudj jelentkezni. A célszerveren több lehetőséged van: megcsinálod az összes releváns usert, adsz nekik jelszót, és az "rsync -e ssh"-t userenként futtatod, az új gépen adott jelszóval, vagy pedig egy saját suerrel, és utána az egyes könyvtárakra kiadsz egy-egy jól irányzott "chown -R" parancsot.

Mindenképpen feltételezi, hogy az rsync dedikált porton működjön, így ki is kell nyitni a routert/tűzfalat. Valahogy mégis csak az ssh -n keresztül kéne ezt intézni

Miért menne az rsync dedikákt porton?

Ugyan a man szerint tud ssh-n kívül mással is menni, de én gyakorlatilag még kizárólag ssh-n keresztül láttam futni.

Zeller hozzászólásából nem világos számomra, hogy csak személyes preferencia, vagy valami előnye is van annak, amit ír szerinte.

Mindenesetre szerintem mindkét oldalon root jog kell, mert egyik oldalon minden felhasználó minden fájlját olvasni akarod, a másik oldalon meg minden felhasználó minden fájlját a korrekt felhasználó és csoport tagsággal meg jogosultságokkal és dátumokkal létre akarod hozni.

Zeller ssh-val mezei felhasználóval belép a távoli gépre, majd root lesz, és elindítja az rsyncet, ami elindítja az ssh-t ami a root userrel kapcsolódik az itteni géphez.

Én a helyi gépen root leszek, elindítom az rsync-et, ami elindítja az ssh-t ami a root userrel kapcsolódik a távoli géphez.

Azon kívül, hogy az enyém kevesebb lépésből áll, igazából nem látok különbséget közöttük. Illetve de, ha mondjuk az egyik géphez nem tudsz root ssh belépést biztosítani, akkor érdemes arról a gépről indítani az rsync-et.

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.

"Zeller ssh-val mezei felhasználóval belép a távoli gépre, majd root lesz, és elindítja az rsyncet, ami elindítja az ssh-t ami a root userrel kapcsolódik az itteni géphez." - Majdnem. Egyik oldalon sem kapcsolódok root userrel, a másolt fájloknak az owner/group dolgait a másolás _után_ helyben rakom rendbe, mezitlábas user + sudo használatával. Így egyik gépen sem kell a root-ot beengedni ssh-n, ideiglenesen sem.

Értem. Ez nem volt világos az előző hozzászólásból.

Ez itt már egyéni preferencia kérdése. Én nem fázom attól, hogy root ssh-n keresztül kulcsos azonosítással hozzáférjen a távoli géphez, cserébe az összes fájl owner/group permission dolgait rendberakni vagy kézzel csinálom, ami sok idő és teli van hibalehetőséggel, vagy kell faragnom hozzá egy scriptet.

Ha neked már van kész scripted erre, akkor teljesen jó megoldás, ha nincs kész scripted, akkor _szerintem_ felseleges túlbonyolítás és időpazarlás. Én túl lusta vagyok ahhoz, hogy a jól működő, tesztelt kész megoldás helyett egy saját megoldást faragjak (amit tesztelni is kell).

Ha nem tudok egyik gépre sem root-ként belépni, akkor nem a te irányodba indulnék, hanem amit mások írtak feljebb: rootként tar, mezítlábas userrel áthozni (pl. scp-vel), aztán tar x rootként.

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.

"...összes fájl owner/group permission dolgait rendberakni vagy kézzel csinálom, ami sok idő és teli van hibalehetőséggel, vagy kell faragnom hozzá egy scriptet."

Épp a héten kellett: getfacl -R > valami és setfacl --restore valami

Mondjuk én chown scriptet teszteltem és ahhoz kellett, hogy vissza tudjak állni egy jó állapotra.

Ettől még mondjuk szerintem se jó megoldás, de lehet olyan eset, amikor valamiért nincs más.

Többen felvetik a tömörítést, mint lehetőséget. Anno ez történelmileg működött, mivel az átviteli sebességek eléggé alacsonyak voltak. Manapság ez nem tűnik szűk keresztmetszetnek, viszont  szakadás esetén folytatható ahol abbamaradt.

* Én egy indián vagyok. Minden indián hazudik.

Lehet megint pontatlan voltam! A PATA diszk a backup (lokál rsync), ami egy USB rackben csücsül.
Most az lesz a forgatókönyv, hogy kíhúzom a rackből és vagy megint USB, de inkább közvetlenül (gyorsabb) kötöm a donorra.

* Én egy indián vagyok. Minden indián hazudik.

cat /dev/vg/home | ssh root@host "cat >/dev/vg/home"

elotte csatold le. ha tomoriteni akarod mehet gzip-en keresztul

neked aztan fura humorod van...

Biztosak vagyunk benne, hogy lvm? Biztos, hogy a cél partició csak erre szánt önálló partició? Biztos, hogy a forrás partició, és cél partició mérete azonos, vagy hogy kedvünk van filerendszer méretekkel macerázni utólag? Biztos, hogy áttöltés közben nem szakad meg?

De ha ez mind tuti lenne, akár jó ötlet is lehetne. :)

"A megoldásra kell koncentrálni nem a problémára."

Én valamikor 1997-'98 táján lvm-eztem először - aztán izgatottan vártam, mikor fog valami hasonlót tudni a Linux is. És nem, nem bonyolítja, hanem kényelmesebbé teszi az életet - mondjuk desktop-on ahol van egy /boot egy swap, meg "a többi", mint / ott irreleváns, de ha ennél nagyobb a feladat, akkor azért naaagyon hasznos tud lenni.

Épp most kezdek visszatérni a régi felállásomra - szerver, sima tükrözött RAID1 tömb, a munkaállomásokon 120G SSD, minden ami munka az megy a szerverre, minimális lokális munkaterülettel.
Gondolkodom a dual booton (windows+ Linux) de a windows 10 makacs frissítési problémái miatt egyelőre inkább egy másik diszk.
A lényeg ebben a felállásban teljesen értelmetlennek tűnik az LVM. A szerveren 1-2T nekem és a nejemnek (levelezés, tárterület, közös terület) bőven elég. Mire lenne jó így az LVM?
(Lehet nem értem a hozzászólásodban a magyarázatot aminek vége, hogy "naaagyon hasznos tud lenni")

* Én egy indián vagyok. Minden indián hazudik.

Desktop-on nem fontos - bár jó tud lenni ott is, ah pl.külön diszken van az OS meg a /home (adatok), és a home-ot nagyobb diszkre akarod migrálni - oké, rsync és umount/mount móka működik, de egy pvmove sokkal "szebb" :-)
Üzleti/céges környezetben meg, pláne virtualizált gépen egyértelműen hasznos: fogytán a hely a diszken, vmware-ben megnövelema  diszket, néhány jól irányzott echo, egy pvresize, egy lvextend, és ott van a plusz terület. Ezt sima partíciós bűvöléssel vagy sikerül, vagy nem...

A legtöbb Linux telepítő automágikusan létrehozza neked az LVM-es layoutot single diskre is, sőt a jobbak akár be is titkosítják neled LUKS-al (mint a Manjaro). Az LVM azért jó mert ha kiderül hogy sok helyre van szükséged, bepasszintasz egy plusz disket a gépbe, és egy mozdulattal megduplázod a free space -t úgy, hogy logikailag ugyanúgy pl. egy nagy / fájlrendszered van. Tehát az LVM egyfajta hibatűrés nélküli RAID.

Sok kis file esetén az scp felejtős, ott ez a jó root-ként kiadva:

cd /blabla; tar -cf - ./ezt | ssh user@host "tar -xf - -C /blabla/"

A nagy kérdés, hogy leállhat-e a szolgáltatás a másolás idejére. Ha nem, akkor rsync, esetleg előbb tar | ssh majd aztán rsnyc.

Ha leállhat, akkor le kell csatolni, esetleg egy --remount ro után lehet a block device-t másolni dd-zni és "on the fly" áttolni az új vasra, és ott image-ként menteni (feltételezem, hogy az új helyen bőven van hely), majd ott helyben felcsatolni és kimásolni. Így szekvenciálisan olvasod a vinyót, nem számít hogy mennyi kis file van, szinte biztosan a net lesz a bottleneck. A tömörítés opcionális, kisebb mintán le kell tesztelni, hogy gyorsít vagy lassít-e a folyamaton. A dd helyett még a partclone is bejátszhat, az - ha minden igaz - nem viszi át a nem használt területet.

Nekem legutóbb élesben kellett átvinni levezést, ott először a user-t a sudoers-ben nopasswd root-ra tettem, majd a

cd /blabla; tar -cf - ./ezt | ssh user@host "sudo tar -xf - -C /blabla/"

utasítással toltam át a nagyját, aztán leállt a postfix/dovecot, utána jött rá rsync.

Tulajdonképp itt látszik milyen jó dolgom van (egyelőre). Hétvégén (holnap) szépen elkocogok az irodába, leállítom a fethcmail -t (csak az termel újabb állományokat), még egy gyors rsync a lokális backup diszkre. Majd átdugom, felmásolom és beizzítom a többi csomagot ha minden jól megy néhány óra alatt megvagyok :)
Lesz egy nagyobb csörtém az openvpn -el, de az ráér (egyelőre).

* Én egy indián vagyok. Minden indián hazudik.

bár nem olvastam végig az egészet, de szerintem blocksync lesz a barátod.
ez képes rsync-hez hasonlóan átmásolni az egészet SSH-n keresztül, majd csak a változásokat.

Azaz ha egy élő rendszert akarsz átvinni, akkor sync-eled az egészet - mire minden átér addigra "természetesen" lesz változás.
majd leállítod a szolgáltatásokat a forrás gépen, blocksync megint (itt már csak az időközben változott blokkokat viszi át) és a célgépen
fsck, mount után már indíthatod is a szolgáltatásokat.

https://www.ullright.org/ullWiki/show/blocksync-py
 

Ez érdekes! Először meglepődtem, van új a nap alatt. Aztán kiderült ezt a virtuális gépek, nem virtuális mozgatására készítették. Szép.
OFF: Alapból nem szeretem a Python scripteket. Ahányszor próbálnék velük valamit folyton beleszaladok, hogy valami elavult, nem kompatibilis verzió.

* Én egy indián vagyok. Minden indián hazudik.