Das neue EEE-Forum https://www.eee-forum.de/forum/ |
|
Rovery / Datenrettung https://www.eee-forum.de/forum/viewtopic.php?f=27&t=107 |
Seite 3 von 3 |
Autor: | tosty [ Mo 14. Mär 2011, 09:15 ] |
Betreff des Beitrags: | Re: Rovery / Datenrettung |
Servus pit, [offtopic] wieso würde Dich das abschrecken? An sich macht es keinen Unterschied, ob man so ein Image nun mit "dd" oder irgendeinem ImageBackup Programm etc. sichert. Das Lesen von der USB Platte wird damit auch nicht schneller, beim Schreiben eines Images kann man ja - wenn man will - auf Komprimierung zurückgreifen (ist aber eher für Backups sinnvoll, als für Dinge, wo man weiter mit dem Image arbeitet). Jedenfalls geht das Arbeiten mit dem Image als Datei dann wesentlich flotter von der Hand als immer direkt über USB zuzugreifen. Oder bezog sich Dein Grauen auf "dd" als solches? Ich nutze es jedenfalls viel und habe für Backups und Image-Generierung von realen Datenträger etc. noch nie etwas anderes benutzt. Auch andere (grafische) Programme bedienen sich intern einfach nur bei "dd", durch direkten Aufruf mit entsprechenden Parametern oder weil man es integriert. Effektiv ist die Funktionsweise anderer Programme, die eigene Routinen nutzen, auch keine andere. Image-Backups-Tasks gehen von der Bedienung vermutlich teils einfacher mit anderen Programmen, mag sein. Oft genutzt wird auch bspw. ddrescue bzw GNU ddrescue. Ferner finde ich wichtig, wenn man dann so einen kompletten Abzug einer HDD/Karte/... hat: dann - wenn es mit dem Platz reicht - davon wiederum eine Kopie zum Arbeiten machen An solchen Komplettabzügen kann man dann auch gut so arbeiten, auch wenn es nicht um das Wiederherstellen irgendwelcher Daten geht .... meine damit, einfach mounten (einzelner Partitionen). Hierzu kann man sich einfach die Partitionstabelle zu Hand nehmen, bspw. mit "mmls"aus dem Sleuth Kit, um den Offset rauszufinden, den man zum Mounten braucht. Beispiele: a) einfaches Beispiel, Backup 32 GB SSD/CF: Code: asus-213xxxxxxx:/media/F:/EeePC/900A/ImageBackups> mmls 2011-03/cf32-full.img DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 00: ----- 0000000000 0000000000 0000000001 Primary Table (#0) 01: ----- 0000000001 0000002047 0000002047 Unallocated 02: 00:00 0000002048 0031641599 0031639552 Linux (0x83) 03: 00:01 0031641600 0044226944 0012585345 Win95 FAT16 (0x0E) 04: 00:02 0044226945 0049110704 0004883760 Linux (0x83) 05: ----- 0049110705 0062537327 0013426623 Unallocated b) komplexere Part.tabelle/Beispiel, ebenfalks kleine SSD/CF: Code: asus-213xxxxxxx:/media/F:/EeePC/900A/ImageBackups> mmls 2010-12/cf32-full.img DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 00: ----- 0000000000 0000000000 0000000001 Primary Table (#0) 01: ----- 0000000001 0000000062 0000000062 Unallocated 02: 00:00 0000000063 0005831594 0005831532 Linux (0x83) 03: 00:01 0005831595 0019535039 0013703445 Linux (0x83) 04: 00:02 0019535040 0019551104 0000016065 EFI File System (0xef) 05: 00:03 0019551105 0062524979 0042973875 DOS Extended (0x05) 06: ----- 0019551105 0019551105 0000000001 Extended Table (#1) 07: ----- 0019551106 0019551167 0000000062 Unallocated 08: 01:00 0019551168 0040531994 0020980827 Linux (0x83) 09: 01:01 0040531995 0057319919 0016787925 DOS Extended (0x05) 10: ----- 0040531995 0040531995 0000000001 Extended Table (#2) 11: ----- 0040531996 0040532057 0000000062 Unallocated 12: 02:00 0040532058 0057319919 0016787862 NTFS Volume Set (0x86) 13: ----- 0057319920 0062537327 0005217408 Unallocated Dann nimmt man sich halt die Infos raus, bspw. aus dem ersten Beispiel die 1. Linux-Partition, die einen (eher ungewöhnlichen) Offset von 2048 Blocks hat, multipliziert das mit der Blockgröße (512 Byte) und mountet sich das Ding Code: asus-213xxx:/media/F:/EeePC/900A/ImageBackups> mount -o loop,offset=1048576 2011-03/cf32-full.img /mnt/diskimage/ asus-213xxx:/media/F:/EeePC/900A/ImageBackups> ls /mnt/diskimage/ bin/ cdrom/ etc/ initrd.img lib/ media/ opt/ root/ selinux/ sys/ usr/ vmlinuz boot/ dev/ home/ initrd.img.old lost+found/ mnt/ proc/ sbin/ srv/ tmp/ var/ vmlinuz.old asus-213xxx:/media/F:/EeePC/900A/ImageBackups> cat /mnt/diskimage/etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=10.10 DISTRIB_CODENAME=maverick DISTRIB_DESCRIPTION="Ubuntu 10.10" ... ... man sieht, da ist/war ein Ubuntu 10.10 drauf Belassen wir den Off-Topic mal hier dabei, ggf. können wir ja weiter diskutieren / ich trenns ab? [/offtopic] |
Autor: | pit234a [ Mo 14. Mär 2011, 21:21 ] |
Betreff des Beitrags: | Re: Rovery / Datenrettung |
Hi tosty Ich finde nicht, dass dies OT ist, sondern ganz nah am Thema dran und auch gute Tips für den Themenstarter beinhaltet. Den sleuthkit und das mmls daraus kenne ich noch nicht und habe eben die Installation mal angeworfen. Das ist natürlich kollossal hilfreich! Ich hatte mir immer die Inhalte mit hexdump Byteweise angesehen (evtl nach 55\ aa oder FAT32 ge-grep-ed) und so versucht, die Offsets zu finden. Das ist aber nicht ganz easy und mehrfach gab ich dabei schon auf. Die mount-option -o loop kennt FreeBSD nicht. Wenn ich etwa ein .iso-Image mounten will, lege ich dafür vorher ein md-Gerät an und mounte dann dieses. Wie ich den passenden Offset-Wert da einbauen könnte, weiß ich so im Augenblick nicht. Darüber muss ich vielleicht nochmal die man-pages lesen (vermutlich aber erst, wenn ich mal wieder ein Problem habe). Deshalb hatte ich dann versucht, direkt in den MBR die passende Information zu schreiben und dann "normal" zu mounten. Aber auch dafür wäre ja mmls eine super Hilfe. Gerade im Fall, wie er hier geschildert ist, könnte die Wiederherstellung des MBR oder das herauslesen der Partitionen und einzeln mounten (vielleicht, wahscheinlich, gab es nur eine einzige mit einem Filesystem) eine sehr gute Möglichkeit der Datenrettung liefern, einfach schnell und direkt. Das halte ich im Vergleich zur Benutzung irgendeiner SW für durchaus nicht sinnlos. Mir haben solche Methoden jedenfalls schon schön geholfen. Es ist aber halt doch so ein wenig Bit-Frimelei und Fehler passieren leicht. Deshalb würde ich das immer nur an einem Image der Platte machen und genau, wie du sagst, eines zu Sicherheit anlegen und eines, womit ich dann spielen kann. Allerdings hatte ich noch keine 300G externe Platte. Das würde meine Kapazität ein wenig überfordern. Was mich ein wenig schaudern lässt, ist die Dauer, die man für ein dd-Image dieser Größe über USB braucht. Weil man ja nicht die Struktur der Daten kennt, ist sicher angesagt, mit einer bs=512 zu übertragen. Ich glaube, Linux dd kann auch bs=1, FreeBSD nur bs=n*512. Wenn ich weniger brauche, nehme ich sdd von Jörg Schilling. dd ist bei mir sehr oft im Gebrauch und ich erzeuge zum Beispiel auch .iso Files damit. Es ist eines der wirklichen wichtigen Tools bei mir. Aber, besonders wenn die bs ja klein ist, dann dauert die Übertragung schon ganz schon lange und letztens hatte ich einen 1GB Transfer von einem USB-Stick und da wartete ich schon eine Weile, nicht mehr ganz sicher, aber ich denke eine gute halbe Stunde. (Linux scheint an USB noch immer schneller, als FreeBSD). Wenn ich das nun auf 300GB hochrechne, dann schaudert es mich halt. Vermutlich hast du aber Recht: mit anderen Programmen wird das auch nicht wesentlich anders gehen können. Wenn die ein Image erzeugen, werden sie dafür Zeit brauchen. Da haben wir ja schon was dazu mitlesen können. Also, wie gesagt, meiner Meinung nach gehört "unsere Diskussion" hier ganz genau hin und war jedenfalls für mich bereits wertvoll und wird vielleicht auch unter diesem Titel anderen helfen können. Es ist doch viel einfacher, als irgendein Programm zu suchen und seine Daten diesem dann blind zu überlassen. Wenn es nur einen Quick-Format gab, werden die Daten vermutlich noch akkurat auf der Platte stehen und können mit etwas Glück gemountet und einfach kopiert werden. Der Versuch kann nicht schaden aber er könnte sich echt lohnen. |
Seite 3 von 3 | Alle Zeiten sind UTC + 1 Stunde |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |