dd merevlemez klónozás

Segédprogramok

sziasztok,

szeretnék átklónozni egy 500 GB-os merevlemezt egy teljesen azonos méretű másik merevlemezre

a "dd if=/dev/sdb of=/dev/sdd bs=8192 conv=notrunc" szépen lefut, de a végén mindíg csak kb 290+ GB adatot másol, szóval nem sikeres a klónozás

mi lehet a gond?

(a hdd-ken nincs bad sector, természetesen mountolva sincs egy partíció sem, ubuntu 12.04 ill. 12.10 live rendszerben próbáltam, az egyik merevlemezt eSata-n ill. USB-n is rákötve a PC-re...)

köszönöm a segítséget

  • 24989 megtekintés

( Refresh | 2012. 11. 27., k – 21:06 )

Addig is, míg valaki érdemben tud válaszolni, amerre én kezdenék kutatni:
- lehetséges-s, hogy az egyik diszk hagyományos, a másik ú.n. Advanced Format-ot használ? Ez nem okozhat gondot?
- Hogy nincs bad sector, az 100%? Én megnézném, hogy egy long selftest lefut-e mindkettőn? (smartctl -tlong /dev/sdb és ha lefutott, akkor smartctl -lself /dev/sdb mutatja meg az eredményt - kb. 1-2 órás futásidővel számolhatsz diszkenként)

Csak találgatok, mert ilyet még nem láttam. Igaz, én csak partíciókat klónoztam dd-vel, teljes diszket soha.

Nekem az egyébként döglött (smart selftest + garanciális szerviz szerint) diszken simán átment a badblocks, a selftest viszont következetesen megakadt két különböző szektornál. Ezért javasoltam inkább ezt.
bs=1M mennyivel jobb? (kérdezem, tényleg nem tudom) Fogalmam sincs, más rendszeren mi a helyzet, nekem a két SATA III diszk közti másolásnál 4096-tal is max. sebességet produkált.

Az egész elég érdekes volt.
Kezdődött azzal, hogy a smartctl -A kimenetében 100 fölötti íráshiba jelent meg.
Akkor próbálkoztam selftestet futtatni, a short lement, lenullázta az íráshibákat, a long megakadt. A windows alól indított short teszt is megakadt, de másik blokknál. Attól kezdve linux alól sem futott a short, de a hibás blokk (LBA) következetesen ugyanaz maradt. Tesztelgetés közben vettem észre, hogy a korábbi "pending" szektorok száma felment 0-ról 400 körülire. Aztán csökkent, majd megint nőtt...
Ez után próbáltam a hibás szektor környékén a badblocks-t futtatni, de nem jelzett hibát. Azóta sem értem az egész történetet, a szervizből meg még várom, hogy visszaszóljanak, mit sikerült a szállítójukkal intézni. Egyébként az sem lehetetlen, hogy a diszknek semmi baja nem volt, csak az elektronikája mondta be az unalmast.

( Fisher v | 2012. 11. 27., k – 21:11 )

Ha nem ragaszkodsz a dd-hez, akkor a Clonezilla segíthet.

( zeller | 2012. 11. 28., sze – 09:18 )

Mount forrás, fdisk cél, mkfs cél, mount cél, rsync, örül.

Ezzel az a baj, hogy sehol sem írta, milyen adatok vannak a klónozandó diszken.
Pl. egy windows-t nem biztos, hogy jó ötlet rsync segítségével másolni. De javíts ki, ha rosszul tudom! (gondolnék itt olyasmire, mint ACL-ek és hasonlók, amiket tudtommal a linux nem kezel)

Egyébként mi bajod a dd-vel? Alaphelyzetben annyit tesz, hogy bitről-bitre másol, vagy nem?

Attól függ. Ha a forrás és cél tökéletesen egyforma médium, akkor jó lehet a dd. Viszont ha eltérnek, akkor problémák lehetnek. És nem arra gondolok, hogy 500G ->1T, hanem 500G->500G, de mégse egyezik minden pontosan. Vagy van a disken egy marék hibás blokk, amin épp nincs fs (vagy adat).

A másik dolog, hogy a legtöbb esetben felesleges a bitre pontos másolat. Bőven elég ha pl. a használt adatterületet másolják át, az üresen maradt helyet meg nem. Szóval jó az a dd, de nem minden esetben a legjobb választás.

