Wie kann ein Backup einer SD-Karte (von einem Raspberry Pi) in eine Datei auf einem Mac OS X gesichert werden?

Die SD-Karte vom Raspberry Pi oder auch jede andere, in den Mac stecken und mit der Eingabe im Terminal:

diskutil list

feststellen wie die SD-Karte gemountet wurde. Bei mir /dev/disk3

Bildschirmfoto 2013-11-09 um 18.35.01

Und den Backup-Prozess starten mit dd (data definition):

sudo dd if=/dev/rdisk3 of=~/Backups/Raspbeery-Pi/ini-rot-backup.img bs=1m
if = input file
of = output file
~ = Homeverzeichnis
Das Prefix „r“ vor dem rdisk3 soll den Prozess beschleunigen, da es auf den raw Speicher der Karte zugreift.
bs = block size hier 1 MB

Bis die 8 GB als backup gespeichert sind, dauert je nach SD-Karten Größe ein paar Minuten, bei mir ca. 7 Minuten:

Bildschirmfoto 2013-11-09 um 18.39.47

Dann kann die SD-Karte entfernt werden und das Backup bei Bedarf eingespielt werden.

Das Einspielen des Backup (Restore) dauert bei einer 8GB Karte über eine Stunde.
Dazu die SD-Karte in den Mac stecken und

diskutil list # schauen wo die SD-Karte gemountet ist
sudo diskutil unmount /dev/disk3s1 # SD-Karte unmounten
sudo dd if=ini-rot-backup.img of=/dev/disk3 bs=1m # Image ini-rot-backup.img auf SD-Karte kopieren

eingeben. Wenn die Ausgabe:

7680+0 records in
7680+0 records out
8053063680 bytes transferred in 10605.150176 secs (759354 bytes/sec)
kommt, dann ist der Kopiervorgang abgeschlossen.

Die Anzeige des Fortschritt des Kopiervorgangs wird in diesem Eintrag beschrieben.

4 Antworten auf „Wie kann ein Backup einer SD-Karte (von einem Raspberry Pi) in eine Datei auf einem Mac OS X gesichert werden?“

  1. Ja das geht so auf dem MAC BOOK AIR mit OSX 10.7 , guter Artikel. Auch bei mir dauert eine 4GB Karte zu lesen fast 40minuten. Ich habe allerdings festgestellt dass es auf einen DELL Inspiron 850 Windows 7 PC mit WIN32DiskImager ganz 6 Minuten dauert die gleiche Karte zu lesen und nur rund 12 Minuten um die Karte zu schreiben. Krass, denn der DELL ist 4 Jahre alt und das MAC BOOK AIR gerade mal 4 Monate

  2. Kurzer Tipp: Beim Zurueckspielen statt /dev/disk3 einfach /dev/rdisk3 nehmen – so werden dann auch vernuenftige Zeiten realisiert:

    4008706048 bytes transferred in 270.867007 secs (14799536 bytes/sec)

    1. One of the key differences between /dev/disk and /dev/rdisk, when you access them from user space, is that /dev/disk is buffered. The read/write path for /dev/disk breaks up the I/O into 4KB chunks, which it reads into the buffer cache, and then copies into the user space buffer (and then issues the next 4KB read…). This is nice in that you can do unaligned reads and writes, and it just works. In contrast, /dev/rdisk basically just passes the read or write straight to the device, which means the start and end of the I/O need to be aligned on sector boundaries.

      If you do a read or write larger than one sector to /dev/rdisk, that request will be passed straight through. The lower layers may break it up (eg., USB breaks it up into 128KB pieces due to the maximum payload size in the USB protocol), but you generally can get bigger and more efficient I/Os. When streaming, like via dd, 128KB to 1MB are pretty good sizes to get near-optimal performance on current non-RAID hardware.

      The caching being done by /dev/disk’s read and write paths is very simple and almost brain dead. It caches even if not strictly necessary; like if the device could memory map and directly transfer into your app’s buffer. It does small (4KB) I/Os, which leads to a lot of per-I/O overhead. It does not do any read ahead or write behind.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.