SD Karte bis aufs bit clonen?

wenn Du die SD-Karte auf dem Notebook mit Win32DiskImager mit Button Lesen oder Read in eine Image-Datei liest, dann hast Du eine 1:1-Kopie, die auch genauso groß, wie die SD-Karte ist.

Schönen Gruß, kle

Ich mache das mit dem System Raspbian im Untermenü " Zubehör - SD Karte Copier"

Das klappt auch mit verschieden großen Karten. Wenn z.B eine 32-er nicht voll genutzt ist und z.B. nur 10GB belegt sind, kann diese auch auf eine 16-er kopiert werden.

ich wollte zum Ausdruck bringen, dass kein Umweg über ein Windowsprogramm nötig ist, sondern dass diese 1:1-Kopie im Betriebssystem Raspbian integriert ist.

Quote from birkner

ich wollte zum Ausdruck bringen, dass kein Umweg über ein Windowsprogramm nötig ist, sondern dass diese 1:1-Kopie im Betriebssystem Raspbian integriert ist.

again what learned!

Auch wenn ich bloß nachgesehen und das Programm nicht getestet habe: Wenn dieses Programm in Raspbian integriert ist und unter "Zubehör" zu finden ist, gehe ich davon aus, dass es auch problemlos funktioniert. Wird ja (hoffentlich) kein zweites NOOBS sein

Man muss am RPi jedenfalls noch ein USB-Laufwerk anschließen, auf dem das Image(?) abgelegt wird.

Die Beschreibung von SD Card Copier bekommt man mit einem Klick auf den Hilfe Knopf. Zwei Laufwerke sind schon nötig. Ob man auf die interne SD Karte kopieren kann, wenn man von USB gebootet hat, weiss ich nicht.

Es gibt ein shell Script zu dem UI. Sehr einfach gestrickt aber es erlaubt im Gegensatz zu dd auch das Clonen auf eine größere oder kleinere SD Karte. Quelle kann jedes Device sein. Dort findet sich auch die Source der UI Version in C programmiert.

Bei SD Card Copier sind nicht unbedingt zwei Laufwerke erforderlich. Das bestehende System auf der laufenden SDKarte wird direkt während des Betriebs aud eine zweite 1:1 abgebildet.

Das funktioniert zuverlässig und relativ schnell.

Quote from birkner

Das funktioniert zuverlässig und relativ schnell.

Ein rw gemountetes root-Filesystem kann nicht zuverlässig byteweise kopiert werden, da sich der Inhalt der Metadaten laufend ändert. Das funktioniert eher zufällig, solange das Filesystem nicht vor dem Kopiervorgeng schon korrupt war, und die Inode-Differenzen beim ersten fsck (im nächsten Boorvorgang) aus dem Journal automatisch fehlerfrei aufgelöst werden klnnen.

Servus !

Also wenn ich als Quelle die interne SD Karte wähle, ist es hier nicht möglich die interne SD Karte als Ziel zu wählen. Wo ist denn dein Ziel, wenn du die SD Karte als Quelle gewählt hast? Das muss doch zwangsläufig ein zweites Laufwerk sein.

Quote from daxb

Also wenn ich als Quelle die interne SD Karte wähle, ist es hier nicht möglich die interne SD Karte als Ziel zu wählen.

Der folgende Kommentar wie auch die dazugehoerige Implementierung findet sich im Code:

// do not allow the current root and boot devices as targets

Interne SD-Karte als Quelle. Die zweite SD-Karte, auf die das System kopiert werden soll, wird in ein Kartenlesegerät gesteckt und über USB mit dem Raspberry verbunden. Eine interne Kopie auf sich selbst kann nicht funktionieren.

Zur Zuverlässigkeit: Ich hab das schon viele Male ohne Probleme gemacht.

Die rootfs-Partition, die boot-Partition und sogar eine vorhandene weitere Daten-Partition werden problemlos kopiert.

Für mich die beste und einfachste Sache für ein gut eingerichtestes System eine Sicherheitskopie zu erstellen.

