Wie SSD am besten klonen?

  • Hallo,

    ich möchte gerne eine SSD auf eine andere SSD klonen. Auf der zu klonenden SSD läuft im Moment ein SQL-Server für den ioBroker.

    Jetzt würde ich gerne die SSD auf eine m2.SSD klonen, die kann man direkt auf den Raspberry schrauben. Die alte und neue SSD sind beide 250GB groß. Vorhin hab ich die neue m2.SSD an den SQL Raspberry angeschlossen und dann versucht, mit dd die SSD zu klonen, das hätte aber ewig lange gedauert, da wurden in so ca. 500MB in einer halben Stunden kopiert.

    Wie kann ich die SSD also schnell und sicher klonen,,und zwar so, das der Klon dann auch bootfähig ist.

    Ich könnte das hier mit einem Windows-System oder mit einem DebianLinux machen.

    Danke schon mal

    Thomas

  • Erstelle doch am Windows PC mittels "Win32 Diskimager" oder wie das heißt. Da kannst du ein Image von deiner Ursprungs SSD machen und dann das Image auf egal welches Laufwerk flashen. Habe ich auch schon gemacht allerdings habe ich dann den "rpi-imager" unter Windows benutzt um das Image auf eine neue SD Karte zu flashen. Oder unter Linux (Debian, Ubuntu...was auch immer) kannst du mittels "Disks" (sudo apt install gnome-disk-utility) auch ein Image erstellen.

  • Du kannst an deinem Debian/Linux PC die neue SSD partitionieren und Dateisystem "installieren". Dann einfach die Daten von der alten SSD auf die neue SSD kopieren. Klonen (ein eins zu eins Abbild ist dann nicht nötig). Ich denke so was in der Art meinte RTFM.

  • Ich will die SSD klonen, um sie auszutauschen...

    Und dazu musst Du Bit für Bit, Byte für Byte, Sektor für Sektor, also das gesamte Speicherabbild auf die Ziel SSD übertragen, damit Du am Ende erfährst, dass die Ziel SSD ein paar Sektoren kleiner ist, als die Ursprungs SSD ? Mit allen unbeschriebenen, oder als gelöscht markierten (aber noch beschriebenen) Sektoren, mit der Badblocktabelle, die am Zielsystem keine Badblocks sind, und mit UUIDs, die bei Betrieb beider SSDs an einem Host gar nicht mehr einmalig sind. Schlimmstenfalls auch noch mit einem korrupten Filesystem, wenn bisher weder beim Booten, noch beim Mounten ein fschk durchgeführt wurde.

    Wenn Du nicht mit cp/rsync die tatsächlich aktiven Files richtig auf das neue Ziel übertragen willst/kannst, dann verkleinere (shrinke) das root/EXT4 Filesystem wenigstens auf den tatsächlichen Datenbestand mit resize2fs und übertrage dann die verkleinerte root Partition mit dd.

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Beide Varianten haben so Ihre zwei Seiten. Nachteil des Klonens ist, wie von den Kollegen schon genannt, dass unnötige "Leerdaten" und möglicherweise auch Dateifehler mitübertragen werden. Der Vorgang als solcher kann sich bei größeren Laufwerken hinziehen. Andererseits erfordert das Klonen weniger Vor- und Handarbeit und man kann sich sicher sein, dass die Zielplatte auch wirklich bootet (vorausgesetzt sie ist nicht tatsächlich zu klein).

    Als Alternative zu dd (das kann schonmal sehr böse ins Auge gehen, wenn man einen Flüchtigkeitsfehler bei der Laufwerksbezeichnung macht) will ich noch Clonezilla erwähnen. Da findet das Klonen interaktiver statt und man erhält genauere Platteninformationen und Sicherheitsabfragen.

  • Beide Varianten haben so Ihre zwei Seiten. Nachteil des Klonens ist, wie von den Kollegen schon genannt, dass unnötige "Leerdaten" und möglicherweise auch Dateifehler mitübertragen werden. Der Vorgang als solcher kann sich bei größeren Laufwerken hinziehen. Andererseits erfordert das Klonen weniger Vor- und Handarbeit und man kann sich sicher sein, dass die Zielplatte auch wirklich bootet (vorausgesetzt sie ist nicht tatsächlich zu klein).

    Als Alternative zu dd (das kann schonmal sehr böse ins Auge gehen, wenn man einen Flüchtigkeitsfehler bei der Laufwerksbezeichnung macht) will ich noch Clonezilla erwähnen. Da findet das Klonen interaktiver statt und man erhält genauere Platteninformationen und Sicherheitsabfragen.

    Hallo Herr Kaiser,

    könntest du bitte für einen DAU erklären wie das funktionieren würde?

    Natürlich habe ich eine Windows Rechner, und der Pi4B ist mit Buster im Netzwerk.

    Habe ich das richtig verstanden, das ich über das Netzwerk die komplette SSD (120GB) vom Pi auf eine andere SSD (128GB) klonen kann?

    Oder direkt in der GUI des Pi4?

    Angeschlossen ist die SSD via USB3.1 und einem GeekwormShield.

    Cool wäre es das gesamte OS in einem File zu haben um dieses dann auf einen anderen Pi4 (NVME) zu klonen.

    Der Source Pi hat eine SATA SSD.

    Danke für die Hilfe und lg

    Christian

  • Ja, über einen USB3-Hub....

    Spoiler anzeigen

    Pi4 V1.1, 4 GB, USB3-Hub, 250 GB SSD, Bullseye 64, Mate-Desktop, SD-Card Extender (ruht)
    Pi3b Pihole (Buster)
    Pi3b, 128-GB-SSD, Buster, mit 10,1" Monitor als MM (ohne Spiegel ;) )
    orangepi zero, ohne Beschäftigung
    Pi 5 4 GB im GeekPi-Gehäuse mit externer SSD (Bookworm)


    Warnung: Raspi und Co. machen süchtig! :)

  • und wieso nicht über einen freien Pi4 USB Anschluss? Hat das einen Grund?

    Ja, weil der Pi bei zwei direkt angeschlossenen SSD's Stromtechnisch in die Knie geht. Deshalb ab zwei SSD's oder HDD's unbedingt einen aktiven USB-Hub verwenden

  • Kopieren alle Daten vom aktuelle Verzeichnis in das Verzeichnis /dst

    Code
    tar cf - . | (cd /dst; tar xvf -)

    Dafür sollte das System, welches das Quell-Verzeichnis nutzt, möglichst nicht laufen

    Ich nutze das zum Beispiel, um bei einem PI das /-Verzeichnis auf ein anderes Verzeichnis zu kopieren.

    Dabei wird das eigentliche /-Verzeichnis zum Beispiel nach /mnt/1 gemountet, das neue Zielverzeichnis nach /mnt/2 und der obige Befehl über die Zeile

    Code
    cd /mnt/1
    tar cf - . | (cd /mnt/s; tar xvf -)

    aufgerufen.

    Wenn in der Konsole keine neuen Ausgaben erfolgen, auch kein Fehler, dann ist alles kopiert.

    Jetzt nach /mnt/1 das /boot-Verzeichnis des Quelldatenträgers (oder das ebenso kopierte /boot-Verzeichnis auf dem neuen Datenträger [minimum 512 MByte groß als VFAT erstellen] mounten und in /mnt/cmdline.txt die PART_UUID des neuen Datenträgers, der noch unter /mnt/2 gemountet ist, eintragen. Dann unter /mnt/s/etc/fstab bei / die UUID, hier kann es die lange sein) dieses Datenträgers eintragen.

    Und wenn man nun diese beiden Datenträger entmountet, und bei dem anderen PI ansteckt, kann man den PI vom neuen starten.

    Klonen ist etwas, was vollkommen überflüssig ist."DD" ist etwas für echte Festplatten, nicht aber für SSDs Und "dd" kopiert Fehler mit.

    Computer ..... grrrrrr

  • Beitrag von insight-er (29. November 2022 um 18:19)

    Dieser Beitrag wurde gelöscht, Informationen über den Löschvorgang sind nicht verfügbar.
  • Der Beitrag ist schon "etwas" älter und vielleicht ist Rasp-Berlin noch aktiv, denn das Problem ist heute aktueller denn je. Es mag aber gern auch ein anderer kompetenter Linuxer antworten ;). (Es gibt viele Beiträge im Netz zum klonen und irgendwie "verwirrend". Der Vorschlag von Rasp-Berlin erscheint mir da fast am sinnvollsten - auch wenn ich als Nicht-Linuxer es noch nicht ganz verstehe.)

    Bei einer SD-Karte funktionierte der WIN21-DiskImager bisher prima. Nachteil war das herunterfahren des Systems - Karte in WIN-PC - clonen - dann zurück. Aber es hat gut funktioniert. Nun will ich auf eine SSD mit 500GB und da funzt das natürlich nicht mehr. Und Gedanken um Backup/Restore/Partitionierung will ich mir gerne vorher machen.


    Meine Fragen dazu:

    1) Ist es richtig, dass es beim Raspi eine Boot-Partition gibt und die weitere Partition eine ganz normale Partition (Programme+Daten) ist?

    2) Daraus folgt dann wohl der Ansatz von Rasp-Berlin:

    - "Daten-Partition" normal kopieren

    - Boot-Partition clonen

    3) Genügt es dann nicht die Boot-Partition nur einmal zu klonen? Da ändert sich doch dann nix mehr?

    Meine Probleme Fragen, zu dem beschriebenen Vorgehen:

    1) Zitat "Dafür sollte das Quellsystem nicht laufen".

    Verstehe ich! ggf müssen auch vorher Backups aus der Datenbank geschrieben werden z.B. bei Domoticz, Influx,....
    Aber was heißt das?
    Auch System runterfahren - SSD an WIN-PC anstecken - copy all?
    Oder: erledigt dies das beschriebene mounten von / auf /mnt/1 ? (Verstehe ich zwar nicht, aber scheint so zu sein)

    2) Zitat: "Jetzt nach /mnt/1 das /boot-Verzeichnis des Quelldatenträgers (oder das ebenso kopierte /boot-Verzeichnis auf dem neuen Datenträger [minimum 512 MByte groß als VFAT erstellen] mounten"

    Verstehe ich nicht. Und auch nicht, wo ich die "PART_UUID des neuen Datenträgers" herbekomme.

    3) Könnte man das nicht irgendwie in ein Script packen, welches man dann nur aufrufen muß?

    4) Oder wird zwischenzeitlich das Raspi-Backup - Programm empfohlen, das vielfach im Netz erwähnt wird? Sollte ich mich damit beschäftigen?

    Noch eine etwas andere Frage:

    Ich hatte mal irgendwo im Netz gelesen, dass einer beschrieben hat wie man mehrere "Partitionen" auf einer SSD erstellt. Die Partition mit den Anwendungen+Daten cloned und dann zwischen den verschiedenen Partitionen leicht duch eine Änderung eines Eintrages auf der Boot-Partition umschalten kann. Finde das aber nicht mehr.

    Die Idee dahinter: Gerade im Smarthome kann man nicht wie bei einer normalen Anwendungsentwicklung losgelöst von der aktiven Anwendung programmieren. Ich brauche Zugriff auf die Sensoren/Aktoren d.h. kann nur am Produktivsystem arbeiten. Mit der o.g. Lösung könnte ich eine stabile Version in einer 2. Partition belassen um im Notfall darauf schnell zurückkehren zu können.

    Oder wie macht Ihr das? Die Steuerungsfunktionen für Boiler, Wallbox, etc sind essentiell und dürfen nicht länger ausfallen.

    Vielen Dank

  • Schau dir mal "sd-card copier" an. Gehört zur Grundausstattung.

    Damit mache ich meine SSD-Clone im laufenden Betrieb.

    Hat bis jetzt problemlos funktioniert, aber: Your own risc ?

    Spoiler anzeigen

    Pi4 V1.1, 4 GB, USB3-Hub, 250 GB SSD, Bullseye 64, Mate-Desktop, SD-Card Extender (ruht)
    Pi3b Pihole (Buster)
    Pi3b, 128-GB-SSD, Buster, mit 10,1" Monitor als MM (ohne Spiegel ;) )
    orangepi zero, ohne Beschäftigung
    Pi 5 4 GB im GeekPi-Gehäuse mit externer SSD (Bookworm)


    Warnung: Raspi und Co. machen süchtig! :)

  • Zu 1)

    Es gibt standardmäßig 2 Partitionen, eine fat als /boot und eine ext4 als /

    Siehe auch Dateisystem

    Zu 2 und 3)

    Du kannst die ganze SD auf die SSD inklusive der Partitionen klonen, oder du musst manuell die Partitionen für boot und root anlegen, die Dateisysteme erstellen und formatieren und die Daten kopieren.

    Zu Problem 1)

    Man sollte immer ein funktionierendes Backup haben, falls etwas schief läuft.

    Das einbinden des Datenträgers ist etwas anderes, siehe man mount oder hier auf deutsch.

    2)

    Die PART_UUID kannst du mit blkid ausgeben lassen, die richtige für root muss dann auch in /boot/cmdline.txt stehen, z.B. root=PARTUUID=1a2ba3ca-02 und auch in der /etc/fstab müssen die richtigen für /boot und / stehen.

    3 und 4)

    Kann ich nichts dazu sagen, ich habe raspiBackup noch nie benutzt. Bei meinem Umzug auf die SSD habe ich die SSD manuell partitioniert. 1GB fat32 für /boot und den Rest ext4 für /, danach habe ich die Daten per rsync auf die SSD geschoben und die UUIDs angepasst, das hat problemlos geklappt.

    P.S. Datenbanken sollten nicht gerade beschrieben werden beim kopieren, also vorher besser den Dienst stoppen.

  • Kann ich nichts dazu sagen, ich habe RaspiBackup noch nie benutzt.

    raspiBackup (kleines r und grossed B ;) ) kann nicht direkt Clonen. Dazu ist rpi-clone wie auch der schon erwaehnte sd-card copier besser geeignet. Aber wenn man schon ein Backup mit raspiBackup erstellt hat kann man dieses auf jedes beliebige Geraet zurueckspielen und hat damit letztendlich die Raspberry auch gecloned. Also z.B. hat man ein Backup einer SD Karte und restored es auf eine SSD. Oder man hat ein Backup einer USB Platte und restored es auf eine SSD.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!