Sorry 4 delay,
Folgende Vorschlag.
Du Imaged die Platte nicht sondern Du kopierst nur deren Inhalt via
rsync ...
Biede Platten Einbinden ( sda + sdb )
## sda = ssd
## sdb = sata (oder was auch immer)
## Dumpen das Pratitiontables von ssd auf sata platte
sfdisk -d /dev/sda | sfdisd /dev/sdb
## ich gehe jetzt einfach mal davon aus, dass Du nur eine Partition auf
der Quellplatte hast. Solltest Du dort auch lvm oder ähnliches
Konfiguriert haben so sind die Mountbefehle entsprechend zu
erweitern ... Für Fragen stehe ich gerne zur Verfügung.
## Welches Filesystem ist auf sda1? Das auf sdb1 erzeugen (ich machs
mal ext4).
mkfs.ext4 /dev/sdb1
mkdir /mnt/sd{a,b}
## Nicht vergessen ich nehme der Komplexität wegen hier nur eine
## Partition an
mount /dev/sda1 /mnt/sda
mount /dev/sdb1 /mnt/sdb
rsync -av --exclude=/mnt/sda1/proc \\
--exclude=/mnt/sda1/sys /mnt/sda1/* /dev/sdb1
## Wenn nun alles fertig gesynct ist
mkdir /mnt/sdb1/{proc,sys}
## Procverzeichnisse mounten
mount -o bind /proc /mnt/sdb1/proc
mount -o bind /sys /mnt/sdb1/sys
## grub installieren
chroot /mnt/sdb1 grub-install /dev/sdb
## wenn keine Fehler wurde der Bootloader korrekt installiert
exit
umount mnt/sdb1/{proc,sys}
### END
Jetz solltes Du dies Platte booten können .... Alle Daten sind exakt so
wie sie auf der ssd waren nur defragmentiert ...
Nochmal: Würden sich daten beim Auslesen
einer Platte verändern könnte man sich nie auf die Konsistenz der Daten
an sich verlassen können.
Nochwas: Wenn zu dd tendierst weil einfacher und weniger aufwendig,
so steht Dir die Möglichkeit zur Verfügung das erstellte Image ( Du
musst es als File schreiben und nicht direkt auf die Zielplatte )
loopback zu mounten. Auf die Zielplatte kanns Dus immer noch ballern
dd if=/dev/sdx bs=2M of=/backup/imagename.img
## Nimeals die die Platte von der aus Du geboot hast auf sich
## selbst dumpen. Das endet in einer Recursion.
mount -o loop imagename /mnt/test
## danach kannst Du nur recursiv einen md5sum check zu machen und den in
## eine Datei umleiten
## kein Zeilenumbruch im folgenden ...
find /mnt/test -type f \( -iname “*” ! -iname ”proc” \) -exec md5sum {}
\; >
## Das ganze nun auch mit der Original ssd natürlich im eingebundnen
## Zustand,
mount /dev/sda1 /mnt/sda
## kein Zeilenumbruch im folgenden ...
find /mnt/sda -type f \( -iname “*” ! -iname ”proc” \) -exec md5sum {}
\; > /tmp/sda_loopback.md5
## nun beide Dateien vergleichen
vi -d /tmp/test_loopback.md5 /tmp/sda_loopback.md5
## wird schon farbig dargestellt wenn vim installiert ist.
## Dann weisst ob sich wirklich was unterscheidet.
Have fun
Matthias
Am Tue, 25 Oct 2011 23:46:14 +0200
schrieb Andrea Hendel <[email protected]>:
> Ja, Hallo nochmal!
>
> Am Montag, den 24.10.2011, 12:27 +0200 schrieb Matthias Schweizer:
>
> >
> > Da sich eine SSD nur intern von
> > herkömmlichen Platten unterscheidet, na aussen jedoch wie eine
> > normal HD auftritt ist eine interne Codierung egal.
> >
> > Forensisch würde sich lediglich nach jeder Imagerstellung die
> > CHECKSUM des erstellten Images unterscheiden, da die SSD bei jedem
> > Zugriff "intern umstrukturiert".
>
> Da wird die Sache doch schon interessanter. Mein Kollege will nämlich
> ein Image OHNE diese Umstrukturierung! (Wo kann man hierzu
> nachlesen??).
> Konkret: auf der SSD läuft die Software irgendso einer
> Maschinenansteuerung. Offenbar mit irgend einem Bug. Strukturiere ich
> die SSD jedoch beim kopieren um, kann das den Fehler verschleiern. So
> habe ich es zumindest verstanden.
>
> > Bei einer herkömmlichen bliebe diese immer gleich.
> >
> > Probiers doch einfach aus. Die Zielplatte ist doch sowieso neu und
> > zerstören kannst Du da eh nichts.
>
> Aber die Bug-tragenden SSD würde ja nach Deiner Stellungnahme auch
> verändert und genau das soll vermieden werden!!!!
>
>
> VG
>
> Andrea
>
> _______________________________________________
> lug-ts mailing list
> [email protected]
> http://www.lug-ts.de/mailman/listinfo/lug-ts
_______________________________________________
lug-ts mailing list
[email protected]
http://www.lug-ts.de/mailman/listinfo/lug-ts