Quote from birkner

Bei SD Card Copier sind nicht unbedingt zwei Laufwerke erforderlich.

Diese Aussage von dir hatte mich irritiert, weil zwei Laufwerke mehr oder weniger zwingend erforderlich sind. Du nutzt ja auch zwei Laufwerke.

Quote from RTFM

Ein rw gemountetes root-Filesystem kann nicht zuverlässig byteweise kopiert werden, da sich der Inhalt der Metadaten laufend ändert.

Da du dich mit Mount so gut auskennst, kannst du folgendes vielleicht bestätigen, oder nicht.

Die Lösung ist oder wäre das Filesystem ro zu mounten. Nehme ich an. Ich beziehe mich auf den unten stehenden man mount Auszug. Die erste Frage wäre also, ob das so richtig ist, Filesystem ro mounten während das System läuft und dann eine Sicherung von diesem ro gemountetem Filesystem machen?

Im man mount Auszug werden zwei Möglichkeiten aufgezeigt ein Fileystem ro zu mounten. Das erste Beispiel ist nicht im Linux Kernen implementiert, sondern im Userspace. Das zweite Beispiel läuft dann im Linux Kernen, nehme ich an? Der Nebensatz im ersten Beispiel "This solution is not atomic." irritiert mich. Was ist damit genau gemeint?

Im Moment weiss ich nicht, welches der zwei Wege ich nehmen müsste. Bzw. welches für welchen Zweck einsetzen.

mount(8) since v2.27 allows to change the mount options by passing  the  relevant  options
       along with --bind.  For example:

              mount --bind,ro foo foo

       This  feature  is  not supported by the Linux kernel; it is implemented in userspace by an
       additional mount(2) remounting system call.  This solution is not atomic.

       The alternative (classic) way to create a read-only bind mount is to use the remount oper‐
       ation, for example:

              mount --bind olddir newdir
              mount -o remount,bind,ro olddir newdir

       Note  that a read-only bind will create a read-only mountpoint (VFS entry), but the origi‐
       nal filesystem superblock will  still  be  writable,  meaning  that  the  olddir  will  be
       writable, but the newdir will be read-only.

       It's  also  possible to change nosuid, nodev, noexec, noatime, nodiratime and relatime VFS
       entry flags by "remount,bind" operation. It's impossible to change  mount  options  recur‐
       sively (for example with -o rbind,ro).

Du kannst während des Abziehens des Disk- oder Partitions Images die root Partition ro mounten mit remount,ro, und danach wieder mit remount,rw zurücksetzen.

Servus !

Würde es nicht besser sein das Raspbian auf einem btrfs Filesystem laufen zu lassen, ein Snapshot zu generieren und dann den Snapshot asynchron auf ein Backupmedium zu sichern bzw auf eine andere SD Karte zu clonen? Hier ist der Ansatz beschrieben.

Ich habe kurz piclone (SD Card copier) überflogen und dort sind ein paar mount/unmount im Source. Piclone scheint also doch etwas mehr zu machen.

Die Frage ist eher, wozu brauche ich ein FS-Snapshot, wenn mir ausreichend Sicherungswerkzeuge zur Verfügung stehen. dd, und damit das Imageclonen ist ja mehr eine Erfindung der Raspberrypi Foundation, um eine Start MMC zu erstellen, damit der Pi zum Laufen kommt.

Kein seriöser Admin käme auf die Idee einen Plattenstapel Byte für Byte, Sektor für Sektor mit allen nicht verwendeten Blöcken auf eine Sicherunskopie zu übertragen, nur weil es so auch funktioniert. Beim Pi hat sich das aber zum Selbstläufer entwickelt, mit allen Frontend-Scripts von expand bis shrink.

Solange tar und rsync in jeder Standardinstallation enthalten sind ist das sicher die bessere Wahl. dd fährt übrgens "blind" über das Lese- und Schreibdevice, es werden nicht einmal Prüfsummen gezogen, wie auch Badblocks itgendwie gelesen und auf das neue Image übertragen werden.

Servus !