SSD-ről klónoznék át Ext4-re telepített Arch Linuxot másik SSD-re, csak a / partíciót. Egy másik topikban locsemege kolléga az rsync -avHASX /forras /cel parancsot ajánlotta. Ezzel így tényleg működik, vagy figyelnem kell még valamire? Az rsync man-ja emlegeti még az -s kapcsolót is, amely a fájlnevekben a szóközt őrzi meg, ez tényleg szükséges? Nem szeretnék szívni azzal, hogy mikor állítom vissza a rendszert, akkor bootoláskor derüljön ki, hogy nem működik.
Lehet még azzal cifrázni, hogy mindjárt mentéskor Tar Gizibe csomagolom az rsyncelt fájlokat? Vagy ami még jobb, úgy működne, hogy először tar -czf /forrás /cél paranccsal csinálom a backupot, megőrizve a hard linkeket, jogosultságokat, egyebeket, és akkor nem kell rsync sem, nem ragaszkodnék hozzá.
Az EFI bootot megoldom, és a PARTUUID-t módosítom az EFI loaderben, az nem okoz gondot.
Hozzászólások
Őőő, vagyis ahogy nézem, a tar jobb lenne így elvileg, de javítsatok ki, ha tévedek:
cd /
tar -cvpzf --one-file-system /cel/backup.tar.gz
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum
Imagebe való mentésre tar helyett inkább fsarchiver-t használnék. http://www.fsarchiver.org/
Van hozzá TextUI-s bash frontend is, MBR backup és restore funkcióval kiegészítve: http://zolli.altervista.org/fsa_dial/
Régebbi thread: http://hup.hu/node/149429
--
Légy derüs, tégy mindent örömmel!
Annyiból jobb a sima tar, hogy létrehozol egy sima ext4-es fájlrenszert bármekkora tetszőleges mérettel, és miután kicsomagoltad a tar.gz-ből a root fs-t akkor csak egy sima grub-install, /dev/sdx majd egy install-grub -o /boot/grub/gruvb.cfg-vel felrántod a boot loader-t és van egy sima belakott renszered. Ha nagyon regaszkodsz az UUID-hez ami létrejött korábban, akkor lehet úgy konfigolni az mkfs.ext4-et, hogy az az UUID-t kapja a partíció ami jó, így nem kell bónuszként az FSTAB-ot hegeszteni :D
Nekem is ez a legszimpatikusabb megoldás, ahogy nézem a tar mindent megőriz, hard-lineket, jogosultságokat, stb.. GRUB nem kell, helyette systemd EFI boot van EFI partícióról, ezt is klónozom. Megcsinálom ezt az UUID-s állítást is, és akkor fstabot meg EFI bootolási beállításokat sem kell módosítanom. Persze azért két backupot csinálok, egyikek CloneZillával.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum
Az fsarchiver file alapu imaget készít és gond nélkül visszaállítható kisebb nagyobb particióra, tudja kezelni a fájlok és a fájlrendszer attributumait is (pl. inode size, label, uuid, xattr). Szerintem klónozáshoz a tar-nál jobb választás..
--
Légy derűs, tégy mindent örömmel!
Neve alapján pont erre való, biztos kihozták belőle mindent amit lehet.
Egy visszaallitasi teszt (és ennek eredménye) érdekes és fontos lehet.
Az rsync tényleg működik (akinek kell a GUI, az is van hozzá, a Grsync), de használhatsz ddrescue-t is, vagy akár CloneZillát is.
GUI-hoz nem ragaszkodok. CloneZilla eszembe jutott, de a célpartíció nagyobb lesz, mint a forráspartíció, az nem lehet gond?
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum
Nem, csak fordított esetben lenne gond.
Az rsync man olvasas jo irany, de lapozz lejjebb a kapcsolokhoz.
Tudomasom szerint alapertelmezetten nem orzi meg a symbolic/hard linkeket es egyebeket, erre kulon kerni kell -- figyelj ra!
Azért van a -a:
-a, --archive archive mode; equals -rlptgoD (no -H,-A,-X)
Ezt el is felejtettem kérdezni, pedig a man-ban szemet szúrt. Az -a kapcsoló ilyen formán ellentétes a -HAX kapcsolókkal, valamelyik felesleges. Nem lenne elég a -vHASX? A hard linkeket a -H őrzi meg.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum
> Az -a kapcsoló ilyen formán ellentétes a -HAX kapcsolókkal, valamelyik felesleges.
Nem ellentetes, semmi koze hozza. Az -a ugyanazt csinaja, mintha kiadnad az rlptgoD mindegyiket. Hogy ezen kivul meg milyen mas opciokat adsz meg (akar HAX kozul) az a te dolgod.
(Egyebkent ennyi ido alatt mar at is dd-zhetted volna, azzal biztos nem losz melle. Es meg a boot loaderrel sem kell tokoreszned. A particiot es a filerendszert pedig egy-egy mozdulat (es pillanat) kiterjeszteni a device vegeig.)
Nem vagyok vérrendszergazda, szóval lehet nem mondok okosat, a többiek majd kijavítanak max.
Szal az lenne a kérdésem, hogy nem gondoltál sima dd-re?
De, gondoltam a dd-re, és még tömöríthető is, de ott látom problémásnak, hogy a célpartíció nagyobb lesz, mint a forráspartíció. Ugyanezért tartok a CloneZillától is.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum
Kicsit most megint csak vakon lövök, elméleti szinten mert gyakorlatban még nem csináltam ilyet.
DD-vel leklónozod a partíciódat a másik vinyóra, egy az egyben (ugyanakkora partícióra). Tehát ugyanakkora lesz.
Utána mivel nagyobb célpartíciót szeretnél, elvileg van lehetőség extendelni nem? Winfos alatt is lehet ilyet, tuti lehet linux alatt is. Kigooglezném, de ezeket gyakorlatban kell kitesztelni. Én egy kicsi virtual gépben próbálgatnám ki.
Nem akarok utána partícióátméretezéssel bajlódni, bár elvileg így is működne. A dd-vel az a bajom, hogy lassú, menti az üres helyet is, nem rugalmas megoldás. A virtuáls gép viszont jó ötlet.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum
Nekem bent rendszergazda kolléga segített amikor a 120GB-os ssd-met leváltottuk 240-esre. Rákötötte egyik szerver gépre a cuccot és kb 30 perc alatt lementette mindet. Nyilván függ a géptől is. Nem tudom, hogy mekkora helyet kell mentened, azért ssd-ről nem olyan marha lassú a másolás.
Noh, de nem akarom erőltetni majd eldöntöd, a dd lassú, ez a hátrány, viszont bitre pontosan átmásol mindent, ez nagyon nagy előny.
A dd-t vésztartalékos megoldásként vetem csak be. Abban igazad van, hogy SSD-ről SSD-re gyorsan lefut, de azért nem ártana, ha a mentés mérete is minél kisebb lenne.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum
Erre csak annyit jegyeznék meg amit te is mondtál, hogy tömöríthető, hisz az üres helyet egy image fájlból jól lehet tömöríteni.
Jó példa erre az amikor egy 8GB-os sd kártyát mentettem le image-ba. 8GB lett, de tömörítve alig 1-2GB.
Azt nem is írtam, hogy nem közvetlenül SSD-ről SSD-re mentés lesz, hanem lesz egy köztes HDD-s lépcső, az meg lassú, és csak kb. 200-300 giga szabad helyem van.
Majd persze idővel veszek egy SATA-USB átalakítót, a jövőben ilyen helyzetekre, de most hétvégén köztes HDD-s lépéssel tudom csak megoldani.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum
mekkora tárhelyet szeretnél leklónozni?
Van infód az ssd-hdd mentés sebességedről?
Meg nem mondom neked, hogy de elvileg meg lehet nézni, hogy mennyivel másol. Utána kiszámolhatod, hogy mennyi idő. Ha végez az éjszaka alatt, akkor már jó.
De egyébként jó a targz is, csak a dd szerintem precizebb, ezért hoztam fel.
Egy 50 gigás linuxos partíciót, egy 100 megás EFI partíciót, meg egy 250 gigás Win10 partíciót (ez utóbbi egy HDD-n van). Egyik sincs tele (110 giga körül van összesen), csak a sebességet vissza fogja fogni a HDD, ráadásul USB2-es külső HDD, de nem lesz vészes, nem olyan rettenet sok giga, egy éjszaka alatt le fog menni. Ha nem lenne a Win10-es partíció (ezt azért mentem, mert vannak rajta megkezdett játékok, amiknek a mentéseit nem tudnám külön elmenteni), akkor csak 9 GB körüli SSD only adatról lenne szó mindössze.
A Win10-es partíciót mindenképp CloneZilláznám, mivel az is nagyobb lesz, mint eredetileg volt. Meg ahhoz majd kell más is, hogy bootképes legyen, ennek utána fogok nézni. A Windows háklis tud lenni.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum
először is jól teleirom
sudo dd if=/dev/zero of=/zero
ha elfogyott neki a hely sudo rm /zero
osztán bele neki egy olyan USB drive, amin van elég hely és
dd bs=32M conv=sync,noerror if=/dev/hda | gzip -c > /media/removable/akarmi.img.gz
elmegy kávét megisz, majd
gunzip -c /media/removable/akarmi.img.gz | dd of=/dev/hdb
ez kicsit matatni fog, de ha lefutott, az usb drive-ot lehet jól elrakni a polcra, kellhet még valamire és jöhet a
gparted
Itt most jó, amit írtál, de más körülmények között az első dd után kiadnék egy sync parancsot. Akkor, ha az lenne a cél, hogy magára a fizikai eszközre is valóban kiíródjanak a nullák, s ne csak a disk cache-ig jussanak el.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Jogos. Plusz még, hogy ha Windowst akarnék klónozni (minek?) akkor inkább a Windowsban csinálnám (sdelete) mielőtt bebootolok valami stickről egy Linuxot.
Már kismilliószor csináltam így:
dd if=/dev/sda of=/dev/sdb
ezzel a teljes lemezt, minden partícióval, mbr-rel átmásolom, tehát ha beteszem az újat, kiveszem a régit akkor pont ott folytatja, ahol abbahagyta
A megmaradt területet ezután gparted-del szoktam kiigazítani. Ennyi, egyszerű, nagyszerű.
sub
Sic Transit Gloria Mundi
Alapvetően a clonezilla is dd-zik. Viszont nekem a sima sda/sdb dd azért nem jó, mert annál csak a legutolsó partíciót tudod kiigazítani, meg elmenti az üres helyet is (jó, igaz az jól tömöríthető), meg a fájlrendszer töredezését is. Nekem meg a közbülső partíciók mérete is nőtt. A tar.gz-és meg gyorsabb, fájlszinten is visszahúzható (csak bizonyos fájlok), nem töredezett, akármekkora partícióra visszamásolható.
[=9]„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum
Egyes operációs rendszereknél van backup és restore parancs.
Másoknál meg fórum van. ;)
dump/restore itt is van, csak úgy tűnik, mindenki elfelejtette. Meg ezen az operációs rendszeren nem kell túlbonyolítani, működik az rsync is.
Talán erre gondoltál?
dump - ext2/3 filesystem backup
Inkább az AIX mksysb-t említeném. Ezzel keletkezik egy bootolható mentés, ami - adott esetben - tetszőleges más hardverre is installálható, gyakorlatilag klónozásnak felel meg. Az rsync talán egy modernebb (??) megoldás, míg a klasszikus a cpio vagy a tar. Ilyenkor felmerülhet a kérdés, hogy pl. az acl-eket melyik is viszi át? ;)
Ezzel szemben - mint a végén láthatod - a gyakorlati megoldás a copy lett. :)
Arra, de ext4-en is működik. Nyilván csak fájrendszert ment, a partíciókat/bootolást nem oldja meg.
A cp-nek az rsync-kel ellenben az a baja, ha megszakítod a folyamatot, kezdheted elölről.
Megszólítva érzem magam. :) Azért használtam rsync-et, mert az oprendszer lényegesen kisebb, mint a teljes filerendszer, továbbá, ha a filerendszert költözteted, költözik a töredezettség is. Jó, ez SSD-nél lényegtelen, de HDD esetében érdekes lehet. Az én esetemben az is szempont volt, hogy ext4-re formázott pendrive-on el tudjam ezt intézni. A -s paramétert valóban nem néztem, de nem állítom, hogy világos a szerepe. Az argumentumban nem esik szét a paraméter szóközök mentén? Ugye eredetileg a szóköz a shellnek speciális karakter, ez aposztrofban, idézőjelben vagy backslash-sel escape-elve litárilsként átadható. Akkor valamiért a literálisként átadott szóközöket maga az rsync szétszedné több paraméterré? Ha igen, miért, hiszen egyben kapta meg? Vagy a ténylegesen feldolgozandó filenevekben lévő szóközökről lenne szó? Ezt azért erőst kétlem. Valaki, aki sokat használ rsync-et, mondja el nekem a -s pontos szerepét, létezésének, szükségességének okát!
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
rsync -s -ave ssh "/tmp/vinni/" "user@szerver:/tmp/mappa szóközzel készült/"
Ennél látod a különbséget, ha -s elmarad. Lényeg, hogy az argumentumlistában levő szóköznél vágna a túloldali szkript.
Akkor megnyugodtam, nem kell az -s kapcsoló. Kösz az infót.
locsemege: reméltem, hogy megszólítva érzed magad. Alapvetően a Tar Gizis megoldást választottam, de a biztonság kedvéért a CloneZillás lemezképeket is elkészítettem. Most a Win10 partícióját menti a CloneZilla. Majd jelentek, ha sikerül visszaállítani a cuccost.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum
Kösz mindenkinek. Sikerült a klónozás tar.gz-s mentésből. A módszer működik. A rendszer beröffentéséhez kellett viszont még szerkeszteni a kernelparamétereknél a PARTUUID-t az EFI-partíción, meg az UUID-et a /etc/fstab fájlban.
Plusz mivel az Arch initramfs-t kötelezően használó disztró, berhelni kellett sajnos az /etc/mkinitcpio.conf fájlban a MODULES= részt, kellett bele a crc32c-intel modul, mivel anélkül nem bootolt Cannot load crc32 driver hibára hivatkozva. Ilyen modul nem kellett a 2. gen. i7-es procihoz, de kell a 3. gen. i5-höz, gondolom mert újabb architektúra és a kernel másképp kezeli. Az egészet meg kellett pecsételni új initramfs készítésével is: mkinitcpio -p linux
Kellett még szerkeszteni Archnál az /etc/hostname fájlt is, mert az a gép is fut, aminek a rendszerét klónoztam, és nem akartam névütközést a hálózaton, szóval ezen a másik gépen módosítani kellett. Sőt, még a NetworkManagerben is kellett állítgatni, az új rendszer alatt a Wi-Fi eszköz neve nem wlp3s0, hanem wlp2s0. Több teendő nem volt vele, de nekem ennyiből is elegem lett. Azt gondoltam, hogy mindkettő inteles gép (a CPU, GPU, Wi-Fi mind inteles), nem lesz driverprobléma, simább lesz az új rendszer életrekeltése.
A Windowst 10-et már Clonezillával klónoztam, és bár a klónozás sikerült, meg az átméretezés is (nagyobb lett a partíció, mint volt), a rendszer mégsem bootol sajnos, az EFI eldobja, és az Arch Linuxot bootoltatja helyette. Nincs hibaüzenet. Majd holnap még az EFI bejegyzéseket átszerkesztem, szerintem rossz UUID-n keresi a Windows-partíciót. Egyébként ez a clonezilla nagyon nem tetszett, elég amatőrre összeszögelt TUI-s program, nehézkes a kezelése, elég rugalmatlanok a menüpontok, körülményes beállítani mit akar az ember.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum
Bár megoldódott, de beírom, mert nem láttam, hogy a cp is pont olyan jó erre...
cp -auvx /forras /mentes
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
Ez egy érdekes felvetés, ilyenre nem is gondoltam. Viszont így adja magát a kérdés, hogy mi a különbség az rsync és a cp között funkcióban?
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum
Az rsync-et távoli gépek között is tudod használni, a cp-t csak helyi filerendszeren. Ha az rsync-et megszakítod és újraindítod akkor ott folytatja ahol megszakítottad, a cp előröl kezdi az egész másolást. Nagyjából...
Illetve az rsync biztosabb, mert az tudja törölni a már azóta megszűnt fájlokat, amik szintén tudnak galibát okozni.
--
"Sose a gép a hülye."
illetve az rsync tud delta transzfert, mig a cp mindent visz, mint a kama3...
Igaz, ez eszembe se jutott.
--
"Sose a gép a hülye."
Újabb helyzetjelentés: a Win10 továbbra sem bootol, pedig most dd-vel klónoztam, ugyanakkora partícióra, még a GUID, PARTUUID-k és az UUID-k is megegyeznek. Meg se nyikkan, ha pedig az EFI partíción kézzel csinálok neki bejegyzést, akkor pedig világos kék képernyős hibaképernyő jön fel, hogy nem találja a C:\Windows\System32\winload.efi fájlt, pedig az ott van az illető partíción.
Nem csak a Windows-partíciót klónoztam, de az előtte lévő 16 megás rejtett partíciót is bitről bitre, dd-vel, UUID-k ott is egyeznek, az EFI partíción a bejegyzések is ugyanazok. Szerintem azért nem bootol, mert a HDD-n az első partíció egy recovery partíció volt, ami most hiányzik, így a partíciók számozása más. Majd megjavítom Windows-telepítővel az EFI bootot, de bosszantó, hogy bitre pontos klónozással sem hajlandó indulni ez a májkrémszaftos kulahalom ugyanazon a gépen.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum
Nem lenne hatékonyabb az adatok mentését követően újra telepíteni az egészet?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
* Ha nem akarsz Windows-t újratelepíteni és linux alól végeznéd, akkor esetleg: http://www.fsarchiver.org/cloning-ntfs/
* Ha Windows alól gondolod akkor WinPE boot majd, dism/imagex/wimlib segítségével mentés wim-be majd visszatöltés (esetleg előtte sysprep és a végén újra aktiválás).
http://hup.hu/node/141243
http://wimlib.net/
--
Légy derűs, tégy mindent örömmel!
Végül is elteszem ezt a címet is, de nem nagyon vágom, hogy ez miben tud többet, mint egy bitpontos másolatot készítő dd parancs.
Amúgy sikerült megjavítanom a Windows 10 telepítőjével az EFI-bootot. Kiválasztottam a nyelv, billentyűzet megadása után, hogy Repair Your Computer majd ott egymás után kiválasztva: Troubleshoot, Advanced Options, Command Prompt.
Az így nyitott javítókonzolban:
diskpart
sel disk 0 (nálam az első és egyetlen lemezen van a Win)
sel vol 2 (az EFI partíció a harmadik, de furmányosan, 0-tól számozva a második, list vol paranccsal ellenőrizhető)
assign letter=F: (megkapta az első szabad betűjelet)
exit (kilépés a diskpart programból)
cd /d F:\EFI\Microsoft\Boot\
bootrec /rebuildbcd
itt ki kellett választani 1-essel a meglévő Windows-telepítést
exit (kilépés a javítókonzolból)
Gép újraindítása után jó lett. Azért kemény, hogy az 1 perces HDD-s bootidő lement 5-6 másodpercre SSD-vel. A javítókonzolba még próbálkoztam előtte a bootrec /fixboot paranccsal is, de azzal nem lett jó.
Szerk.: Lemezkezelővel átméreteztem a Win 10 partícióját, így már kitölti a neki fenntartott szabad helyet. Akinek így nem menne, lehet próbálkozni a gparteddel is.