Ich habe ddFestplatten folgendermaßen geklont:
dd if=/dev/sdb of=/dev/sda bs=4096 conv=notrunc,noerror,sync
Und es hat immer gut funktioniert. Alle Dokumentationen zu „dd“ erinnern Sie ausdrücklich daran, dass die Zielfestplatte gleich groß oder größer als die Quelle sein muss. Muss das unbedingt so sein?
Nun ist mir klar, dass ich bei einem Klonen auf eine kleinere Festplatte keine Partitionen erwarten kann, dieteilweise „Außerhalb der Grenzen“ auf dem Ziel, um intakt zu sein.
Könnte ich jedoch trotzdem mit „dd“ eine Brute-Force-Kopie der Quelle bis zur physischen Größe des Ziels erstellen, obwohl ich genau weiß, dass ich meine Partitionen auf dem Ziel später bearbeiten und die außerhalb der Grenzen liegenden löschen muss? Oder würde „dd“ das Ziel in einen rauchenden Trümmerhaufen verwandeln, wenn es die Grenze seiner Größe erreicht ;-)
Übrigens habe ich bei meinen Recherchen hierzu empfohlene Werte für bs=alles von bs=1024bis zu gesehen bs=32M. Was ist wirklich am besten?
Antwort1
Wie andere hier bereits erwähnt haben, ddfunktioniert die Verwendung einfach nicht, da sich die Kopie der GPT-Tabelle am Ende der Festplatte befindet.
Mit der folgenden Methode ist es mir gelungen, eine Migration auf ein kleineres Laufwerk durchzuführen:
Booten Sie zunächst in die LiveCD-Distribution Ihrer Wahl.
Passen Sie die Größe der Quelllaufwerkpartitionen so an, dass sie tatsächlich in die Beschränkungen des kleineren Laufwerks passen ( gpartedzum Beispiel mit ). Wenn Sie dann davon ausgehen, sdadass es sich um die Quellfestplatte handelt, sgdiskerstellen Sie zur Sicherheit zunächst eine Sicherungskopie der GPT-Tabelle vom Quelllaufwerk: `
sgdisk -b=gpt.bak.bin /dev/sda
Angenommen, dies sdbist das Ziel, replizieren Sie die Tabelle vom Quelllaufwerk auf das Ziel:
sgdisk -R=/dev/sdb /dev/sda
sgdiskwird sich nun beschweren, dass es versucht hat, die Header-Kopie außerhalb der Grenzen der Zielfestplatte zu platzieren, wird dann aber auf ein anderes Verfahren zurückgreifen und den Header korrekt an der oberen Grenze der Zielfestplatte platzieren.
gpartedÜberprüfen Sie mit einem Tool Ihrer Wahl ( zum Beispiel), ob auf dem Ziellaufwerk ein korrekter Klon der Partitionstabelle erstellt wurde .
Kopieren Sie mithilfe ddvon jede Partition vom Quelllaufwerk auf das Ziellaufwerk:
dd if=/dev/sda1 of=/dev/sdb1 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda2 of=/dev/sdb2 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda3 of=/dev/sdb3 bs=1M conv=sync,noerror,notrunc status=progress
etc...
Wenn Sie beim Replizieren der GPT-Partitionstabelle ohne Backup oder beim Exportieren der Inhalte die Namen der Laufwerke verwechseln, ddkönnen Sie sich natürlich von Ihren Inhalten verabschieden :)
Antwort2
Das physische Laufwerk sollte zumindest nicht anfangen zu rauchen, aber die Wahrscheinlichkeit ist sehr hoch, dass Ihr Dateisystem nicht mehr funktioniert (ich meine das Zieldateisystem; wenn Sie nur kopiert und nichts in der Quelle verändert haben, sollte die Quelle selbst in Ordnung sein). Daten innerhalb einer Partition werden nicht unbedingt in aufsteigender Reihenfolge zugewiesen. Einige davon können am Ende der Partition liegen, auch wenn die Partition nicht voll ist (eigentlich glaube ich, dass dies bei einigen Dateisystemen deterministisch geschieht, aber ich weiß nicht genug, um ins Detail zu gehen). Die dort vorhandenen Daten können für die Integrität des Dateisystems von entscheidender Bedeutung sein. Ich rate Ihnen daher dringend davon ab, sich auf eine solche Kopie zu verlassen.
Wenn Sie diese Kopie erstellen möchten, müssen Sie zunächst die Partition mit einem Tool verkleinern, das ihre interne Struktur kennt und alles in einer kleineren Partition ordnungsgemäß neu zuordnen kann. Dann können Sie die Kopie erstellen. gpartedist eine gute GUI-Schnittstelle für solche Dinge.
Was den bsWert angeht, ist es normalerweise am besten, ein paar Tests durchzuführen, bevor man mit dem eigentlichen Kopieren beginnt. Es gibt einige Tools, die Ihnen dabei helfen, diese Prüfung zu automatisieren, aber ich erinnere mich nicht an den Namen. Meiner Erfahrung nach liegt der beste Bereich normalerweise zwischen 4 M und 16 M. Darüber bringt es nicht mehr viel. Aber es hängt von vielen Dingen ab, einschließlich der Festplatten selbst. Ich habe zum Beispiel selten mit echten High-End-Festplatten gearbeitet, die aufgrund ihrer höheren Geschwindigkeit und Cache-Größe für höhere Werte geeignet sein könnten.
BEARBEITENWenn eine Partition vollständig kopiert ist, können Sie sie problemlos verwenden. Wie andere jedoch betont haben, müssen Sie auch sicherstellen, dass die Partitionstabelle intakt ist (zumindest die relevanten Einträge). Mit den vier primären Partitionen von MBR gibt es keine Probleme, da sie in den ersten 512 Bytes der Festplatte beschrieben sind. Logische Partitionen sind in der gesamten erweiterten Partition beschrieben, sodass Einträge verloren gehen können (aber sie würden Partitionen beschreiben, die sowieso verloren gehen würden). Bei GPT gibt es sowohl am Anfang als auch am Ende der Festplatte eine Kopie der Partitionstabelle. Sie verlieren die zweite, können sie aber aus der ersten wiederherstellen. Natürlich ist es ratsam, dies so schnell wie möglich zu tun; andere Antworten waren diesbezüglich präziser.
Antwort3
Obwohl die vorgeschlagene „Herausforderung“ auf den ersten Blick schwierig, nicht machbar oder naiv erscheinen mag, wie einige kommentiert haben, ist sie es nicht. Die Grundidee hinter der Verwendung von dd zur Migration von einer größeren auf eine kleinere Festplatte ist vollkommen in Ordnung und bietet Vorteile für die Datenmigration. Natürlich ist ausreichend freier Speicherplatz erforderlich, damit die belegten Daten auf die Zielfestplatte passen.
Die Idee besteht darin, jede Partition einzeln per dd zu bearbeiten und nicht die gesamte Festplatte auf einmal, wie ursprünglich vorgeschlagen. Es lässt sich sogar noch mehr erreichen: Die Partition(en), die abgeschnitten würden, können mit ein wenig Hilfe von Tools zur Größenänderung des Dateisystems auch sicher migriert werden. Tatsächlich ist eine solche Migration interessant, um Dateisystem-Matrizen und erweiterte Dateiattribute beizubehalten, die nicht einfach mit Tools wie cp, rsync, pax usw. kopiert werden können, die in der Dateisystemebene und nicht in der Blockgeräteebene arbeiten. Durch die Verwendung von dd entfällt die Notwendigkeit, das Betriebssystem neu zu installieren oder das FS neu zu benennen, um Probleme mit SELinux zu vermeiden.
Nachfolgend finden Sie, was ich normalerweise mache, um ähnliche Aufgaben zu erledigen:
1) Zuerst müssen Sie die Dateisysteme innerhalb der betroffenen Partitionen verkleinern, die abgeschnitten werden würden. Verwenden Sie dazu das Tool resize2fs (vorausgesetzt, wir sprechen von einem ext2/ext3/ext4-FS – andere moderne FSs haben auch Größenänderungstools für denselben Zweck). Beachten Sie, dass ein Dateisystem zwar – aus offensichtlichen Gründen – nicht größer als die Partition sein kann, in der es sich befindet, aber es kann problemlos kleiner sein. Der Sicherheitstrick besteht hier darin, „mehr als nötig“ zu verkleinern. Beispiel: Stellen Sie sich vor, Sie haben ein Dateisystem von 1 TB, das Sie auf ein 500-GB-Laufwerk migrieren möchten. In diesem Fall schlage ich vor, das FS auf beispielsweise 450 GB zu verkleinern (Sie müssen dafür natürlich genügend freien Speicherplatz haben, d. h. der derzeit belegte Speicherplatz in diesem Dateisystem darf 450 GB nicht überschreiten). Die scheinbar verschwendeten 50 GB Speicherplatz werden nach der Datenmigration behoben.
2) Partitionieren Sie die Zielfestplatte mit der entsprechenden Geometrie und berücksichtigen Sie dabei die Platzbeschränkungen.
3) dd die Daten mit den Partitionsgeräten und nicht mit dem Festplattengerät (d. h., verwenden Sie dd if=/dev/sda# of=/dev/sdb#für jede Partition statt if=/dev/sda of=/dev/sdb). HINWEIS: sda und sdb sind hier nur Beispiele; WICHTIGER HINWEIS: Beim dd von einem größeren auf ein kleineres Partitionsgerät beschwert sich dd über den Versuch, Post an das Ende des Blockgeräts zu schreiben. Das ist ok, da die Dateisystemdaten vollständig kopiert worden wären, bevor dieser Punkt erreicht wurde. Um eine solche Fehlermeldung zu vermeiden, können Sie die Größe der Kopie mit und bs=Parametern angeben count=, die der verkleinerten Dateisystemgröße entsprechen. Dies erfordert jedoch einige (einfache) Berechnungen, kann aber bei falscher Ausführung Ihre Daten gefährden.
4) Ändern Sie nach dem DD-Verfahren die Größe der jeweiligen Dateisysteme in den Zielpartitionen erneut mit resize2fs. Geben Sie diesmal die neue Dateisystemgröße nicht an. Wenn resize2fs ohne Größenangabe ausgeführt wird, vergrößert es das Dateisystem so, dass es die maximal zulässige Größe einnimmt. In diesem Fall wird das 450-GB-Dateisystem also erneut vergrößert, um die gesamte 500-GB-Partition einzunehmen, und es wird kein Byte verschwendet. (Der Ansatz „mehr als nötig reduzieren“ verhindert, dass Sie versehentlich falsche Größen angeben und Ihre Daten gefährden. Beachten Sie, dass die Unterscheidung zwischen GB- und GiB-Einheiten schwierig sein kann.)
Hinweis für komplexere Vorgänge: Wenn Sie einen Bootmanager haben, den Sie mitkopieren möchten, was sehr wahrscheinlich ist, können Sie die ersten paar KB der Festplatte mit dem Festplattengerät statt den Partitionsgeräten (wie dd if=/dev/sda of=/dev/sdb bs=4096 count=5) dden und anschließend die Geometrie in /dev/sdb neu konfigurieren (das vorübergehend eine ungültige Geometrie für das neue Laufwerk, aber einen intakten und gültigen Bootmanager enthält). Fahren Sie abschließend mit den Partitionsgeräten fort, wie oben beschrieben, um jeweils eine Partition dden. Ich habe solche Vorgänge oft ausgeführt. Vor kurzem habe ich erfolgreich eine komplexe Migration durchgeführt, als ich von einer Festplatte mit einer Mischung aus MacOSX- und Linux-Installationen auf eine kleinere SDD in meinem MacMini6,2 aktualisierte. In diesem Fall musste ich Linux von einem externen Laufwerk booten, den Bootmanager dden, gdisk ausführen, um GPT auf der neuen Festplatte zu reparieren und schließlich jede Partition dden, die die gerade verkleinerten Dateisysteme enthielt. (Beachten Sie, dass das GPT-Partitionsschema zwei Kopien der Partitionstabelle speichert, eine am Anfang und eine am Ende der Festplatte. gdisk beschwert sich häufig, weil es die zweite Kopie der PT nicht finden kann und weil die Partitionen die Festplattengröße überschreiten, aber es behebt das PT-Kopierproblem ordnungsgemäß, nachdem Sie die Festplattengeometrie neu definiert haben.) Dies war ein viel komplexerer Fall, der jedoch erwähnenswert ist, da er zeigt, dass diese Art von Vorgang auch problemlos durchführbar ist.
Viel Glück! ... und denken Sie vor allem daran, vor einem solchen Vorgang alle wichtigen Daten zu sichern. Ein Fehler kann Ihre Daten unwiederbringlich beschädigen.
Und falls ich es nicht oft genug betont habe: Sichern Sie Ihre Daten vor der Migration! :)
Antwort4
Ich möchte meine Erfahrungen zu diesem Thema teilen, falls dies für einen anderen Leser nützlich sein sollte. Kürzlich habe ichDDRESCUEdas erste Drittel einer NTFS-Partition von einer defekten Festplatte wiederherzustellen und das wiederhergestellte Segment der Partition erfolgreich auf einer kleineren Festplatte wiederherzustellen - wodurch die erfassten Dateien gerettet wurden (und der Rest verloren ging). Im Folgenden sind die Schritte aufgeführt, die ich dabei unternommen habe(definitiv ein HACKSAW-Ansatz!!)...
Die Quellfestplatte bestand aus 750 GB, formatiert in NTFS mit einer MBR-Dateitabelle. Ich hatte sie nur ein paar Mal zum Sichern von Dateien verwendet, daher befanden sich die meisten Dateien am Anfang der Festplatte, etwa 160 GB. Ein Familienmitglied warf die Festplatte (extern montiert) auf den Boden – danach funktionierte sie nie wieder richtig! Mithilfe von ddrescue (mühselig) konnte ich einen großen Teil des Anfangs der Festplatte wiederherstellen. Aufgrund des physischen Schadens schaltete sie sich während des Vorgangs sehr häufig ab ...
Ich hatte eine kleine Laptop-Festplatte (150 GB) zur Verfügung (extern gemountet), auf die ich die ddrescue-Daten direkt extrahiert habe. Alternativ hätte ich die Daten in eine Image-Datei extrahieren und die Datei später mounten können, aber ich dachte, das direkte Schreiben der Daten auf eine Festplatte wäre einfacher.
Der Schlüsseltrick zur Rettung bestand darin, sowohl die MBR- als auch die NTFS-Bootsektordaten auf der Rettungsfestplatte manuell zu bearbeiten. Andernfalls wird die Festplatte von keinem Betriebssystem erkannt. Ich konnte unter Linux kein geeignetes Programm dafür finden, also habe ich mich an Windows gewandt. Es gibt ein praktisches Paket namens Windows Support Tools, das nicht mehr gepflegt wird, aber immer noch nützlich ist (siehe Link unten)! Das Tool, das ich zum Bearbeiten der Partition verwendet habe, ist Disk Probe. Stellen Sie sicher, dass Sie den Endsektorwert Ihrer Festplatte kennen (ich habe fdisk -l unter Ubuntu verwendet).
https://en.wikipedia.org/wiki/Windows_Support_Tools
Mithilfe eines guten Taschenrechners und etwas Kreativität lud ich die Festplatte in Disk Probe unter Windows, montierte sie und bearbeitete die Werte für die Endsektoren. Im MBR mussten zwei Wertesätze geändert werden, nämlich a) der Endsektor der Festplatte und b) der Endsektor der NTFS-Partition. Im NTFS-Bootsektor musste der Wert für die Gesamtzahl der Sektoren der Partition geändert werden. In jedem Fall wurde der numerische Wert verringert, um der verringerten „Dimension“ der kleineren Festplatte zu entsprechen (die Endsektoren wurden von 750 GB auf 150 GB geändert). Klicken Sie auf die Registerkarte Ansicht, um diese Werte zu bearbeiten.
Hier ist ein Bild von Disk Probe in Aktion beim Bearbeiten der NTFS-Bootsektordaten
Nach dem Bearbeiten der oben genannten Felder erkannte Windows die Partition als gültige, wenn auch beschädigte Partition. Ich ging in die Eingabeaufforderung und führte das Windows-Programm Chkdsk auf der beschädigten Festplatte aus (chdsk D:). Es war aufregend zu sehen, wie die Partition Datei für Datei wieder zum Leben erwachte! Das Programm baute die Partitionstabelle neu auf und ordnete alle Dateien, die von der beschädigten Festplatte kopiert worden waren, erfolgreich neu zu. Dateien, die außerhalb des Bereichs lagen (nicht kopiert) wurden nicht gefunden und daher eliminiert.
Den Grund für den nächsten Teil verstehe ich nicht, da Windows die 150 GB-Festplatte mit den enthaltenen Dateien erfolgreich neu erstellt hat. Trotzdem konnte Windows die Festplattenpartition nicht nativ öffnen, um Dateien anzuzeigen (es gab einen Fehler). Doch Ubuntu kam zur Rettung! Ich startete Ubuntu neu, mountete die externe Festplatte und ohne Probleme wurden alle wiederhergestellten Dateien angezeigt!
Hoffentlich erweist sich diese Methode zum Wiederherstellen von Dateien von einer großen Festplatte auf eine kleinere Festplatte auch für eine andere arme Seele als mich selbst als nützlich. Prost!