Windows 7 SSD clonen - Kopien nicht lauffähig und fehlerhaft

miriquidi

Member
Registriert
28 Juni 2012
Beiträge
409
Hallo,

ich möchte mein altes x120e mit Windows 7 x86 mangels Rechenleistung gegen ein T420s tauschen, dabei aber die bestehende Installation mit der vielen gut eingerichteten und unter den Nachfolge-Windowse nicht lauffähiger Software mitnehmen und weiter nutzen. So ein Umzug von einer AMD auf eine Intelplattform geht prinzipiell (ein Clone davon ist mal temporär auf ein X220 umgezogen und lief gut), aber sicherheitshalber teste ich sowas vorher mit einem Backup. Wenn das geht, dann darf die Originalplatte umziehen.

Das Problem: Ich bekomme keine Kopie vom System gezogen.

Das Windows 7 x86 residiert auf einer 128 GB SSD, wobei die Installation von einem x100e (andere AMD-Plattform) stammt und später auf die SSD geklont wurde und noch später in ein x120e umgezogen ist.
Als Ziellaufwerke dienen eine 128 GB SSD eines anderen Herstellers (1 kiB kleiner als die bisherige) sowie testweise auch eine 320 GB Festplatte, welche mittels eines handelsüblichen USB-SATA-Gehäuses angeschlossen werden.
Jetzt habe ich die SSD mittels gparted (vom USB-Stick) als auch mittels NTI ECHO auf die zweite SSD bzw. die HDD überspielt, bekomme jedoch immer selbst auf dem Ausgangsrechner x120e nicht startfähige Systeme. Das System stürzt ziemlich am Anfang des Hochfahrens ab und verweist im blauen Bildschirm auf Checkdisk. Reparaturversuche mittels eines Windows 7 USB Sticks (Reparaturfunktion) waren alle erfolglos. Wenn ich das Dateisystem später wieder in Windows 7 einbinde und mittels des Kommandozeilenbefehls "chkdsk /F" repariere, bekomme ich viele hundert Dateifehler.

Mich macht das ganze etwas ratlos, weil das ja eigentlich funktionieren sollte. Auch der USB-SATA-Adapter funktioniert problemlos mit anderen Festplatten an dem Rechner und an anderen Rechnern.

Jetzt ärgert mich das T420s selbst aber schon von Beginn an, unabhängig von diesem Kopierproblem: Eine Windows 7 AMD64 Installation aus einem x220 bootet ohne Probleme, die lauffähige Debian-Installation (andere SSD) aus dem gleichen x220 will im T420s aber nicht starten (das BIOS wurde zurück gesetzt und alle Einstellungen sind identisch).

Ich bin mit meinem Latein am Ende und wollte mich umhören, ob mir noch jemand einen Rat geben kann.
 
Hast du die SSD im x120 mal mit checkdisk geprüft? Vielleicht sind da die Fehler ja schon vorhanden und werden gnadenlos geclont.

Grüße Thomas
 
Das Ziellaufwerk sollte/muss im Rechner eingebaut sein, das Quelllaufwerk an USB und von einem bootfähigen Stick den Rechner starten.

Hilfreich ist übrigens:
Vor dem klonen in der Konsole "chkdsk c: /r" ausführen, um sicher zu stellen, dass das Dateisystem in Ordnung ist.
 
Zuletzt bearbeitet:
^Das nutze ich auch. Dazu dann ein Stick mit Macrium-PE bauen und es funktioniert immer, zumindest bei mir!
 
die lauffähige Debian-Installation (andere SSD) aus dem gleichen x220 will im T420s aber nicht starten (das BIOS wurde zurück gesetzt und alle Einstellungen sind identisch).
Durch Zurücksetzen des BIOS verlierst Du die UEFI-Booteinträge im NVRAM. Falls es also eine UEFI-Installation ist, müsstest Du den Eintrag für Debian neu anlegen.
 
Hallo,
vielen Dank für die zahlreichen Ratschläge. I
ch bin gestern dazu gekommen, weiter an dem Problem zu frickeln.

Das Dateisystem auf dem Quelllaufwerk ist laut chkdsk in Ordnung. Da fällt mir schon einmal ein Stein vom Herzen.
Laut gparted gibt es aber ein Problem: Es sind zwei Partitionen drauf. Die Windows 7 Start-Partition und die eigentlich Windows 7 Partition mit den Programmen und Daten. Letztere endet laut Patitionstabelle nach dem letzten Sektor der SSD, geht somit über das "Ende" der SSD hinaus. Es sind nur wenige kiB/MiB, aber das kann für mein Verständnis eigentlich nicht sein.
Komischerweise ist bisher aber kein Fehler im Betrieb aufgetreten (die SSD wird aber auch nie "voll" gemacht).