Windows-t,pontosabban ntfs-t valóban nem a legjobb ötlet akárhogyan klónozni, merthogy a partíciókat helyre kell rakni, ha eltérő a geometria, fixboot, fixmbr köröket meg kell futni (esetleg a windows telepítővel a helyreállítást is...) Windowst szerintem célszerűbb backup a régi, telepíteni egy minimális verziót (azonos SP-vel!) az új diszkre, aztán restore, és örül.

No, akkor elmesélem itt is (telesírtam vele a fél internetet korábban :) )

Szóval viszonylag friss tapasztalataim vannak a dd-vel történő klónozással.
Nem egészen két éve kellett egy 500-as Samsungról egy 1TB-os WD-re költöztetnem a windows-os cuccaimat és jobb ötlet híján azt csináltam, hogy bájtra azonos méretben létrehoztam a partíciókat az új diszken, dd-vel rámásoltam a windows-os partíciókat, utána boot az XP telepítőről, fixmbr és öröm é bódottá... :)
Pár hete az akkori diszkem döglött be, csak egy linuxos fájlrendszeren volt hely, belemásoltam a még működőképes partíciókat dd-vel egy-egy image fájlba, majd mikor megjött az új diszk, szépen vissza a helyükre. Ja! A struktúráját elmentettem egy sfdisk -d segítségével.
Legnagyobb meglepetésemre egy fixmbr után vidáman bebootolt az XP, egy darabig fűrészelt a diszken, de úgy egyébként magához tért és működik. :)

rsync-kel egy gondom van: valamikor sok éve, amikor még dolgoztam, valamit nagyon bekavart a jogosultságoknál egy alkalommal... (talán ACL-ezve volt a rendszer?) Azóta picit tartok tőle, de már többen tudják, hogy pszichiátriai eset vagyok ;)

( mspike | 2012. 11. 28., sze – 12:31 )

próbáltad ezt " conv=notrunc" elhagyni ? Neked pont nem kell ez most. Persze ártani nem árthat alighanem...

A másik, biztos vagy benne, hogy mind kettő egyforma méretű ?

fdisk-el megnézve ugyan az a méret ?

( Pingvinpasztor | 2012. 11. 28., sze – 15:55 )

cat-tal szoktam ... //bootolok cd-s valaminuxról, és cat sdb > sda // ... nincs ellenőrzési lehetőség a maszatot is gondolkodás nélkül ráírja
csak akkor m1, ha a merevlemezek, lapok stb.. chip verziószáma is szögre passzol, 1ébként hanyattvágja magát ...
ja és sokáig tart, és melegszik a vas, fujatni szoktam valami szobaventillátorral a hdd-ket
// így is kevesebb idő mint 0-ról rakni a vindózt + frissítgetni + telepítgetni a felhasználói programokat, a végén csak nevet,
munkacsoportot, ip-t állítasz oszt jónapottttt :):):) //
_____________________
www.pingvinpasztor.hu

( apostroph3 | 2012. 11. 28., sze – 16:11 )

sudo apt-get install gddrescue

sudo ddrescue -r3 /dev/hda /dev/hdb /tmp/ddlog

man ddrescue sokat mond, esetleg ddrescue wiki
vagy ilyesmi:)

de akár letöltheted a window$ ERD 7-et, bár ahhoz kellene talán még egy jó nagy merevlemez. azzal készítesz egy teljes bacup-ot, és az új hddre 'visszaállítod' - nem emlékszem klónozni tud e -

... vagy fájlonként rekurzív könyvtárbejárással dd_rescue... utána meg egy boot-szektort még átbiggyeszteni...

(
... mindig az mc-ből fut a legtöbb szál...
http://www.pvtv.hu/tarolo/out_files/kepernyokep4.png
)
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

( sztomi v | 2013. 02. 06., sze – 11:28 )

vegulis ott volt a gond, hogy a forras merevlemezen bad sector volt...

egy seagate seatools-os check utan mar minden ok volt (ha jol tudom, "relokalta" a bad sectort...)

(sz)Tomi

( knzoltan | 2013. 09. 01., v – 21:33 )

Sziasztok, szoktam tesztelgetni a dd paranccsal, gondoltam megkérdezem, hogy mi a különbség a 2 parancs között a végeredmény tekintetében:

dd if=/dev/sda of=/dev/sdb

cat /dev/sda /dev/sdb

Mindkét esetben átmásolja az adatokat ugye?
Természetesen a dd-t felparaméterezném még (bs=1024 stb.)

