Hallo,
wie könnte ich den Inhalt einer Festplatte 1:1 auf eine neue Austausch-Festplatte klonen?
Clonezilla ist mir bekannt, habe das aber noch nicht gemacht.
Vielen Dank für Tipps
dd if=/dev/sdN of=/dev/sdM
You should of course be very sure what to fill in for N (the “sending” device) and M (the “receiving” device).
Of course sdM should at least be as large as sdN.
And nothing on it must be in use (file systems must NOT be mounted, Swap must be switched OFF as such).
Oh, entschuldige. Auf Deutsch:
Du solltest sehr sicher wissen was N (das original) und M (die Kopie) ist. Sonst wäre ein Überschreiben eines unschuldige Scheibes möglich.
Natürlich soll sdM wenigstens so groß wie sdN sein.
Und Alles sollte nicht in gebrauch sein (etwaige Dateisystemen nicht angehängt und etwaige Swap nicht eingeschaltet).
Hallo,
@hcvv
wenn ich die Festplatten 1:1 klone wie Du gezeigt hast, brauche ich die neue Festplatte nicht formatieren?
Das Original N hat zwei Partitionen.
Wenn du das vor dem Kopieren machen sollte hat das kein Zweck da das alles wieder überschrieben wird met dem Kopie.
Wenn du das nach dem Kopieren machen sollte wäre das Kopieren umsonst, weil du dann das Kopierte wieder überschreibt.
Paß mas auf. Ich habe keine Idee warum du diese Platte “klonen” möchtest. Ich habe dir nur eine einfache Methode angereicht um eine ganze Platte (oder auch änliche Massenspeicher Geräte) Byte für Byte zu kopieren.
Byte für Byte heiß also inklusive Partitionstabelle und alles. Was auch darauf sein möchte.
Entweder wir verstehen uns gar nicht, oder du hast eingentlich weing Idee darüber was ein Spechergerät ist, was alles darauf sein kann, was “formatieren” (slechtes Wort sowieso) eigentlich ist.
Ich habe nicht gesagt du solltest etwas “klonen”, Die Entscheidung hast du aus irgendeinen Grund genommen.
Hallo,
@hcvv
also ich möchte die bestehende Festplatte durch eine neue Festplatte ersetzen, um zu sehen, ob meine Schwierigkeiten die mein Rechner macht, davon kommen. Den Inhalt der bestehenden Festplatte möchte ich natürlich behalten. Das einfachste wäre ein Klonen. Dann weiss ich auch sicher, ob es an der Hardware der Festplatte liegt. Falls die Schwierigkeiten nach den Austausch mit der neuen geklonten Festplatte weiter bestehen, dann muss der Fehler wo anders zu finden sein.
Und Alles sollte nicht in gebrauch sein (etwaige Dateisystemen nicht angehängt und etwaige Swap nicht eingeschaltet).
Muss die Swap Partition auch umounted sein?
Also sag mir bitte, ob ich einfach den oben gezeigten Befehl nehmnen kann und damit eine neue Festplatte geklont wird.
Siehe Post #2 hieroben.
Bedenke dabei das die neue Platte nach dem kopieren einfach durch auswechseln getestet worden kann. Die alte Platte bleibt unversehrt und kann wieder zurückgesetzt worden.
Also, wie gefährlich sieht das aus?
Noch etwas.
Wenn deine neue Platte nicht gleich groß ist wie die alte Platte (also größer) und ein GPT hat, befindet der “backup partition table” sich jetzt nicht mehr am physische ende der PLatte. Das sollte repariert werden. Also wenn alles geklapt hat noch folgendes
gdisk /dev/sdX
(natürlich as richtige X herausfinden, ist nach dem Auswechseln vielleicht jetzt /dev/sda))
Und dan die Kommandos
r
um zum recovery Menu zu gelangen
d
um den backup Partitionstabelle aus der haupt Partitionstabelle auf zu bauen
w
jetzt wird die Änderung auf die Platte geschrieben und das gdisk Program beendet.
Hallo,
@hcvv
also die neue Festplatte hat die gleiche Größe. Ich brauche dann den letzten poste von Dir nicht beachten?!
Ich habe die neue Festplatte über Nacht klonen lassen.
Was gut wäre, wenn man den Befehl dd verbose laufen lassen könnte. Leider hatte ich keine Kontrolle daüber, was sich abgespielt hat, oder wie weit der Fortschritt beim Klonen war. Auch wurde mir keine MItteilung gegeben, als derProzess beendet war. Ich habe einfach auf verdacht mit Strg+C abgebrochen.
Dann kam eine Meldung:
Tuxedo2020:/# dd if=/dev/sdb of=/dev/sdd
2611390425+0 records in
2611390425+0 records out
1337031897600 bytes (1.3TB, 1.2TiB) copied, 49556 s, 27.0 MB7s
Anscheinend ist alles ohne Fehler abgelaufen.
Meine Frage jetzt ist:
Kann ich ohne die alte Festplatte sdb abzustecken, die neue Festplatte schon testen? Die neue Festplatte sdd steckt am USB 3.0 und ist mit einem aktiven SATA Adapter angeschlossen.
Sobald ich boote, wird die ssb auf /home gemountet. Über tty1 müsste ich doch die sdb umounten können? Und anschließend könnte ich die sdd auf /home mounten? Oder müsste man beim Booten einen Bootparameter setzten?
Bitte gib mir Bescheid, ob ich damit richtig liege. Falls nicht, bitte gib dazu Hilfestellung. Ich möchte wenn möglich ohne die sdb auszubauen erst testen. ob die neue Festplatte sdd eine Problemlösung bringt.
Wenn das exact so ist, natürlich nicht.
Es sollte aber doch richting enden und dann einen neuen Shell Prompt zeigen. Ich bin da nicht sicher ob das schon fertig war.
Ich nehme an du hast erst mal
man dd
durchgelesen (wenn nicht um zu sehen ob ich dir nicht beschwindel, dann doch um zu lernen).
Da steht drin:
Sending a USR1 signal to a running ‘dd’ process makes it print I/O statistics to standard error and then resume copying.
Also mit
kill -s USR1 <PID>
bekommst du Ausgaben über den Vorgang.
Den PID findest du mit
ps -ef
irgenwo am ende, oder um das ganze kürzer zu machen
ps -ef | grep 'dd if=/dev/sdb'
Dann gibt es warscheinlich noch immer zwei. Wähle das Richtige PID.
Natürlich kannst du schon einiges testen. Erstens würde ich schauen ob die gleiche Partitionierung da ist:
fdisk -l
und/oder
lsblk -f
Pass auf, weil alles kopiert ist, sind die UUIDs auf beide Platten gleich. Das könnte zu Verwechslungen leiten.
Um einzelne Dateisystemen zu testen einfach irgenwo einhängen und schauen ob das geht, und wenn ja, mal herumgucken.
Z.B.
mount /dev/sdd1 /mnt
Wenn das gelingt
cd /mnt
ls -l
.........
.........
cd
umount /mnt
Und das Gleiche für etwaige sonstige Dateisystemen auf sdd2, usw.
Hallo,
Natürlich kannst du schon einiges testen. Erstens würde ich schauen ob die gleiche Partitionierung da ist:
Code:
fdisk -l
URL: SUSE Paste
Aus meiner Sicht sollte das Klonen gelungen sein. Exakt die gleiche Ausgabe von fdisk.
und/oder
Code:
lsblk -f
Pass auf, weil alles kopiert ist, sind die UUIDs auf beide Platten gleich. Das könnte zu Verwechslungen leiten.
URL: https://paste.opensuse.org/34176118
Um einzelne Dateisystemen zu testen einfach irgenwo einhängen und schauen ob das geht, und wenn ja, mal herumgucken.
Z.B.
Code:
mount /dev/sdd1 /mnt
URL: SUSE Paste
Anscheinend hat der harte Abbruch mit Strg+C von dd… dem Klonen doch irgendwie geschadet. Das neue Laufwerk lässt sich nicht mounten.
Erstens: das Benutzen von paste.opensuse.org ist zwar richtig für Bilder und ganz große Mengen von Text, aber für so kleinere Sachen wie hier ist es umständlich für dich und für uns. Dafür gibt es CODE Umfassungen. Das ist der Knopf mit #. Copy/Paste alles daszwischem. Siehe auch Using CODE tags Around your paste
Auch ist die Ausgabe von lsblk unvollständig. Da gehört alles dazu: Kommandozeile, alle Ausgabezeilen und nächste Promptzeile. Ich zweifle auch daran das fdsisk Komplett ist. Da sehe ich ein System ohne root Dateisystem und ohne sda. Kaum zu glauben.
Frage ist auch. Du hast in Post #8 gezeigt: von sdb nach sdd. Jetz zeigt du sdb und sdc. Was hat sich geändert?
Dann zur Sache.
Die fdisk Ausgabe zeigt das wenigstens die Partitionstabelle heil kopiert worden ist. Mehr eingentlich nicht. Aber das ist schon was.
Das unvollständige lsblk zeigt dat sdc1 schon anghängt ist. Und zwar von irgendein Desktopbenutzer. Während solche Arbeiten als die jetzt geschehen sollten andere Benutzer eigentlich gar nicht da sein. Und sicher nich auf die PLatten herunstochern. Trotzdem hat dieses unkontrolierte Verfahren als vorteil das wir sehen das sdc1 angehängt worden kan. Ob es vollständig und unversehrt ist wissen wir aber nicht.
Das Anhängen von sdc2 geht dann überhaupt nicht. Da gibt es anscheinend am Anfang nichts Richtiges.
Meine Schlußfolge: Das dd war wirklich nicht zu ende.
Also nochmals. Wir könnnen versuchen das zu optimieren:
dd if=/dev/sdb of=/dev/sd? bs=1M
Ich habe auch ein leichteren Weg zum ab und zu schauen wie es geht (natürlich von ein andere Terminal/Console als root):
killall -SIGUSR1 dd
Das würde ich auch vermuten.
dd status=progress if=/dev/sdX of=/dev/sdY
soll laut
info '(coreutils) dd invocation'
Fortschrittsmeldungen ausgeben. Ich habe das aber noch nicht ausprobiert.
Viele Grüße
susejunky
Hallo,
also das Klonen der Festplatte hat bei allen Versuchen nicht geklappt.
Beim letzten Versuch mit Clonezilla und einer Wiederherstellungsprüfung am Ende der Erstellung eines Klone-Image, ergab die Fehlermeldung:
Partclone fail, please check /var/log/partclone.log
Die folgende Partition im Image ist defekt: sdb2 (das ist die /home Partition).
Also versuche ich jetzt eine 1:1 Kopie der Partition sdb2 /home Partition mit tar.
Dazu eine entscheidende Frage:
Wenn ich das tar-Archiv ab Verzeichnis /home erstelle, dann erhalte ich beim Entpacken auf der Partition sdb2 auch das Verzeichnis ab /home/Benutzer/… usw.
Das Verzeichnis /home ist doch aber ein Systemverzeichnis und gehört zum Linux filetree? Das heißt ich hätte beim Entpacken dann 2 mal /home, einmal vom Linux filtree und einmal vom tar-Archiv, nach dem mounten auf /home. In etwa so: /home/home/Benutzer/ … usw.
Das hieße, ich darf das tar-Archiv nur ab Verzeichnis /Benutzer packen, damit dann beim Entpacken nur die /Benutzer auf der Partition sdb2 angelegt sind; wenn dann sdb2 auf /home gemountet wird, müsste das gesamte Verzeichnis richtig angelegt sein - /home/Benutzer/ … usw.
Ist hier meine Denkweise richtig? Ich möchte verhindern, dass ich das tar-Archiv x-mal neu anlegen muss bis herausgefunden habe was richtig wäre. Ein tar-Archiv anlegen dauert ein paar Stunden.
Vielen Dank, wenn mir dabei jeman einen klaren Blick verschaffen könnte.
Wenn das mit dd nicht klappt, hat es kein Zweck das noch mit adere Magie zu versuchen. Du mußt herausfinden warum es nicht geht mit dd.
Bist du ganz sicher das /dev/sdb außer Betrieb war während des Kopierens? Ich habe da Zweifel ob du wirklich die beiden Dateisystemen abgehängt hast.
Übrigens habe ich einige Fragen gestellt und darauf keine Antwort bekommen. So wird die Zusammenarbeit erschwärt wenn nicht unmöglich.
Ich möchte doch noch was sagen.
Es haben hier zei Leute gesagt das das dein dd nicht zu ende war. Es ist auch angegeben worden wie man vielleicht das ganze beschleunigen kann.
Das einige was darauf zurück kommt is das oben zitierte. Nichts darüber ob es schneller geht. Nichts darüber ob du jetzt bis zum End gewartet hast. Nur “es klappt nicht”. auf so ein Report ist leider kein bedeutuingsvolles Antwort möglich.
Wenn du die angegebene Vervolgungsweise nicht mitmachen möchtest ist das schon berechtigt. Aber sag dann einfach “Danke, aber ich mache mich euch nicht mehr weiter” und tue dann etwas Anderes. Das macht uns wenig. Etwas verlorene Zeit, aber wenigestens ein Danke.
Wenn du dan später wieder irgenwo hängen bleibst kannst du immer wieder einen neuen Draht starten mit eine gute Überschrift und gute Beschreibung Das lockt dann wieder andere (or vielleicht die gleiche) Leute die versuchen werden zu helfen.
Aber auch dann: gebe viel Information (Niemand ist hellsehend), bestens keine Schlussfolgen, aber Rechnerausgaben. Antworte auf alle fragen (wenigstens mit “das weiss ich nicht” oder “wie kann ich das herasufinden”, aber nicht durch ignorieren). Und gehe nicht auf einmahl in eine ganz andere Richtung, dabei möglich Beweise vernichtend und Leute in Verwirrung stehenlassend (die kommen dan vielleicht nie wieder zu dir zurück).
Wer keine Lust auf ein “dd-Gebastel” hat, sollte die vollständige Backup-/Restore-/Klone-Anleitung für SUSE Linux Enterprise unter:
https://forums.suse.com/discussion/comment/59193#Comment_59193
beachten. Diese Anleitung sollte auch mit openSUSE LEAP und deren Installations-Medien und Live-Medien funktionieren.
https://de.opensuse.org/SDB:Live_USB_Stick
Vorbedingung: Bis auf die EFI-Partition (FAT32) und die SWAP-Partition (SWAP) sind alle Partitionen (root- und home-Partition) der SSD/Festplatte mit XFS formatiert.
Hinweise zu XFS-Reflink unter:
https://forums.suse.com/discussion/comment/61030
beachten.
Viel Glück!
Hier noch ein Auszug aus meiner Anleitung für den Raspberry Pi, wie man der root-Partition das Dateisystem wechselt.
Alt: Ext4
Neu: XFS
Diese Raspberry Pi-Anleitung sollte helfen beim Wechsel der Partitionen auf das Dateisystem XFS.
# mkdir /usr/lib/microcode/efi
# mkdir /usr/lib/microcode/root
# mkdir /usr/lib/microcode/backup
# fsck.vfat -rvV /dev/sdc1
# fsck.ext4 -f /dev/sdc2
# mount -r /dev/sdc1 /usr/lib/microcode/efi
# mount -r /dev/sdc2 /usr/lib/microcode/root
# mount /dev/sdd1 /usr/lib/microcode/backup
# df -h
# mount
# dmesg
Backup der EFI-Partition erstellen
--------------------------------------------------------------------------------
# cd /usr/lib/microcode/efi
# tar -cf /usr/lib/microcode/backup/Server1_efi_J2020M02T22.tar *
Backup der ext4-Partition erstellen
--------------------------------------------------------------------------------
# cd /usr/lib/microcode/root
# tar -c --xattrs --one-file-system -pf /usr/lib/microcode/backup/Server1/Server1_root_J2020M02T22.tar *
Wiederherstellung Raspberry Pi
--------------------------------------------------------------------------------
1.) Neue Partitionstabelle erstellen:
# umount /dev/sdc1
# umount /dev/sdc2
# umount /dev/sdd1
# mount
# df -h
# cfdisk --zero /dev/sdc
=> dos
Gerät Boot Anfang Grösse Kn Typ Bezeichnung Dateisystem Typ
/dev/sdc1 * 2048 256MB c W95 FAT32 (LBA) system-boot FAT32 Primär
/dev/sdc2 Rest 83 Linux writable xfs Primär
2.) Neu erstellte Partitionstabelle kontrollieren
# cfdisk /dev/sdc
3.) Neu erstellte Partitionen formatieren und kontrollieren:
# mkfs.vfat -n SYSTEM-BOOT -f 2 -F 32 /dev/sdc1
# fatlabel /dev/sdc1 system-boot
# fsck.vfat -rvV /dev/sdc1
# mkfs.xfs -m reflink=1,crc=1 -fL writable /dev/sdc2
# mount /dev/sdc2 /usr/lib/microcode/root
# umount /dev/sdc2
# mount
# df -h
# dmesg
# xfs_repair /dev/sdc2
# mount -r /dev/sdd1 /usr/lib/microcode/backup
# mount /dev/sdc1 /usr/lib/microcode/efi
# mount /dev/sdc2 /usr/lib/microcode/root
4.) Restore-Vorgang starten:
# cd /usr/lib/microcode/efi
# tar -x -f /usr/lib/microcode/backup/Server1_efi_J2020M02T22.tar
# cd /usr/lib/microcode/root
# tar -x --xattrs -pf /usr/lib/microcode/backup/Server1/Server1_root_J2020M02T22.tar
5.) Wiederhergestellte Partitionen kontrollieren
# df -h
# ls -alh /usr/lib/microcode/efi
# ls -alh /usr/lib/microcode/root
6.) Freier Speicherplatz auf der Speicherkarte als „frei“ markieren (TRIM)
# fstrim -v /usr/lib/microcode/efi
# fstrim -v /usr/lib/microcode/root
Rasberry Pi-Installation anpassen
--------------------------------------------------------------------------------
Umstellen von ext4-Partition auf xfs-Partition:
# vim /usr/lib/microcode/efi/cmdline.txt
=> rootfstype=xfs
# vim /usr/lib/microcode/root/etc/fstab
=> ",attr2,inode64,noquota" ergänzen
Ext4 hat sich im harten Einsatz (Raspberry Pi 1x täglich per Zeitschaltuhr ein/ausschalten) nicht bewährt. XFSv5 hat sich in diesem Umfeld bewährt!