Pár gépet leselejtezünk, melyet ismerősök fognak elhordani. Szeretném legyalulni a vinyók tartalmát úgy, hogy lehetőleg más könnyedén ne férjen hozzá. Elegendő-e, ha törlöm az ntfs-partíciókat, majd ext3-ra felformázom a vinyót? Nem szeretném wipe-olni, mert akkor soha nem végzek, a fizikai formázás (nagykalapács) pedig nem játszik, mert egyben, működőképesen vinnék a cuccot.
Érdekelne, ki milyen megoldást szokott alkalmazni ilyen esetben?
--
sok válaszból sok jó infó, elleszek vele, köszönöm mindenkinek!
- 2785 megtekintés
Hozzászólások
masold parszor ra a /dev/urandom taralmat, de ez idoigenyes. Szerintem eleg a reformat egy atlag helyzetben.
--
Unix is user friendly - it's just picky about it's friends.
- A hozzászóláshoz be kell jelentkezni
egy ext3-ra átformázott hdd-ről pl. getdataback-kel még visszanyerhető az eredeti tartalom?
- A hozzászóláshoz be kell jelentkezni
Nem ismerem ennyire a fájlrendszerek felépítését, de az ntfs a lemez tetszőleges helyén tárolhat fájlrendszer infókat szerintem (nem kötött a másolat helye és mérete). Ha azt a részt pont nem írja felül semmi, akkor ezt felismerheti helyreállító program. Formázás általában nem szokott a lemez teljes felülírásával járni, csak a fájlrendszer infókat írja be a megfelelő helyre.
- A hozzászóláshoz be kell jelentkezni
A fájlrendszer infó ott lehet, ha mögötte már, amire mutat zagyva hülyeség van. Szerintem nem a file struktúra elvesztése a lényeg, hanem a tartalomé.
- A hozzászóláshoz be kell jelentkezni
elvétetted a lényeget :)
A particionálás/formázás általában csak a a particiós táblát és a fájlrendszert tartalmazó fő területet gyakja szét. Ettől még ott lehet biztonsági másolat a fájlrendszer adatairól valahol az adatterületen, amit ha megtalál egy helyreállító program, akkor nagyon könnyen visszaállítja a fájlokat. Szóval a lényeg, hogy formázással alapból nem csak a fájlok tartalmát hagyja a lemezen, hanem a fájlrendszer adatait is.
De még ha fájlrendszer infókat legyakta, akkor a raw adatokból is visszakaphatóak olyan fájlok/töredékek, amelyek ismert headerrel és formátummal rendelkeznek (jpeg, gif, doc ...). (pl fényképezőgépben törölt/formázott sd kártyáról sikeresen visszaállítottunk utólag képeket, pedig az fapados fat fájlrendszerű volt).
A /dev/zero -val felül dd-zés gyors és egyben biztonságos megoldás. Ezt sem biztos hogy vissza tudnák állítani kürt-ék, csak az adhatna egy nagyon pici esélyt, hogy ugyanazzal az értékkel lett írva minden - de ha jól tudom a merevlemez is az egymás utáni jelek változását rögzíti, nem pedig 1 és 0 értékek vannak sorba rakva -> így az adatfelületen komolyabb változást okoz.
Nem olyan, mint az analóg kazetta (vacakabb)mágneses törlés után halkan kihallható eredeti felvétel.
- A hozzászóláshoz be kell jelentkezni
nemtudom, meg sosem volt ilyen tesztekre szuksegem. Otthon kiprobalhatom, ha gondolod, es nem teszed meg korabban,mint en :)
--
Unix is user friendly - it's just picky about it's friends.
- A hozzászóláshoz be kell jelentkezni
köszi, nem szükséges, költői kérdés volt a részemről :)
- A hozzászóláshoz be kell jelentkezni
ext-re meg nem próbáltam, de ntfsrol fatre formázás után a getdataback for ntfs MINDENT helyreállított.
>>A Linux olyan mint az asszony, már fogalmad sincs miért választottad.<<
- A hozzászóláshoz be kell jelentkezni
OFF:
">>A Linux olyan mint az asszony, már fogalmad sincs miért választottad.<<"
Ez mekkora... :-))
ON
- A hozzászóláshoz be kell jelentkezni
Cd vagy pendrive live linux és dd -vel felülírni a teljes lemezt gondolom a lassabb megoldások közé tartozik. De ha jól saccolom szekvenciális írásnál akár 40MByte/sec sebesség is simán meglehet, újabb lemeznél akár sokkal több is. Az előbbi feltételezésből kiindulva 7 óra körül megvan egy terás lemez is.
"dd if=/dev/zero of=/dev/hda"
- A hozzászóláshoz be kell jelentkezni
Talán ha az összes file-ra nyomsz egy cat /dev/null > $file , az elég gyors lehet. Ha jól gondolom ez nem hoz létre új bejegyzést, akkor a régi tartalom elvész.
De a tuti a dd :)
- A hozzászóláshoz be kell jelentkezni
"Ha jól gondolom ez nem hoz létre új bejegyzést"
Jol gondolod. (Legalabbis egy normalis fajlrendszernel ez igy mukodik.)
Igy viszont a fajlokat el kell erni. Ennek a sebessege fugg a fajlrendszertol, ami akarmilyen gyors is, a kozvetlen diszk irasanal (dd) nem lesz gyorsabb.
Szerk.: Figyelmetlen voltam, azt hittem /dev/zero-t irtal, /dev/null-nak tenyleg nincs ertelme, ahogy utanam irtak.
- A hozzászóláshoz be kell jelentkezni
Baromi rossz ötlet, ugyanis semmi nem történik, csak 0 hosszúra állítod a fájlméretet, a teljes tartalma viszont érintetlenül ottmarad, ahol azelőtt volt. (Ok, fájlrendszerfüggő, van, ahol az első szektort legalább nullázza.)
Esetleg ha a /dev/zero -t küldenéd minden fájlba, annak már egy fokkal több értelme lenne.
De az egyetlen közelítőleg megfelelő megoldás a dd if=/dev/urandom of=/dev/sda egy bootcd-ről.
- A hozzászóláshoz be kell jelentkezni
Én ezt két napja HDD-ről rendszeren singleuserbe bootolva játszottam el, garanciaérvényesítés előtt... :) Nem tanulmányoztam át a végeredményt, de miután végigment kapott egy hardresetet, aztán nem bootolt. Szóval hatékonynak tűnt... :)
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
Sutoben 200-250 fok.
Szerk: Most olvasom hogy mukodnie kell utana, sorry.
-------------------------------
"A gorog katolikus noknek 8 dioptria alatt nem kotelezo a bajusz!" avagy "Nozni csak muholddal lehet..." | http://lazly.hu
- A hozzászóláshoz be kell jelentkezni
hány percre? :)
np...
- A hozzászóláshoz be kell jelentkezni
perc?
Gyakran kevergetve, amíg a színe aranybarna nem lesz. Aztán megkell fordítani!
Ha úgy szemre már porhanyós, kiveheted.
Azért a sütő helyett ajánlanék egy öntödei kupolót, a koksz mellé adagolva.
:)
- A hozzászóláshoz be kell jelentkezni
ennél azért egyszerűbb egy 20dekás kalapács egy párszor bele a közepébe a hegyével :)
de erre sajnos most nem kerülhet sor...
- A hozzászóláshoz be kell jelentkezni
Suto a tuti. Ekkora hofokon a merevlemezek adathordozo retege dobja a magnesesseget, elektronika is megsul. Remek modszer, szerintem 10 perc alatt szepen atmelegszik elomelegitett legkevereses sutoben. :) :)
-------------------------------
"A gorog katolikus noknek 8 dioptria alatt nem kotelezo a bajusz!" avagy "Nozni csak muholddal lehet..." | http://lazly.hu
- A hozzászóláshoz be kell jelentkezni
sajnos sütő nincs a cégnél (nem túl mobil), viszont a kalapács úgymond minden rendszergazda eszköztárában (mint végső 'csapás' a problémára) megtalálható :)))
--
jut eszembe, egyszer csináltam próbaképpen adatmegsemmisítést cd-ről egy mikró segítségével, hát szellőztetni kellett az eszközt utána rendesen. Gondolom az égett elektronika szag is rendesen átjárhatja a sütő belsejét.
- A hozzászóláshoz be kell jelentkezni
Az az adatmegsemmisítési módszer a mikrót is megsemmisíti... :D
- A hozzászóláshoz be kell jelentkezni
...és ha az adatok valahogy a kalapácsot meg tudnák, akkor lenne igazán izgi :)
jAzz
- A hozzászóláshoz be kell jelentkezni
A wipe-t nem uszod meg ha biztos akarsz lenni benne hogy ne jojjon vissza adat rola.
A sima particionalas/formazas kb. a szarnak egy pofon kategoria, arrol meg szinte minden visszanyerheto.
Nalunk erre van egy gep, amire 4-6 HDD is van ilyen selejtezesekkor feltolva es egyszerre megy rajtuk a wipe.
Bad Szektoros HDD, amin nem megy vegig a wipe pedig nem megy ki tolunk. Azt itt helyben szetszadizzuk :)
- A hozzászóláshoz be kell jelentkezni
Ha a tartalom "gázos", azaz ha dd-vel végigolvasva a vinyó találhatnak olyan adatot, ami problémás lehet, akkor sajnos végig kell írni az egész diszket.
Erre a dd if=/dev/zero of=diszk bs=1024k a legegyszerűbb megoldás (bár a /dev/random jobb), általában 2-4h alatt végig lehet menni egy diszken. Ha az összes gépen és diszken lehet ezt párhuzamosan végezni, akkor az max. egy délután.
- A hozzászóláshoz be kell jelentkezni
/dev/random semmiképpen, de még az urandom is lassú.
$ pv /dev/zero > /dev/null
^C82GB 0:00:10 [ 8.2GB/s] [ <=> ]
$ pv /dev/urandom > /dev/null
^C.1MB 0:00:09 [6.03MB/s] [ <=> ]
$ pv /dev/random > /dev/null
^C80B 0:00:12 [7.98B/s ] [ <=> ]- A hozzászóláshoz be kell jelentkezni
Igen, a randomnak nincs értelme, az urandom lehet, de az soká fog tartani. Alapvetően mezei Pistikék ellen a zero is tökéletesen elegendő. A Kürt kft ellen meg egy menet urandom kevés. Mondjuk 10-20 menet urandom után már nem aggódnék :)
- A hozzászóláshoz be kell jelentkezni
Szerintem egy menet /dev/zero elegendő a Kürt kft. ellen is.
A mai adatsűrűségek mellett puszta mítosznak tekinthető, hogy "szuper-felkészült cégek szuper-fejlett elektronmikroszkópokkal és fekete mágiával" helyre tudják állítani a felülírt adatokat. Ha lenne ilyen tartalék az adattárolási technológiában, akkor azt a merevlemez-gyártó cégek kihasználnák. És ki is használják, az összes fejlesztést a trackek szélességének csökkentésénél, a jelfeldolgozás javításánál, a mechanikai elemek tűrésénél stb. azonnal be is építik a következő termékvonalba, mert csak így tudnak versenyben maradni.
De ha mégis lehetséges lenne egy modern merevlemezről elektronmikroszkópos elemzéssel és hasonló hókuszpókuszokkal adatot visszanyerni, ez akkor is borzasztó időigényes lenne. 1 bit/s nagyságrendű sebességet becsülnek, akik értenek hozzá.
Ha esetleg te lennél Oszama bin Láden, és az NSA et al. bármekkora költség- és időráfordítás árán kész lenne minden egyes bitért megküzdeni, hogy visszafejtse a laptopod tartalmát, akkor esetleg el lehetne gondolkodni azon, hogy zero vagy urandom. Egyébként nincs jelentősége.
A zero challenge jut még eszembe, ill. egy magyar cikk, aminek a szerzője felkeresett több adatmentéssel foglalkozó céget azzal, hogy egy dd-vel felülírt lemezről szeretné az adatait visszakapni. Egyetlen helyen foglalkoztak vele érdemben, ott is azt kérdezték, hogy végigment-e a parancs, a többi helyről kapásból elküldték azzal, hogy esélytelen. (citation needed, tudom, de nincs érkezésem megkeresni.)
- A hozzászóláshoz be kell jelentkezni
Én is emlékszem erre a cikkre.
-----
"Én vagyok a hülye, hogy leállok magával vitatkozni."
- A hozzászóláshoz be kell jelentkezni
igazan rakhatnanak egy 3., nagyon gyors random generatort is a kernelbe, ilyen celokra pl. nem kell kriptografiailag es statisztikailag 100% megbizhato algo...
vannak pl. egesz gyorsan szamolhato, statisztikailag okes, nagyon nagy ciklusu pseudo-random algoritmusok, amibe bele lehet piszkitani random idokozonkent egy kis /dev/random-bol vett adattal.
A'rpi
- A hozzászóláshoz be kell jelentkezni
Hiren's Boot CD-n / Ultimate Boot CD-n van rá céleszköz, bár valószínűleg eltart egy darabig ezeknek is a futása.
- A hozzászóláshoz be kell jelentkezni
Tobben is irtatok, hogy /dev/zero-nal jobb a /dev/urandom. Miert? Azt ertem, hogy igy osszevisszasag kerul ra, de a csupa 0-bol sem lehet visszanyerni az adatot, es a random sokkal lassabb.
- A hozzászóláshoz be kell jelentkezni
Ez csak szokás kérdése, de a random szemét alól kibányászni az adatot nehezebb (itt persze nem a software -ekkel való vissza állításról beszélünk, hanem mikor a Kürtnél szétbontják a disket, de ez már elviszi a beszélgetést)
Még annyit hozzá fűznék, hogy ha a blocksize -t valami (nagyyon) nem szabályos értékre állítod be nagyban csökkenti a vissza állíthatóság valószínűségét.
----
概略情報
http://molnaristvan.eu/
- A hozzászóláshoz be kell jelentkezni
Koszonom!
"Még annyit hozzá fűznék, hogy ha a blocksize -t valami (nagyyon) nem szabályos értékre állítod be nagyban csökkenti a vissza állíthatóság valószínűségét."
Meg (altalaban) a sebesseget. :)
- A hozzászóláshoz be kell jelentkezni
"de a random szemét alól kibányászni az adatot nehezebb"
Ha mindent felülírok 0-val, akkor mit állítanának vissza?
- A hozzászóláshoz be kell jelentkezni
azert belul a vinyo is analog... nem csak 0.00000 es 1.00000 jelszint van a lemezen, ha rairsz 0-t nem lesz teljesen 0, hanem egy pici megmarad az elozo allapotabol is. lehet mondjuk 0.0 es 0.01 lesz az ertekek, attol fuggoen, hogy elotte 0 vagy 1 volt a bit... ezt Kurt esetleg megfelelo es baromidraga es lassu technikaval esetleg ki tudja olvasni es ebbol helyreallitani...
ezert szoktak mondani, hogy 10-20x urandom, utana mer tenyleg eselytelen...
A'rpi
- A hozzászóláshoz be kell jelentkezni
shred -vfz -n 30 /dev/{h|s}d{a|b|c|d}
- A hozzászóláshoz be kell jelentkezni
Gyors megoldás:
dd if=/dev/urandom of=/dev/sda bs=$[61*1023] count=102400
Ez a diskek első kb 6GByte -ját törli. Ugyan GetData Back nem tudja vissza állítani, de active unerase byte-to-byte ódban visza tudja állítani
Esetleg második lépésben bele tekerhetsz a diskbe seek=13421772800 paraméterrel egy újabb törléshez.
De a jó magoldás a DBAN és ezzel wipeolás.
Ha több gép van akkor kapcsold be mindet és párhuzamosan indítsd el a DBAN -t (ha elindult ki veheted a CD -t vagy pendriveot)
----
概略情報
http://molnaristvan.eu/
- A hozzászóláshoz be kell jelentkezni
Van valami olyasmi mondás, hogy: "A mi szolgáltatásunk gyors, megbízható, olcsó. Ezek közül bármely kettőt választhatja a kedves vevő".
Ez jutott eszembe.
jAzz
- A hozzászóláshoz be kell jelentkezni
Jogos, de nem is vártam százas megoldást. Marad a gyors és olcsó.
- A hozzászóláshoz be kell jelentkezni
add oda úgy hogy az első bootkor elindul egy script wipe-pal. Várjanak ők. :)
No rainbow, no sugar
- A hozzászóláshoz be kell jelentkezni
wehhehee, bár valszeg' fogja és kinyomja a szemét, ha nem jön be gyorsan a vindóz logó :)
- A hozzászóláshoz be kell jelentkezni
esetleg: http://hup.hu/node/89984
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
kicsit bővebben erről? nem igazán találok megfelelő infót.
- A hozzászóláshoz be kell jelentkezni
gugli morci? első kettő igazán releváns találat az ötödik meg itt van a hupon.. :)
- A hozzászóláshoz be kell jelentkezni
linux meg egyéb kulcsszavak nélkül tényleg használható a gugli első pár találata is, egyébként nem sok mindent hoz. :)
- A hozzászóláshoz be kell jelentkezni