Pl le lehet menteni az mbr-t cat tal is? Fel lehet paraméterzni a cat ot is úgy, hogy csak az első 512 bájtot másolja, és utána álljon le?

-- Zoli

Átmásolhatod a diszket `cat'-tal is. A `cat' nem kifejezetten blokk műveletek végzésére van kitalálva, ennek megfelelően nem tudsz neki I/O blokkméretet, blokk darabszámot, (stb.) megadni.

A diszkek I/O sebessége jellemzően lényegesen alacsonyabb, ha az optimálisnál kisebb blokkmérettel írod/olvasod őket, ezért valószínűleg a `cat' lassabb lesz, mint egy (megfelelően felparaméterezett) `dd'.

A Linux kernel nem túl finnyás, és engedi a blokk eszközöket mindenféle (adott esetben nem optimális) blokkmérettel írni/olvasni. (Egyes UNIX variánsok kapásból elhajtanak a francba, ha nem megfelelő blokkmérettel kérdezed az eszközt - ott a `cat' nem lesz alkalmas ilyen jellegű klónozásra, csak a `dd' megfelelő `bs' opcióval.)

Az 512-nek semmiképp (pedig ez a default), a 4k-nak ott lehet, ahol egy cilinderen 8 szektor lakik.
Ha ismered a disk fizikai karakterisztikáját, akkor az átlagos szektorszám cilinderenként az az érték, ami neked kell, és ezt szorozd fel 512-vel.
Akkor a legoptimálisabb ugyanis a disk írás/olvasás, ha egy cilindert egy lépésben végigírsz/olvasol.
Persze, ha szar a disk, és a S.M.A.R.T minden cilinderen áthelyezett már egy szektort a disk valamely másik részére, akkor a lineáris olvasásnak vastagon lőttek, de ez már nem a paraméter hibája.
--
PtY - www.onlinedemo.hu

Fizikai címzés != logikai címzés.
FS szinten logikailag címzel, dd esetén, ha blockdevice-t használsz, irreleváns, hogy az FS milyen szektormérettel operál.
A fizikai disken 1 szektor = 512 bájt, de ha szektoronként olvasol/írsz, akkor szinte mindig újra meg kell várnod, míg a disk tesz egy fordulatot. Ha meg egyszerre többet olvasol, akkor optimálisabb.
Olyan disk, ahol 1 szektor van egy sávon nem létezik. Olyan sem, ahol 8.
Lemezgyártók oldalain nézhetsz számokat.
--
PtY - www.onlinedemo.hu

Itt leírtam.
Egyértelműen fizikai karakterisztikáról beszéltem. Amit lekérdezel, evvel köszönőviszonyban sincs.
A diskeken már jó ideje több szektor találhatóa külső trackeken, mint a belsőkön. Ennek köszönhető az is, hogy ha pl. dd-vel klónozol, miért lassul az átvitel folyamatosan.
Ha pl. raidet csinálsz, ott is érdemes úgy meghatározni a chunkok szélességét, hogy az átlagos szektorszámnak megfeleljen. Vagy, ha tudod, hogy a disk soha nem lesz tele, és pl. 2/3-ra optimalizálsz, akkor lehet játszani a számokkal.
Igaz, a modern vezérlők sokszor nem engednek sok választási lehetőséget, ilyenkor meg végig kell tesztelni, hogy hol a legjobb a performance.

Raid esetében persze vigyázni kell, mert ha sok a disk, és nagy a chunk, akkor egy írással végigírod a teljes lemeztömböt, és apró fájloknál sok időt tudsz elveszteni vele.
--
PtY - www.onlinedemo.hu

Nem is az fs clustereire gondoltam, hanem arra a címezhető valamire, amit fizikailag elérünk, az LBA-ra. Az más kérdés, hogy az eszköz intelligens, bufferel, így lényegében ez is elfedésre kerül. Amúgy a disk cache miatt már a kernel által is részben.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Pont az ellenkezőjére gondoltam. A HDD egy mezei desktop PC-ben van, majd jön a villámcsapás, s 22 kV-os oldalon a túlfeszültség levezetőben a villamos ív rövidrezárja a hálózatot, s a megszakító működésbe lép. Azaz előre bejelentés nélkül megszakad a delej.

Ugye, a gondom ezzel az, hogy a kernel hiába hiszi, hogy kiírta a tranzakciós naplót, flush-ölte a disk cache-t - ami a RAM-ból van allokálva -, az adat átment a SATA kábelen, viszont még csak a HDD-n lévő cache-ben van, nem pedig a mágnesezhető rétegen, a fizikai diszken.

