Problem: SSD 1:1 auf andere SSD kopieren

  • Hallo zusammen,


    Kann mir bitte jemand helfen ?

    Ich möchte eine SSD kopieren (als full Backup) mit dem SD Card COPIER unter Bullseye auf einem Raspi 4 / 4GB. Die zweite SSD hat eine eigene Stromversorgung.

    Leider gibt es da Probleme:


    a.: SD Card COPIER: Neue SSD --> Nachdem die Vorbereitung durchgelaufen ist und der Kopiervorgang 10 Minuten läuft, "friert" der Raspi ein. (mehrfach probiert)

    b.: SD Card COPIER: SSD vorher mit einem Standard-Image bespielt -> Fehlermeldung "could not create FAT"

    c.: SD Card COPIER: nochmal probiert, wie b. -> Fehlermeldung "Drive has changed" :conf:


    Ich verwende aktuell zwei 240GB SSD´s. Unter Buster mit zwei 128GB SSD´s hatte das immer prima funktioniert.

    Sind die 240er zu groß ?

    Oder was mache ich falsch ?


    Gruß, Holger

  • Moinsen,


    240 GB sind nicht zu groß !
    Keine Ahnung was du falsch machst. Nur wenn man einen größeren Datenträger Clonen will macht man das nicht aus einem aktiven System heraus, sondern macht das mit einem LIVE System entweder über die SD-CARD oder nutzt andere Tools wie zB CloneZilla

    Franky

  • Nur wenn man einen größeren Datenträger Clonen will macht man das nicht aus einem aktiven System heraus, sondern macht das mit einem LIVE System entweder über die SD-CARD oder nutzt andere Tools wie zB CloneZilla

    Hallo,


    danke für die Tipps, die habe ich jetzt beherzigt:

    Ein "frisches" Bullseye auf einer SD-Karte zum booten verwendet und dann die SSD´s mit sep. Stromversorgung per USB angeschlossen. Leider hat das nichts geändert. Damit scheiden "Stromversorgungsproblem" oder "korruptes Filesystem" m.E. ebenfalls aus.

    Für CloneZilla müsste ich die Platten ja an einen PC anschließen, oder ? Das sehe ich aber nicht so ganz ein. Ein Raspi 4 muß das doch können. :no_sad:


    Gruß, Holger

  • Moinsen,


    auch wen Linux vieles kann, außer eigenständig Kaffee kochen, ist es immer ein Graus, wenn man versucht von einem aktiven System aus einen Clone seines selbst zu erzeugen. Da du keine Angaben machst, ob dein OS auf dem PI möglicher Weise swapt, und es damit auch möglicher Weise ständig zu Änderungen auf dem Ausgangsdatenträger kommen kann, gehe doch den einfachen Weg.
    Einen x86 / x86-64 Computersystem wirst du wohl auch noch besitzen ?
    Erstelle einen Bootdatenträger USB mit Cloneilla, hänge den USB Hub mit beiden SSD an diesen, starte von USB das ganze System mit dem LIVE System welches Clonezilla mitbringt und lass ihn machen.
    Wenn du dir nicht sicher bist welches Laufwerk in der Linux Notation welches ist, dann melde im BIOS zuvor alle lokalen Datenträger vorübergehend ab, damit du dir deine Boot- und Systempartition auf dem Computer nicht zerstörst.

    Franky

  • Kopieren mit dd

    Die SD-Karte kann man 1:1 auf die SSD übertragen, da die SSD ohnehin größer ist, als die SD-Karte.

    Wenn man das direkt vom RPi machen will, muss / ReadOnly eingehängt werden.


    Wie bereits beschrieben mit dd kopieren:

    Code
    sudo dd if=/dev/mmcblk0 of=/dev/sda bs=1M oflag=sync
    # 1 MiB Blockgröße bei der Übertragung

    Wenn /dev/mmcblk0p2 nicht ReadOnly eingehängt ist, dann braucht man das erst gar nicht zu versuchen.

    Folgender Befehl könnte die Root-Partition ReadOnly remounten. Falls bereits Dateien schreibend geöffnet sind, geht das nicht.


    Root / des laufenden Systems -> readonly

    Ein Backup von einem laufenden System zu erstellen, ist keine gute Idee, aber möglich, wenn man das Root-Dateisystem ReadOnly remount kann.

    Code
    sudo mount -o remount,ro /


    Besser wäre es, das gleich auf einem Linux-Desktop zu machen (z.B. von LiveCD irgendein Live-Debian booten).

    Wenn man dann ein externes Kartenlesegerät anschließt, erscheint die SD-Karte als /dev/sdX wobei X der nächste freie Buchstabe ist.

    Partition 2 vergrößern

    Nachdem die Daten 1:1 kopiert worden sind, muss noch die zweite Partition angepasst werden.

    Dazu mittels fdisk das Ziellaufwerk öffnen (z.B. /dev/sdb).

    Dateisystem innerhalb der Partition vergrößern

    Nun ist die Partition auf dem Ziellaufwerk vergrößert, aber das ext4-Dateisystem hat immer noch die alte Größe.

    Um das ext4-Dateisystem zu vergrößern:

    Code
    sudo fsck.ext4 -f /dev/sdb2
    # falls /dev/sdb das Ziellaufwerk ist
    sudo resize2fs /dev/sdb2

    Keine Änderung der PartUUID

    An der /etc/fstab und /boot/cmdline.txt muss nichts geändert werden, da sich die PartUUID nicht ändert.

    Die PartUUID wird beim Erstellen der Partitionstabelle angelegt und die Partitionsnummern werden mit einem Bindestrich angehangen.



    PartUUID nach dem die 2. Partition neu erstellt worden ist:

    Code
    [root@andre-Fujitsu-i5 ~]# lsblk -o NAME,UUID,PARTUUID
    NAME      UUID                                 PARTUUID
    loop0
    ├─loop0p1 28BC-DD90                            00a9f9df-01
    └─loop0p2 04d00667-3771-4c58-ae48-8815de85cc6e 00a9f9df-02


    Die UUID wird hingegen zusammen mit dem Dateisystem erstellt, das sich innerhalb der Partition befindet.

    Der Test erfolgte mit einem loopdevice.


    Images mit losetup als Blockgerät bereitstellen

    Hilfreich ist noch losetup, wenn man z.B. mit Images arbeiten muss und diese mounten möchte. Der Vorteil ist, dass man unkompliziert auf die Partitionen zugreifen kann und alle Tools wie z.B. fdisk wie gewohnt damit funktionieren.


    Code
    # Image mounten
    # leeres Verzeichnis erstellen
    sudo mkdir /mnt/image
    sudo losetup -f -P --show /home/pi/Downloads/2022-09-22-raspios-bullseye-armhf-lite.img
    # -f     := force
    # -P     := Partitionen erkennen
    # --show := Blockgerät anzeigen
    
    sudo mount /dev/loop0p2 /mnt/image
    sudo mount /dev/loop0p1 /mnt/image/boot


    Komprimierte Images direkt mounten (ReadOnly)

    Wenn man sich z.B. ein Image für den RPI herunterlädt, sind die Dateien meist mit xz oder gzip komprimiert. Das ist kein Archivformat, sondern nur ein Kompressionsformat.


    Mit dem tool nbdkit kann man ein Blockgerät mounten, dass ein Plugin nutzt, um die xz on-the-fly zu entpacken.

  • Hi,

    der Befehl "sudo dd if=/dev/sda of=/dev/sdb" hat die Platte komplett kopiert. Aber das Ergebnis ist nicht bootfähig --> Kernel panic :no_sad:

    Immerhin bin ich einen Schritt weiter, --> kein Absturz.


    Im Internet empfiehlt jemand, folgenden Befehl :

    sudo dd if=/dev/sda bs=1M iflag=direct | dd of=/dev/sdb bs=1M oflag=direct


    Ich werde es ausprobieren ... :)


    Gruß, Holger

  • Geht auch kürzer mit einem Befehl:

    Code
    sudo dd if=/dev/sda of=/dev/sdb bs=1M iflag=direct oflag=direct


    Eigentlich sollte das ausreichen:

    Code
    sudo dd if=/dev/sda of=/dev/sdb bs=1M oflag=sync


    Und zur Sicherheit danach nochmal:

    Code
    sudo sync

    Wenn der Befehl beendet ist (keine Ausgabe), ist der sync abgeschlossen und alle Daten sind auf die Datenträger geschrieben worden. Ohne den sync kann es passieren, dass man die Festplatte vom PC trennt und der noch gar nicht fertig mit Schreiben ist (auch wenn dd schon fertig ist).

    Mit oflag=sync wird immer gewartet, bis die Daten geschrieben sind.

  • Hallo zusammen,


    leider endete auch dieser Versuch:

    sudo dd if=/dev/sda of=/dev/sdb bs=1M oflag=sync

    sudo sync


    beim Boot-Versuch mit der Fehlermeldung:

    end Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-Block(8,2)


    und die Zielplatte kann auch nicht gemounted werden:

    error mounting /dev/sdb2/media/pi/rootfs wrong fs type, bad option ...


    Hat jemand noch eine Idee ?


    Gruß, Holger

  • Nimm mal tar oder rsync zum Kopieren. Dann noch die UUIDs in /etc/fstab und /boot/cmdnline.txt anpassen.

    Hast Du schon Deine Raspberries gesichert :fies:

    Bei mir erledigt das raspiBackup vollautomatisch jede Woche :shy:
  • Vielleicht hat ja einer deiner Datenträger defekte Sektoren oder das Filesystem des Quelldatenträgers hat Fehler.


    Testen könnte man dies z.B. mit badblocks /dev/<Datenträger>


    Vor dem Einhängen des kopierten Datenträger, könnte bei Problemen auch ein Filesystemcheck helfen.


    Ich verwende zum Kopieren von Datenträgern lieber ddrescue, das hat besonders bei der Datenrettung von "Problemdatenträgern" einige nützliche Funktionen.

  • Nochmals Danke für die Tipps,


    ich vermute inzwischen auch, dass das Dateisystem (Quelle) einen Fehler hat.

    Habe probeweise zum booten auch eine SD mit Buster verwendet, kopiert zwar ohne Absturz, aber das Ergebnis ist ebenfalls nicht bootfähig.

    Die Dateien scheinen augenscheinlich kopiert worden zu sein.

    ddrescue probiere ich auf jedenfall aus :)