Beim Durchlauf von chkdsk ist mir aufgefallen, dass es auf dem Quellsystem just in jenem Moment im Startprozess gestartet wird, in welchem die Kopien immer den Hochfahrprozess abbrechen. Da chkdsk die Hauptpartition prüfen muss, bevor das Restsystem schon darauf zugreift, könnte es sein, dass es einen Fehler beim "Einhängen" der Hauptpatition gibt. Ich schaue im Laufe der Woche mal, ob die Partitionensgrenzen auf der Kopie wirklich sektorgenau der Quelle entsprechen.

@linrunner: Das muss ich mir bei Gelegenheit genauer anschauen. Dachte, das wäre alles auf der Festplatte eingeschrieben.
 
Zuletzt bearbeitet:
geht somit über das "Ende" der SSD hinaus. Es sind nur wenige kiB/MiB, aber das kann für mein Verständnis eigentlich nicht sein.
Da wäre ich mir nicht ganz so sicher. Soweit ich weiß, wird am Ende das Laufwerks eine Kopie der Partitionstabelle abgelegt. Vielleicht liegt hier die Ursache, sollte z.B. kein ausreichender Platz für die Ersatz-Partitionstabelle vorhanden sein.

Ich würde erst einmal die Partition, die angeblich über das Laufwerksende hinaus geht, etwas verkleinern.
 
Zuletzt bearbeitet:
Hinsichtlich der Überlänge, verkleinere die Partition minimal über die Datenträgerverwaltung. Vorher bitte Backup! Sicher ist sicher
 
Macrium Reflect free nutzen. Der macht auch vorher einen Check und wanrt, wenn das Dateisystem beschädigt ist.
Das habe ich jetzt aus probiert und damit die SSD 1:1 auf eine Festplatte geklont. Das Fehlerbild ist das gleiche wie zuvor, die Kopie ist im Originalrechner ist [EDIT]nicht[/EDIT] lauffähig.

Was mir dabei auffiehl: Die Partitionen beginnen an den gleichen Sektorgrenzen. Im Fall von gparted ist die geklonte Partition aber länger als die alte. :\
Bei Macrium Reflect liegen die Grenzen in der Kopie an der gleichen Stelle wie im Original.

@ach: Genau an dem Backup scheitert es ja. Die Daten sind vielfach gesichert, nur die Programmeinstellungen usw. nicht. :(
 
Zuletzt bearbeitet:
Wäre es hier nicht einfacher ein Image auf Ext. HDD zu sichern und dann direkt am Zielgerät dieses auf die eingebaute SSD zu recovern? So handhabe ich das andauernd und es gab dabei abgesehen von Anwenderfehler (Image von 256GB auf 128GB - erst neue einbauen, dann recovern hilft aber) noch keinerlei Probleme. Ob es dafür auch gratis Software gibt, weiß ich allerdings nicht, da ich etwas gekauftes verwende.
 
Kopiert ein Image mehr als nur die Partitionen?

@Mornsgrans: Die Quelle am internen SATA-Port, das Ziel an einem USB-SATA Gehäuse.
Evtl. sollte ich mal einen anderen Rechner dafür verwenden.
 
Hallo,ich hatte das schon versucht (nur wohl vergessen aufzuschreiben). Es hatte mit gparted keinen Effekt. Das Image ist genauso wenig lauffähig, wie wenn die Quelle intern angestöpselt ist.
 
Nun, Du hast es ja nicht nur mit GParted versucht.
Kopiert ein Image mehr als nur die Partitionen?
Ein Laufwerks-Image kopiert die gesamte Platte incl. Partitionierungsdaten.

Was mir eben noch eingefallen ist:
Eine MBR-Partitionierte Platte muss auch wieder als MBR-System geklont bzw. gesichert und wiederhergestellt werden.
Gleiches gilt auch für GPT-Systeme.

Die Vermutung liegt nahe, dass Du vielleicht ein MBR-System als GPT oder umgekehrt kopiert/geklont hast.
 
Das Quellsystem will ich besser nicht über USB-booten lassen, wer weiß, was da wieder passiert. Insofern bleibt dafür nur gparted.

Sowohl die Quelle als auch das Ziel sind MBR-Systeme, so dass es daran leider nicht liegt.
Ich habe meine etwas angestaubte gparted-Version jetzt aktualisiert. Die neue Version startet zwar auf dem x120e aber im ersten Auswahlmenü ist Schluss.
Auf dem T420s startet es hingegen richtig. Dort zu kopieren, ist dann der nächste Versuch. Sobald ich wieder Zeit finde.
 
Zuletzt bearbeitet:
Das Quellsystem will ich besser nicht über USB-booten lassen, wer weiß, was da wieder passiert. Insofern bleibt dafür nur gparted.
Du sollst das Quellsystem nicht von USB booten (Windows kann das eh nicht), sondern das Klontool vom USB-Stick.
Steht auch so in Beitrag #5!!!!!!

Anschließend das Quellsystem von der USB-Platte auf die intern verbauten HDD klonen.
 
  • ok1.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen
Zurück
Oben