Na, ekkor mi van? Már azon túl, hogy sz.pás.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mondom: úgy tudom (könnyen leet, hogy rosszul), a desktop diszkekben is van annyi tartalék a kondenzátorokban, hogy ha elmegy a betáp, akkor a cache-ben lévő adatokat még gyorsan kiírja.
Ki nem próbáltam, meg hát erre van journalozó fájlrendszer és az olyan apróságok, hogy ha nincs szünetmentesed, akkor ilyen esetekben számolhatsz némi adatvesztéssel.

locsemege azt írta, hogy ha becsap a villám és ez lecsapja a biztosító automatát. Ilyenkor talán még van rá esély, hogy a villámáram ( :D ) nem éri el az eszközeidet.
Journal FS nem véd az áramszünetből eredő adatvesztéstől, csak a fájlrendszer konzisztenciáját védi.

Én sem arra céloztam, hogy megmarad az adat, hanem hogy túléli a fájlrendszer.
Amúgy nagyon írás közben kell elkapni azt az áramszünetet, mert a disk cache azonnal ürül, ha a disk épp nem ír/olvas pár pillanatig.
Nem összetévesztendő a buffer cache-sel, ami OS szinten van.
--
PtY - www.onlinedemo.hu

Az a gondom a naplózással, hogy nem tudom, felkészült-e arra az esetre, hogy noha a kernel azt hiszi, kiírta a tranzakciós naplót, a dróton át is ment, de a mágneses réteg és a drót között pihen a HDD cache-ben. További kellemetlenség, hogy ennek a cache-nek semmiről sincs tudomása, így az egész csak akkor működhet, ha a journal hash-sel védett, netán duplikált, vagy egy régebbi állapothoz tud visszanyúlni a rendszer.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, épp ez a lényege. Hacsak nem bugos, akkor adatvesztésen túl nem lehet problémád.
Mondjuk én Oracle-lel szereztem ilyen jellegű tapasztalatokat, de a működési elv sokban nem különbözhet.
Meg kellene nézni, pontosan hogy működnek ezek a fájlrendszerek, de én úgy tudom, áramkimaradás nem okozhat nekik gondot.

Volt szerencsém olyan rendszerhez, ahol az adat legalább kettő független (vezérlő, storage doboz szinten is!) diszkre került kiírásra, és az írási művelet akkor lett kész az OS részéről, amikor a lassabb diszkről is sikeresen visszaolvasta(!) a kiírt adatot. Nem gyors, ellenben baromi lassú volt (és ezzel pont fordítottan arányos áron lehetett megkapni), viszont a rendszer felépítéséből adódóan ha az alkalmazás azt kapta vissza, hogy "írás kész", akkor biztos lehetett abban, hogy az adatok legalább két példányban a diszken csücsültek.

Ez tök' jó, csak akkor egy sync opcióval mountolt filerendszer már egyszerűbb. A disc cache alkalmazásának lényege éppen az, hogy RAM-ba megy az adat, az alkalmazás felé visszanyugtázzuk, hogy az írás megtörtént, a kernel meg elmolyol rajta, felhergeli rá a DMA kontrollert, ha ráér éppen, aztán kitolja a piros dróton az anyagot. Lehet, hogy 3 ms múlva, de lehet, hogy 3 perc múlva.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha adott egy 40GB os Seagate IDE-s merevlemez, amit szeretnék dd vel egy IDE/SATA - USB átalakítón kereresztül átmásolni abból a célból, hogy photorec-kel visszaállítsak képeket róla, akkor a dd-t Te milyen blockmérettel paramétereznéd fel?
2 ilyen merevlmezem is van, az egyikről sikerült 16GB nyi adator helyreállítanom egy barátomnak - boldogság van - viszont a másik HDD-val nem tudok mit kezdeni, valószínüleg szektorhibás. Próbáltam, conv=noerror,sync paraméterekkel 512 kb os szektoronként, de csak 130MB ot másolt át a dd egy image-be. Azt szeretném, hogy lépjen túl a szektorhibán - oda írjon be 0 kat, de másolja át az egész merevlemezt 1 db image be, hogy azt olvashassam a photorec-kel. Hogyan tudom ilyenkor meghatározni, hogy mik lennének az optimális dd paraméterek ebben az esetben?

-- Zoli

