Habe ich 'rpi-clone' irgendwo nametlich erwähnte? Ich habe 'dd' erwähnt
Warum hast Du dann überhaupt Deinen Beitrag verfasst?
BTW: rpi-clone hat sich bewährt und kommt bei mir immer Freitags zum Einsatz, nachher auch wieder. Das vergibt übrigens automatisch neue UUIDs und PARTUUIDs und verwendet, wie schon erwähnt rsync. Um u.a. diesen ganzen Kram muss ich mich nicht selber kümmern.
Klonen von interner Nvme auf externe Nvme? Schau mal ob du hier fündig wirst!
Muss noch dazu sagen. Ich verwende den dd-Befehl auf einem LapTop mit Sparky-Linux und habe zwei SD-USB-Adapter. Zuerst stecke ich dann die Surce vom RPi und mache ein lsblk dann die Clone-SD, damit ich sicher bin, dass ich nicht die Source mit dem Target überschreibe!
Bei mir geht diese Befehl und die neue SD bootet wie die alte.
Noch ein Hinweis: Wenn ich ein kleineres Target habe, verkleinere ich die Source-SD zuvor mit gparted.
immer Freitags zum Einsatz, nachher auch wieder
Gerade geschehen... Nur falls es jemanden interessiert, hier die Ausgabe davon:
hyle@rpi5:~ $ sudo rpi-clone sdb
rpi-clone Version: 2.0.27
Booted disk: nvme0n1 512,1GB Destination disk: sdb 63,9GB
---------------------------------------------------------------------------
Part Size FS Label Part Size FS Label
1 /boot/firmware 512 0M fat32 bootfs 1 512 0M fat32 bootfs
2 root 476 4G ext4 rootfs 2 59 0G ext4 rootfs
---------------------------------------------------------------------------
== SYNC nvme0n1 file systems to sdb ==
/boot/firmware (79,0M used) : SYNC to sdb1 (512,0M size)
/ (13,2G used) : SYNC to sdb2 (59,0G size)
---------------------------------------------------------------------------
Run setup script : no.
Verbose mode : no.
-----------------------:
Ok to proceed with the clone? (yes/no): y
Syncing file systems (can take a long time)
Syncing mounted partitions:
Mounting /dev/sdb2 on /mnt/clone
=> rsync // /mnt/clone with-root-excludes ...
Mounted /dev/nvme0n1p1 on /boot/firmware already
Mounting /dev/sdb1 on /mnt/clone/boot/firmware
=> rsync /boot/firmware/ /mnt/clone/boot/firmware ...
Editing /mnt/clone/boot/firmware/cmdline.txt PARTUUID to use 629ed166
Editing /mnt/clone/etc/fstab PARTUUID to use 629ed166
===============================
Done with clone to /dev/sdb
Start - 18:48:15 End - 18:49:10 Elapsed Time - 0:55
Cloned partitions are mounted on /mnt/clone for inspection or customizing.
Hit Enter when ready to unmount the /dev/sdb partitions ...
unmounting /mnt/clone/boot/firmware
unmounting /mnt/clone
===============================
hyle@rpi5:~ $ Die Quelle ist eine NVMe und das Ziel ist eine SD-Karte. Die Option -f ist bei mir nicht nötig, weil die "Partitionsstruktur" auf dem Ziellaufwerk schon gegeben ist und die Dauer hängt von den Dateien ab, die sich auf dem Ziellaufwerk vom Quelllaufwerk unterscheiden, aber das sollte klar sein, wenn man rsync kennt.
Machst Du das manuell oder per crontab/systemd timer?
Ich mache das manuell und das hat folgende Gründe:
1. Verwende ich zwei SD-Karten, die ich im wechsel dafür nutze und somit austausche.
2. Möchte ich die nicht immer am RPi, bzw. dem aktiven USB-Hub stecken lassen.
3. Ist hier die Bootreihenfolge SD > USB > NVMe. Es würde also erst von USB gebootet werden und somit stören, wenn ich täglich meinen RPi 5 als Hauptrechner mit Strom versorge.
Und weitere Gründe sind u.a., dass damit ja auf komplette Laufwerke geschrieben und im schlimmsten Fall könnte das auch ein falsches sein. Ich habe hier öfter HDDs mit Videodateien angeschlossen und dann wäre das fatal, wenn die versehentlich überschrieben werden würde. Deshalb sehe ich vorher zur Sicherheit mit lsblk nach.
Der Hauptgrund ist aber, dass ich das Backup erstelle und danach das System per apt aktualisiere und da will ich immer dabei sein um zu sehen, ob etwas schief läuft. Da kommt es auf die drei Minuten vorher um ein Backup zu erstellen und testen auch nicht an. Im Durchschnitt kostet mich Backup erstellen + testen und System aktualisieren + Neustart ca. 10 Minuten Zeit. Das ganze einmal pro Woche zu machen ist mir mein System Wert und m.M.n. auch keine Zeitverschwendung. 
Das sind valide persönliche Gründe. Ich mache die apt updates auch immer manuell.
Und weitere Gründe sind u.a., dass damit ja auf komplette Laufwerke geschrieben und im schlimmsten Fall könnte das auch ein falsches sein.
Das ist ein kleiner Nachteil von rpi-clone: Es kann keine PARTUUID als Ziel angegeben werden. Dann wärest Du diesbezüglich sicher.
EDIT: Oder kann man irgendwie per fstab EIntrag definieren dass eine PARTUUID ein bestimmtes /dev/sdx wird?
Es kann keine PARTUUID als Ziel angegeben werden. Dann wärest Du diesbezüglich sicher.
Ja ich weiß, aber dann wäre das automatisiert nicht möglich, denn rpi-clone ändert ja jedes mal die PARTUUIDs und die müsste man dann auch immer manuell neu mitgeben. 
Oder kann man irgendwie per fstab EIntrag definieren dass eine PARTUUID ein bestimmtes /dev/sdx wird?
Nicht dass ich wüsste. Wobei die fstab bei den Ziellaufwerken keine Rolle spielt, denn rpi-clone mountet ja manuell. 
//Edit
Franjo G Ja, das kommt auch noch dazu.
Stimmt. Das habe ich vergessen: rpi-clone müsste noch eine weitere Option bekommen mit der man die Änderung der UUIDs disabled. Könnte man sicherlich einbauen.
eine weitere Option bekommen mit der man die Änderung der UUIDs disabled
Das würde mir nicht gefallen, denn dann kann es wieder Konflikte beim Test des Backups geben. Die NVMe kann ich ja nicht mal eben schnell ausbauen. Das passt schon alles so wie es ist.
Ich versuche immer bei Problemen eine Lösung zu finden - so bin ich nun mal 
Es gibt auch diesbezüglich keinen Feature Request auf github - also wird es auch wie bei Dir einfach nicht gebraucht.
Das ist hier zwar irgendwie etwas OT, aber falls hier wieder jemand aufschlägt und schreibt irgendwas von "ein Backup auf eine SD-Karte ist doof", dem kann ich nur antworten, dass ich eine baugleiche microSD-Karte seit Dezember 2022 in meiner Dashcam verwende und die auch heute noch gut funktioniert. Für alle die es nicht wissen sollten, eine Dashcam schreibt die Karte komplett voll und überschreibt dann immer wieder die älteste Datei.
Die paar MB, die bei meinem Backup alle zwei Wochen mit rsync geschrieben werden sind im Vergleich zur Dashcam ein Witz.
Und weitere Gründe sind u.a., dass damit ja auf komplette Laufwerke geschrieben und im schlimmsten Fall könnte das auch ein falsches sein. Ich habe hier öfter HDDs mit Videodateien angeschlossen und dann wäre das fatal, wenn die versehentlich überschrieben werden würde. Deshalb sehe ich vorher zur Sicherheit mit lsblk nach.
Eine Möglichkeit gäbe es m.M.n
Ein kleines Skript, welches prüft, ob sda1 oder sdb1... existiert und eine Größe von 512M hat und dann rpi-clone mit der entsprechenden Laufwerksangabe startet.
Sicherlich erfüllen die Video-HDD's diese Voraussetzung nicht.
//EDIT
Wobei das bei einem wöchentlichen Wechsel der SD auch nichts bringen würde.
Gute Idee. Noch sicherer ist es sicherlich einfach eine Datei /boot/thisIsMyBackupSSD zu erzeugen und darauf zu prüfen.
Gute Idee. Noch sicherer ist es sicherlich einfach eine Datei /boot/thisIsMyBackupSSD zu erzeugen und darauf zu prüfen.
Aber wie gesagt, das bringt alles nichts, wenn die Sd nicht dauerhaft im Pi steckt, was aufgrund der Bootreihenfolge und der Tatsache dass diese wöchentlich gewechselt wird nicht möglich ist. So müsste ja, wenn ein automatisches Backup ansteht, vorher die SD gesteckt werden und dann wäre es nicht mehr automatisch.
Eine Lösung wäre beide SD Karten anzuschliessen und ein Script mounted immer wechselweise die SD Karten vor den rpi-clone Backup.
Ist aber für hyle, wie er schon schrieb, keine Lösung da (s.o.). Aber ich denke es reicht jetzt mit dem OT - auch wenn es eine interessante Diskussion ist 
Vielleicht mal ein Thema im Stammtisch 
Diese ganze Diskussion ist im Grunde genommen eh obsolet, solange es keine Option dafür gibt, die Abfrage
Ok to proceed with the clone? (yes/no):automatisch zu übergehen.
Vielleicht habe ich die aber auch nur übersehen. Das Verwenden einer solchen Option wäre allerdings aus den genannten Gründen ziemlich riskant.
Ein echo yes | rpi-clode … ginge nicht?
Könnte ich mal testen, aber heute nicht mehr.
Ein echo yes | rpi-clode … ginge nicht?
Das geht.
~ $ echo yes | sudo rpi-clone sdb
rpi-clone Version: 2.0.27
Booted disk: nvme0n1 512.1GB Destination disk: sdb 120.0GB
---------------------------------------------------------------------------
Part Size FS Label Part Size FS Label
1 /boot/firmware 512.0M fat32 bootfs 1 512.0M fat32 bootfs
2 root 476.4G ext4 -- 2 111.3G ext4 --
---------------------------------------------------------------------------
== SYNC nvme0n1 file systems to sdb ==
/boot/firmware (77.5M used) : SYNC to sdb1 (512.0M size)
/ (11.9G used) : SYNC to sdb2 (111.3G size)
---------------------------------------------------------------------------
Run setup script : no.
Verbose mode : no.
-----------------------:
Ok to proceed with the clone? (yes/no):
Syncing file systems (can take a long time)
Syncing mounted partitions:
Mounting /dev/sdb2 on /mnt/clone
=> rsync // /mnt/clone with-root-excludes ...
Mounted /dev/nvme0n1p1 on /boot/firmware already
Mounting /dev/sdb1 on /mnt/clone/boot/firmware
=> rsync /boot/firmware/ /mnt/clone/boot/firmware ...
Editing /mnt/clone/boot/firmware/cmdline.txt PARTUUID to use d77b366b
Editing /mnt/clone/etc/fstab PARTUUID to use d77b366b
===============================
Done with clone to /dev/sdb
Start - 23:05:14 End - 23:05:33 Elapsed Time - 0:19
Cloned partitions are mounted on /mnt/clone for inspection or customizing.
Hit Enter when ready to unmount the /dev/sdb partitions ... unmounting /mnt/clone/boot/firmware
unmounting /mnt/clone
===============================Don’t have an account yet? Register yourself now and be a part of our community!