Kell, hogy boldoguljon! Amit nem tud leolvasni, azt átlépi, majd a hibás szektorokon annyiszor megy végig, amíg csak lehet. Ha már pl. 30-40 perce nem csökken a hibás adatmennyiség mutatója, nyugodtan megszakíthatod ctrl-c-vel.
Hidd el, ha az újabb verziót teszed is fel, ezen a tényen nem változtat. Nézd meg a changelogot, miben több, mint ami fent van. Ha nincs benne egy ilyen "Now can read the all unread sectors ever", akkor hagyd a csudába a fordítgatást :)
--
PtY - www.onlinedemo.hu

Fedorán van készen, binárisban. Amúgy forrásból legegyszerűbben úgy lehet fordítani, hogy kicsomagolod a forráskódot, a legfelső alkönyvtárban, ahol van configure, ott

./configure
make

Ezután root joggal ugyaninnen:

make install

Ami függőségként kell neki, annak a devel csomagja is legyen fenn, hiszen másképp nem fogod tudni lefordítani!

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezt tudom, de nem lehet így arch ra telepíteni a dd_rescue-t, mivel azt írja a ./configure parancsra, hogy nincs ilyen fájl.

Ezeket a fájlokat tartalmazza a mappa:
COPYING configure.in find_nonzero.c fmt_no.h
Makefile dd_rescue.1 find_nonzero.h frandom.c
README.dd_rescue dd_rescue.c find_nonzero_avx.c frandom.h
autogen.sh file_zblock.c fmt_no.c list.h

És a Readme nem szól arról, hogy hogyan kell telepíteni.

-- Zoli

Ha pl. fix méretű filet akarsz létrehozni, akkor én így szoktam:

dcfldd if=/dev/zero of=filenev.bin bs=1M count=3k
ez ugyebár 3 gigás file lesz, könnyebb számolni.

Lehetne truncate -s 3G filenev.bin is, de az copy on write filerendszernél más eredményhez vezet, ha az adott file pl. virtuális gép lemezkép.

( Komma | 2014. 03. 01., szo – 14:08 )

Sziasztok!

Hasonló problémám merült most fel, mint a topik nyitónak.

Adott két külső 500GB-os merevlemez.

Samsung S2 kb. 4-5 éves, TV-re kötve filmnézésre használták, a probléma, hogy RAW lett az NTFS fájlrendszer helyett, gondolom nem lett jól leválasztva, történt már hasonló probléma a köreimben. A Hard Disk Sentinel 14%-os kondíciót lát és kb. 385 bad sectort! Adat van rajta és nem is lenne rossz még megmenteni.

Lett mellé szerezve egy ADATA HV620, 500GB ez is.

Amit el szeretnék érni, hogy leklónozzam az eredeti sérült samsung-ot, vagy biztonsági mentést róla, hogy a másolatról valahogy lehessen adatot visszanyerni.

Ehhez nézegettem a dd-t meg a ddrescue-t.

Ehhez szeretném segítségeteket kérni, hogy milyen kapcsolókat érdemes ilyen esetben még használni, hogyan induljak neki.

A sérült samsung 1 db ntfs partícióval rendelkezett.
Az új adata 1db fat32 partícióval rendelkezik.

Előre is köszönöm a segítségeteket.

fdisk -l:

Disk /dev/sdb: 500.1 GB, 500107859968 bytes
255 fej, 63 szektor, 60801 cilinder, összesen 976773164 szektor
Egység: szektorok 1 * 512 = 512 bájt
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Lemezazonosító: 0x00000a21

Eszköz Indítás Eleje Vége Blokkok Az Rendszer
/dev/sdb1 * 32 976773119 488386544 b W95 FAT32

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 fej, 63 szektor, 60801 cilinder, összesen 976773168 szektor
Egység: szektorok 1 * 512 = 512 bájt
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Lemezazonosító: 0x06748563

Eszköz Indítás Eleje Vége Blokkok Az Rendszer
/dev/sdc1 2048 976769023 488383488 7 HPFS/NTFS/exFAT

Szívesen, és örülök neki, de azért mentsél, mert a jó HDD-re az olvashatatlan blokkok miatt itt-ott hibás adat, vagy sérült filerendszer kerülhetett, ami előbb-utóbb a használat során a filerendszer széthullásával, adatvesztéssel járhat. Szóval jó volna a fontos anyagot átmásolni valahova, ezután megformázni a jó HDD-t, ahova a rosszról klónoztál, majd a mentésből file-osan visszamásolni az anyagot, így már biztosan stabil lesz a filerendszered. Mondjuk az adatban lévő esetleges hibákon ez sem segít, de legalább nem romlik tovább a helyzet, és a filerendszer töredezettségét is elimináltad egyúttal.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Felmerült bennem néhány kérdés és gondolat.
RAW lett az NTFS fájlrendszer helyett - ez mit is jelent?
Hard Disk Sentinel -> kuka.
Samsung diszk -> kuka. Ez magánvélemény. :)
A ~500GB FAT32 partíció igen derék! Biztosan meg lehet csinálni, csak nem szokás.
A rossz diszket viszont először ki kellene javítani, ha pörög még. Utána elég a dd.
Erre javaslom a hdat2 programot, Ennek gondosan el kell olvasni a megjegyzéseit, mert néha az egyes funkciók le vannak tiltva. Általában a működőképes diszkről érdemes adatot menteni. (Az azért örömteli, hogy a dd_rescue nem foglalkozik a hibákkal, de nem tudjuk mi lesz a végeredménye. Aki ilyenben hisz, az használhatja a SpinRite programot, amely akár 2000 olvasás/szektor végeredményéből sakkozza ki, mi is van a szektorban.)

Mindenesetre többet tudnánk meg egy smartctl -A, illetve smartctl -x kimenetből!

A cél diszk egy picikével kisebb, de ez csak egy hibaüzenetet fog eredményezni.

Szia!

Valószínűleg kukás lesz a lemez, ez már el van könyvelve:), csak az adatokat, ha lehet leszednénk még.
500GB FAT32, gyári formázás az új hdd-n.
Windows lemezkezelő RAW fájlrendszert mutatott.

Easeus programmal elindítottunk egy keresést, általában ezzel oldottam meg a RAW partíciót, és múltkor gond nélkül vissza is nyertük vele az adatokat. De a mostani keresés érdekes eredményt adott, mert nem az eredeti állománynevek látszottak, hanem fájltípusra lebontva egy csomó állomány és "F0001" ilyesmi számozással voltak az állománynevek. Bár a fájlok megvoltak elvileg csak más néven, mert egy képet megnéztünk és az jónak tűnt. Keresés eredményét exportáltuk, hátha még azok is jók lesznek valamire.

A rossz samsung-ot megnéztem TestDisk-el, nem hajtottam végre partíciós tábla módosítást, mert e művelet közben szól a windows 7, hogy sérültek az adatok a samsung hdd-n, nem e akarom helyreállítani őket (párbeszédablak), peddig addig csak raw fájlrendszert mutatott a lemezkezelő. Hát mondom legyen, dolgozgatott kicsit és végül elérhető lett a hdd. Tehát bele tudtam lépni a sajátgépnél és láttam a könyvtárszerkezetét, próbából elindítottam egy másolást, de 900KB körüli sebességgel ment csak. És ekkor inkább hagytuk az egészet, gondoltam szerzünk egy másik hdd-t és arra átklónozzuk és onnan mentjük.

Hát nem túl jók az eredmények:
Error SMART Values Read failed: scsi error medium or hardware error (serious)
Smartctl: SMART Read Values failed.

Smartctl: Device Read Identity Failed: scsi error medium or hardware error (serious)

Most rádugva egy win xp-re lemezkezelő nem lát fájlrendszert és üresnek ítéli.

( akkos v | 2014. 03. 01., szo – 19:34 )

Végigolvasva ezt a sok sikertelen és sikeres variációt, igazán szerencsésnek érzem magam, hogy amikor pár hónapja először klónoztam teljes lemezt így:

dd if=/dev/sda of=/deb/sdb

akkor csont nélkül átment.

És a legszebb az egészben, hogy az sda egy 60gb-os ssd volt windows 7-tel, az sdb pedig egy 2006-os 80gb-os hdd, 3-4 badblock-al.

Utána csak gparted-ben átméreteztem az ntfs-t 80gb-ra, és azóta is vígan megy.

írásnál a badblock reallokálásra kerül, ha van még szabad fenntartott hely (vagy "megjavul" ha sikeres az írás), de a topic nem erről szólt, hanem bad sectoros winyó OLVASÁSáról, az meg egy másik téma. Amit te csináltál, az szerencse, de csak azért, mert a bad szektoros winyó nem volt mégsem teljesen hibás (futtattál utána badblocksot, hogy vissza is olvassa az egészet?:) )

nem, beraktam, ment, azóta rá se néztem. A felhasználó meg nem panaszkodott.

Nem is a badblockon volt a hangsúly, hanem hogy nekem hogyan sikerült mindenféle kapcsoló meg blockméret megadása nélkül ssd-ről hdd-re windows7-et klónoznom.
Annyi hogy igazából nem közvetlenül ment a dd, hanem először egy fájlba, majd onnan vissza. Bár szerintem ez teljesen irreveláns.

szerk.:oké, writeonly voltam, kétszer is. badsectoros a forrás.
Ettől függetlenül még érdekel, hogy pontosan minek kell bs-t megadni. Én sosem használtam, és nem volt belőle problémám.

"pontosan minek kell bs-t megadni. Én sosem használtam, és nem volt belőle problémám."
Próbáld ki: másolj át egy SD-t bs=4M-mel, aztán meg nélküle.
Az időt nézd a végén.

Problémád nem lesz belőle, ha ritkán csinálod, semmit nem számít, de napjában többször ismételgetni már megfontolandó.

( BlinTux v | 2016. 11. 25., p – 14:02 )

Lazán kapcsolódik, úgyhogy nem nyitok új topikot ez miatt:
Úgy néz ki nekem is szükségem lesz egy klónozásra, mert két gépben fel kellene cserélni a winyókat.

Tehát adott két SSD:
120 GB : Windows 10
  80 Gb : Üres

120-as winyót kellene a 80-asra klónozni.
Elfoglalt hely nem haladja meg a 80Gb-ot (30Gb foglalt) szóval a méret belefér.

Kérdés, hogy SSD-t mivel a legcélszerűbb klónozni?

(MBR partíciós táblát és NTFS filerendszert feltételezve)

Régi gépen: 

ntfsresize -s 70G /dev/regissdwin10particio
ntfsclone -s -o /mnt/net/backup/win10.simg /dev/regissdwin10particio
dd if=/dev/regissd of=/mnt/net/backup/boot.img bs=byteokszamaazelsoparticioig count=1

Új gépen: 

dd if=/mnt/net/backup/boot.img of=/dev/ujssd bs=1M
blockdev --rereadpt /dev/ujssd
ntfsclone -r -O /dev/ujssdwin10particio /mnt/net/backup/win10.simg
ntfsresize /dev/ujssdwin10particio

Örülsz :-)

Igazából úgy gondoltam, hogy On the fly klónozás, azaz winyóról rögtön a másik winyóra egy liveCDről.
Néztem ezt a clonezillát, elvileg tud ilyet.

Gondolom a másolandó winyónak nem eshet bajja, a másolat meg vagy jó lesz, vagy nem.
Csak nem akarok ezzel órákat szívni, ezért várok tuti ötleteket :)

A Clonezilla képes rá, de nem beginner módban. Meg kell neki mondani, hogy ne foglalkozzon a céllemez méretével (-icds).
Arra nyilván figyelni kell, hogy a forráslemezen ne legyen olyan partíció, ami olyan helyen kezdődik, ami túlmutat a célleméz méretén. Ha az esetedben a 120-ason van olyan partíció, ami pl. 90GB-nál kezdődik, akkor annak a másolása nem lesz sikeres.

( noorbertt v | 2017. 02. 05., v – 15:30 )

Nem nyitok neki temat, jo itt is..

Van egy hazi szerver ami allandoan fut, van mod arra hogy a rendszer particiot klonozzam? Akar ugy hogy valtozas eseten frissitse is magat a masolat?
A cel az lenne hogy ha meghal a rendszer ssd akkor kb csak cserelni kelljen es minden ugy fut ahogy volt.

Biztos, hogy a házi szerverben a rendszer partíción lévő "adatok" a legfontosabbak?
Gondolok arra, hogy a telepített csomagokat kb. bármikor újratelepítheted, nem hiszem, hogy arról kellene biztonsági mentés. Inkább a változtatott rendszerfájlokról (vagy akár az egész /etc/-ről) készítenék egy mentést ill. a telepített csomagok listájáról.

Szerk.: látom, a /var nincs külön szedve. Ebben az esetben esetleg egy mysql dump (ha fut egyáltalán mysql) is a mentendőek közé kerülhetne. 5-10 giga helyett kell mentened néhány megát. Ha nagyon kell, akár egy szkriptet is készíthetsz, amit ssd-behalás után lefuttatsz (telepíti a megfelelő csomagokat, bemásolja a /etc-fájlokat, újra létrehozza a mysql-adatbázist, stb.).

Nem ragaszkodom semmilyen megoldashoz. Az lenne a lenyeg hogy minden telepites es beallitas, service stb.. pontosan ugyan ilyen maradjon.

Nekem az is jo ha fel kell tenni egy friss ubuntu servert es onnan elinditani egy szkriptet. De itt mar kapasbol azt gondolom h mi van ha ossze fog akadni valami es nem lesz ugyan? pl ubuntu frissites miatt

(az hogy 100giga vagy 5mega nem szamit)

mi van ha ossze fog akadni valami

Akkor az az ubuntu csomagolóinak a bűne :)

A csomaglista lehet nem feltétlen automatikusan generált, úgy is megoldható, hogy a "végső felhasználásra szánt programokról" készítesz listát (a függőségeket meg a csomagkezelő elvileg megoldja), így talán kisebb eséllyel lesz akadás, pl. csomagok átnevezése vagy hasonló miatt.

Ha pontosan ugyanazt akarod visszakapni, akkor nyilván a teljes mentés (akár dd, akár rsync vagy bármi ilyesmi) a megoldás. Ha a rendszer működési váza elegendő, akkor az utóbbi jobb megoldás. Az utóbbi azért is lehet jó, mert azért a rendszert nem ártana frissíteni, már csak azért is, mert ha egy olyan csomagot akarsz telepíteni, ami eddig nem volt telepítve, ne fuss olyanba, hogy a rendszer már nem támogatott, csomagtároló már nincs is hozzá, stb.

Csomaglista mentése, /home /root /etc mentése - nagyjából ennyi elég, hogy helyrekalapáld a gépet. Vagy ha perverzen akarod csinálni, akkor telepítsd újra RAID1-re az egész motyót, és az egyik diszket, miután összeállt a szinkron, húzd le a gépről. Igen, ez nem lesz konzisztens másolat (mintha kihúztad volna a gépet a 230V-ból), de egy fsck-val el fog róla indulni a rendszer.

( BlinTux v | 2017. 09. 20., sze – 19:57 )

Én sem akarok új témát nyitni, szépen gyűlnek itt a különböző kérdések... :)

Nekem most olyan gondom lenne, hogy egy laptop winyót kellene klónozni egy másik, nagyobb winyóra.

A kicsi 20Gb-os, a nagy 40Gb.
Van a winyón működő DOS, Windows, Linux is, illetve FAT16, EXT3 fájlrendszer is.

A gondok ott kezdődnek, hogy egyszerre csak egyik lemez lehet a gépben.
Gondoltam bebootolok pendriveról egy linuxot és dd-vel készítek egy image fájlt a winyóról rá a pendrivera, majd kicserélem a winyót és visszaírom rá.
Noh itt kezdődik a másik gond, hogy ugye a dd pontosan akkora imaget hozna létre mint a winyó (20Gb) és ez nehezen férne rá egy 8Gb-os pendrivera :)

Gondoltam még rá, hogy tömörítem az image fájlt már készülés közben. De ebben az esetben rohadt lassan megy a másolás, hiszen egy 166Mhz es gépről van szó.
Fél napot ment, fogalmam sincs meddig haladt, de nem volt türelmem tovább várni :)

Tehát, szerintetek hogy lehetne megoldani a problémát?
Egyébként a winyón lévő adat maximum 1Gb, csak hát nincs kedvem az új winyót felparticionálni, felrakni újra az OS-eket, mert egy ilyen gépen az egy agyrém :)

Egyébként ez amolyan support gép, még régebbi gépekhez, pl. Commodore, szóval nem akarom jobbra cserélni, mert a célját tökéletesen ellátja, csak sikerült hozzá szerezni egy kétszer akkora winyót :)

> Fél napot ment, fogalmam sincs meddig haladt, de nem volt türelmem tovább várni

Van rá pár megoldás, hogy lásd, hol tart a folyamat:
https://www.cyberciti.biz/faq/linux-unix-dd-command-show-progress-while…

A dd mellett is van még egy csomó lehetőség a klónozásra, pl. gddrescue (van hozzá GUI is: ddrescue-gui), CloneZilla, Redo stb.
CloneZilla is, Redo is tud könnyen távoli gépre menteni.

( sigellef | 2017. 09. 20., sze – 21:45 )

dd_rescue | rescue_dd | ddrescue (ubuntu)

ddrescue -f /dev/sda /dev/sdb
így akkor is simán klónozza, ha van hibás szektor.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba