Linux: Image/Abbild (Backup) von SD erstellen und verkleinern

  • Problematik / Technische Grundlage:


    Ein vollständiges Abbild (clone) einer SD zu erstellen ist der einfachste und schnellste Weg ein Backup bzw eine Sicherung seines Systems zu erzeugen.
    Problem dabei ist allerdings das über dd oder Win32DiskImager usw man ein vollständiges 1:1 Abbild erstellt, es werden also auch leere Sektoren gesichert - ist die SD 16GB ist auch das Image 16GB.


    Wenn die Quell-SD zB 16300 MB groß ist aber die Ziel-SD nur 16200 dann passt das Image nicht auf eine andere 16GB SD Karte oder sogar auf eine kleinere, obwohl nur zB 4GB Speicher tatsächlich belegt sind...
    Es gibt fast immer minimale Unterschiede, auch wenn auf der SD Karte die selbe Größe (zB 16GB) aufgedruckt ist. Manche Hersteller rechnen mit den korrekten 1024, andere wiederum aber nur mit 1000 -> 16 x 1024 ergibt 16384 aber 16 x 1000 ergibt eben nur 16000 (MB). Aber auch der Herstellungsprozess kann minimale Unterschiede hervorrufen.



    Verschiedene Backupmethoden stehen zur Verfügung:

    1) dd Backup der ganzen SD Karte
    2) tar Backup eines beliebigen Verzeichnisses, wobei bei / als Verzeichnis die gesamte Pi gesichert wird
    3) xbmc Backup, welches das xbmc Konfigurationsverzeichnis in einem tar sichert
    4) rsync Backup, wobei Hardlinks benutzt werden um die Datenmenge in den Backupversionen zu reduzieren.


    dd: Vollbackup: ja , Backupzeit: lange , Backupgröße: gross , Datenkompression: nein , CPU belastet: mittel , Karte belastet: hoch , Selektiver Restore möglich: nein , Dateisystem: alles
    tar: Vollbackup: nein , Backupzeit: mittel , Backupgröße: mittel , Datenkompression: ja , CPU belastet: mittel , Karte belastet: mittel , Selektiver Restore möglich: ja , Dateisystem: alles
    xbmc: Vollbackup: nein , Backupzeit: kurz , Backupgröße: klein , Datenkompression: ja , CPU belastet: nein , Karte belastet: kaum , Selektiver Restore möglich: ja , Dateisystem: alles
    rsync: Vollbackup: nein , Backupzeit: kurz , Backupgröße: mittel , Datenkompression: nein , CPU belastet: nein , Karte belastet: kaum , Selektiver Restore möglich: ja , Dateisystem: ext2/ext3
    (Quelle der Tabelle)


    Ich möchte euch hier beschreiben wie die Profis (ich bin aber keiner :lol:) dies handhaben - ihr habt das vielleicht schon mal gesehen das ein Raspbian Image o.ä. nur 200MB groß ist aber nachdem ihr es auf die SD geflasht habt ist die Partition 2GB ... Die Profis löschen/entfernen die leeren Sektoren um das Image nur auf die Größe des belegten Speicherplatzes zu reduzieren - bzw der freie Speicher wird mit 0'n beschrieben, erstellen anschließend das Image und lässt sich dadurch kleiner packen (oder mounten ein Image und 0'n den leeren Speicher)



    [hr]



    Zum erstellen eines Images ist der einfachste Weg einen größeren USB-Stick oder eine USB-Festplatte an den PI anzuschließen und darauf das Image zu schreiben. Ihr solltet aber darauf achten dass das Laufwerk nicht allzu langsam ist, sonst dauert es ziemlich lange (billige USB-Sticks haben nur eine Schreibgeschwindkeit von umdie 2MB/s, ist die SD 16GB groß kann es bis zu 2 Stunden dauern..)
    Achtet auch darauf das FAT32 nur eine maximale Dateigröße von 4 GB unterstützt. Ihr solltet also entweder ein Linux Dateisystem oder NTFS verwenden.


    Ich hab hierfür eine SSD verwendet da damit der maximale USB-Datendurchsatz des PIs ausgenutzt werden kann: ca. 30MB/s
    (ich nutze also den PI um von ihm direkt ein Image zu erstellen)



    Eine weitere Möglichkeit besteht aber auch darin die SD an ein anderes Linux System anzuschließen bzw zu mounten - das kann auch ein Virtuelles über zB VirtualBox oder eine andere VM sein.




    Wenn ihr das Backup Live vom/über den RaspberryPI erstellen wollt ist es wichtig vorher das System als read-only zu mounten! Denn es kann zu Probleme kommen wenn gerade auf die Partition geschrieben wird wärend ihr ein Image davon erzeugt - in solch einem Fall sichert ihr nur Datenschrott
    Dies erreicht ihr über /etc/fstab . Mehr Details dazu weiter unten!

    Oder man beendet vorher alle Dienste und Programme, also zB: service apache2 stop ; service mysql stop ;service cron stop und natürlich auch eure selber erstellen Scripts oder gar RaspBMC usw!



    [hr]



    Falls euer Sicherungslaufwerk (wohin das Image geschrieben wird) mit NTFS formatiert ist müsst ihr auch noch folgendes beachten:


    Benötigtes Paket installieren:

    Code
    apt-get update
    apt-get install ntfs-3g


    Wenn ihr das Sicherungslaufwerk über Linux formatieren wollt könnt ihr nun folgenden Befehl nutzen:

    Code
    mkfs.ntfs -f /dev/sda1


    (quick format)



    Durch NTFS wird aber die Schreibgeschwindigkeit unter Linux stark reduziert! Besser wäre den Datenträger mit ext3 oder ext4 zu formatieren:

    Code
    mkfs.ext4 /dev/sda1



    [hr]



    Anleitung:


    Ihr geht dabei wie folgt vor:
    (alle Befehle erfordern root Rechte, also ggf sudo davor schreiben!)



    Zunächst müssen wir erst das RaspberryPI System als read-only mounten damit nicht wärend des sicherns auf die Partitionen geschrieben wird (zB von Diensten wie CRON o.ä.) und unsere Sicherung dadurch nutzlos werden würde (siehe dicker roter Hinweis weiter oben).
    Dazu müsst ihr /etc/fstab bearbeiten und "ro" zu den beiden Partitionen hinzufügen, sodass es ungefähr wie folgt aussieht:

    Code
    proc            /proc           proc    defaults          0       0
    /dev/mmcblk0p1  /boot           vfat    defaults,ro          0       2
    /dev/mmcblk0p2  /               ext4    defaults,noatime,ro  0       1


    Diese Änderung müsst ihr nach dem erstellen es Abbilds wieder rückgängig machen - und zwar müsst ihr dazu folgenden Befehl ausführen bevor ihr logischerweise /etc/fstab verändern bzw speichern könnt:


    Und dann rebooten damit die Partitionen der SD beim nächsten Systemstart nur als read-only gemounted wird:

    Code
    reboot


    Nach dem reboot könnt ihr das ganze prüfen indem ihr über den Befehl mount kontrolliert ob " (ro " hinter der " / " und " /boot " Partition steht - oder ihr versucht jeweils in " / " und " /boot/ " eine Datei zu erzeuchen was aber nicht funktionieren dürfte :) -> touch /test ; touch /boot/test



    Herausfinden ob das SicherungsLaufwerk erkannt wurde:

    Code
    dmesg | grep sd

    (die erste Partition ist meistens sda1 oder sdc1)


    Verzeichnis erstellen wohin wir das Laufwerk mounten und die erste Partition mounten/einbinden:

    Code
    mkdir -p /mnt/sda1
    
    
    mount /dev/sda1 /mnt/sda1/

    (Pfade ggf anpassen)



    [hr]



    Der reguläre Weg ein vollständiges 1:1 Abbild der SD zu erstellen sähe normalerweise wie folgt aus:

    Code
    dd if=/dev/mmcblk0 of=/mnt/sda1/rpi.img bs=1M


    (if -> input file , of -> output file)


    Das erzeugt aber besagtes 1:1 Abbild, also in meinem Fall wäre das rpi.img dann ca. 8GB groß.
    Funktioniert so natürlich auch, ist aber wie ich finde unschön, vorallem wenn man die Datei ggf auch zum Download bereitstellen möchte :stumm:


    Nun gibt es ein paar Tricks.


    Der erste Trick besteht darin beim erstellen des Abbilds die Ausgabe an gzip zu leiten (pipe (|)) um das Abbild komprimieren zu lassen. Mit folgendem Befehl spart man sich einen Zwischenschritt - man kann das komprimieren aber auch nach dem erstellen durchführen.

    Code
    dd if=/dev/mmcblk0 | gzip > /mnt/sda1/rpi.img.gz


    Das spart schon mal einiges an Platz denn ungepackt wäre das Image ~7,6GB gross:

    Code
    root@raspberrypi:~# du -sh /mnt/sda1/rpi.img.gz                                   
    990M    /mnt/sda1/rpi.img.gz
    root@raspberrypi:~#


    Zur Wiederherstellung sähe der Befehl so aus:

    Code
    gzip -dc /mnt/sda1/rpi.img.gz | dd of=/dev/mmcblk0



    Jenachdem wie groß eure SD Karte ist kann das erstellen ziemlich lange dauern - in meinem Fall hat es mit NTFS 45 Minuten gedauert:

    Code
    root@raspberrypi:~# dd if=/dev/mmcblk0 of=/mnt/sda1/rpi.img bs=1M
    7695+0 Datensätze ein
    7695+0 Datensätze aus
    8068792320 Bytes (8,1 GB) kopiert, 2712,63 s, 3,0 MB/s
    root@raspberrypi:~#


    Mit ext4 war es dahingegen mit nur ca 10 Minuten merklich schneller:

    Code
    root@raspberrypi:~# date ; dd if=/dev/mmcblk0 of=/mnt/sda1/rpi.img bs=1M ; date
    Do 3. Jul 18:44:59 CEST 2014
    7695+0 Datensätze ein
    7695+0 Datensätze aus
    8068792320 Bytes (8,1 GB) kopiert, 711,419 s, 11,3 MB/s
    Do 3. Jul 18:56:51 CEST 2014
    root@raspberrypi:~#

    Problematisch hierbei ist allerdings das Windows nicht von alleine auf Linux-Dateisysteme zugreifen kann. Dafür müßte man einen extra Treiber installieren zum Beispiel > diesen <.


    Die Größe des Abbilds können wir nun mit folgendem Befehl kontrollieren:

    Code
    root@raspberrypi:~# du -sh /mnt/sda1/rpi.img
    7,6G    /mnt/sda1/rpi.img
    root@raspberrypi:~#



    Bevor ihr das Sicherungslaufwerk umount'et (vor dem abziehen wieder aushängen) solltet ihr aber unbedingt den Befehl sync ausführen damit der Buffer geleert und alle Daten geschrieben werden. Anschließend müsst ihr auch vor dem Abziehen das Laufwerk wie gesagt umount'en:

    Code
    umount /mnt/sda1



    [hr]



    Nun aber zum Hauptmerkmal dieser Anleitung:


    Hier gibt es nun mehrere Möglichkeiten:

    • Das erzeugte Image mounten, den freien Speicher mit nullen voll schreiben indem man eine Datei erzeugt und diese Datei anschließend wieder löschen. Wenn man das Image dann mit zip o.ä. packt wird es wesentlich kleiner als wenn man diesen Schritt nicht machen würde.
      Hierbei muss man darauf achten dass das erstellte Abbild mehrere Partitionen beinhaltet, man also jede Partition einzeln mounten muss! Wie das detailliert geht hab ich bereits letztes Jahr in einer anderen Anleitung beschrieben. Bitte lest euch dort ein wie das genau geht. Wenn ihr Raspbian verwendet sollten die offset Werte aber bei allen gleich sein.

      Code
      mkdir -p {/mnt/rpi1,/mnt/rpi2}
      
      
      mount /mnt/sda1/rpi.img /mnt/rpi1 -o offset=$((8192*512))
      mount /mnt/sda1/rpi.img /mnt/rpi2 -o offset=$((122880*512))


      Damit haben wir jetzt vom Image die /boot/ Partition nach /mnt/rpi1/ und die root-Partition nach /mnt/rpi2/ gemountet.
      Jetzt schreiben wir in beide Partitionen eine Datei mit nullen und anschließend löschen wir diese wieder. Danach können wir die mounts wieder entfernen:

      Code
      cat /dev/zero > /mnt/rpi1/big_zero ; sync; rm /mnt/rpi1/big_zero
      cat /dev/zero > /mnt/rpi2/big_zero ; sync; rm /mnt/rpi2/big_zero
      
      
      umount /mnt/rpi*


      Das da jeweils eine Fehlermeldung von wegen "kein Speicherplatz mehr verfügbar" kommt ist normal und Absicht :)
      Die Image Größe hat sich nun noch nicht verändert - wenn man die Datei aber nun pakt wird sie kleiner als es vorher möglich war.


    • Es gibt eine ganze Reihe Programme die sowas ähnliches wie die 1.Möglichkeit beschreibt, machen. Dazu gehört zum Beispiel fsarchiver , btrfs , zerofree , sfill , e2image oder partimage. Letzteres unterstützt leider kein ext4 und man kann ext4 leider nicht so einfach in ext3 umwandeln bzw ist das nicht zu empfehlen..


    • Es gibt auch einen manuellen Weg die zweite Partition (root-Partition) zu shrink'en. Dieser Weg ist etwas aufwendiger und auch etwas gefährlich sofern man etwas falsch macht - erreicht aber dass das *.img auch ohne es zu packen kleiner wird :)


      Wie bei der 1.Methode benötigen wir die offset Werte, allerdings mounten wir die 2.Partition nicht sondern erzeugen dafür nur ein extra Device auf das wir dann zugreifen können:

      Code
      losetup -f --show -o $((122880*512)) /mnt/sda1/rpi.img

      Dieser Befehl sollte euch dann dev/loop0 o.ä. ausgegeben haben, das ist das neue Devive welches wir in den nächsten Schritten ansprechen.
      Nun überprüfen wir das Device erst mal auf Fehler:

      Code
      e2fsck -p -f /dev/loop0

      Das sollte fehlerfrei verlaufen, ansonsten habt ihr ein Problem...
      Nun müssen wir erst mal herausfinden wieviel Speicherplatz auf dem Device belegt ist, damit wir wissen auf welche Größe wir die Partition shrink'en können. Dazu mounten wir das Device temporär nach /mnt/rpi1, prüfen den Benutzten Platz und umounten es für die späteren Schritte wieder:

      Code
      mkdir -p /mnt/rpi2
      mount /dev/loop0 /mnt/rpi2
      df -h
      umount /mnt/rpi2


      Die Ausgabe von df -h sieht bei mir folgendermassen aus:

      Code
      Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
      /dev/loop0      7,3G    2,3G  4,8G   32% /mnt/rpi2

      (hab die Ausgabe aufs nötigste gekürzt)
      Das zeigt also das ca. 2,3GB belegt sind (ich hab da schon einiges installiert, deshalb ist bei mir mehr belegt als es bei euch sein könnte). Es kann also nicht schaden das Device (bzw die Partition) auf 3GB zu verkleinern - und genau das machen wir jetzt:

      Code
      resize2fs -p /dev/loop0 3G


      Anschließend können wir durch mounten des Devices noch mal kontrollieren ob die Größe nun weniger ist als zuvor (es würden nun 2,9G anzeigen werden), danach ist aber wichtig das angelegte Device für die nächsten Schritte wieder zu löschen (Daten bleiben erhalten, wir entfernen nur das selbst erzeugte loop device):

      Code
      losetup -d /dev/loop0


      Das von uns modifizierte Image ist jetzt aber leider noch nicht kleiner als vorher. Darum kümmern wir uns nun - und jetzt wird es leider auch etwas komplizierter...


      In den folgenden Schritten müssen wir nun ein blanko Image mit den selben Spezifikation erzeugen wie das normale Image, Partitionen erzeugen und die Daten kopieren.
      Erstmal fragen wir die Spezifikationen unseres Images ab:

      Code
      fdisk -l /mnt/sda1/rpi.img

      Die Ausgabe sieht bei mir so aus:


      Für uns sind die ersten 3 Zeilen wichtig: 255 heads, 63 sectors -> 255 x 63 = 16065 x 512bytes = 8225280 bytes pro cylinder.
      Wir erstellen ein Image mit 4MB am Anfang (für den MBR) + 56MB (FAT32 Partition, für /boot/) + 3GB System Partition (3072MB) ; ergibt also eine Gesamtgröße von 3.132 MBytes oder 3.284.140.032 Bytes (1 kB = 1024 Bytes). Letztere Zahl teilen wir durch 'bytes pro cylinder' und erhalten den cylinder Wert zum erstellen des blanko Images: 3284140032 / 8225280 = 399,27 cylinders. Nachkomma Stellen sind blöd also runden wir auf 400 auf!
      Blanko-Image erzeugen:

      Code
      root@raspberrypi:~# dd if=/dev/zero of=/mnt/sda1/3GB.img bs=8225280c count=400
      400+0 Datensätze ein
      400+0 Datensätze aus
      3290112000 Bytes (3,3 GB) kopiert, 124,484 s, 26,4 MB/s
      root@raspberrypi:~#


      Jetzt benutzen wir fdisk um direkt die korrekte Struktur im Image zu erzeugen und legen darüber auch gleich die Partitionen an:

      Code
      fdisk -u -C400 -S63 -H255 /mnt/sda1/3GB.img


      Wir legen die ersten Partition (/boot) an und ändern den Type auf W95 FAT32 (LBA):


      Jetzt legen wir in der selben fdisk-Session die zweite (System)Partition an und ändern den Type auf Linux:


      Nun das gemachte kontrollieren:


      Anschließend müssen wir die gemachten Änderungen schreiben/speichern und fdisk beenden:


      Soweit so gut... Jetzt 'kopieren' wir die erste Partition von unserem Backup-Image zum Blanko-Image, überspringen (skip) aber die ersten 4MB (8192 sectors of 512 bytes) und suchen (seek) weitere 4MB (8192 sectors of 512 bytes) um 56MB zu kopieren (114688 sectors of 512 bytes):

      Code
      dd if=/mnt/sda1/rpi.img of=/mnt/sda1/3GB.img bs=512 count=114688 skip=8192 seek=8192


      Das gleiche Spiel machen wir jetzt auch für die 2.Partition: wir überspringen 4 MBytes + 56 MBytes (122880 sectors of 512 bytes, 60 MBytes) vom input file und seeking 4 MBytes + 56 MBytes (122880 sectors of 512 bytes, 60 MBytes) im output file um 3072 MBytes (6291456 sectors of 512 bytes) zu kopieren..:

      Code
      dd if=/mnt/sda1/rpi.img of=/mnt/sda1/3GB.img bs=512 count=6291456 skip=122880 seek=122880


      ...fertig... :D
      Das neu erstellte Image ist jetzt 3GB groß und beinhaltet alle Daten vom Backup-Image.
      (quelle)

      Code







    [hr]


    Weitere Hinweise:


    Ein Nachteil von dd ist die Geschwindigkeit, weil es wirklich über den kompletten Speicher geht. Sobald ich mal wieder etwas Zeit hab werd ich (oder andere?) das Tutorial um weitere Linux-Sicherungsprogramme erweitern ;)


    Weitere, ähnliche Tutorials in diesem Forum sind folgende:
    Backup einer SD-Karte
    Automatisches Erstellen eines Backups (Pi sichert sich selbst)
    Backup des laufenden Systems anlegen

  • für ne einmal Aktion recht umständlich ...


    deine Anleitung werde ich als Grundlage fürn RPI backupscript nehmen :thumbs1:


    ich nutze eine virtuelle Maschine ( Virtualbox ) um das image zu verkleinern.


    - Virtuelle Platte anlegen ( etwas größer als die gesamte Belegung von der MMC/MicroSD karte )
    - HOST fs mit sshfs mounten ( Verzeichnis durch reichen geht nur mit den Gast vbox modulen, war mir zu umständlich fürn minimalsystem :fies: )
    - mit sudo dd if=/sshfs/host/MMCcard.img of=/dev/sdb
    - mit cfdisk noch ggf den partitiontyp anpassen
    - mit sudo dd if=/dev/sdb of=/sshfs/host/MMCcardSMALL.img kleines image wieder auf den Host kopieren
    - fertig ;)

    Edited once, last by speefak ().

  • Ehm naja, dir fällt aber schon auf das in meinem Tutorial ein USB-Gerät zur Sicherung genutzt wird? Es ist relativ egal ob man ein extra Device oder einen Mount verwendet wohin das Image geschrieben wird - also egal ob USB-Gerät oder ein externes Virtuelles Laufwerk or whatever..
    Wichtig ist in jedemfall der von mir eingangs Dick und Rot markierte Teil: keine Live-Sicherung sofern das System noch schreiben kann (zB in Logfiles)


    Mit kurzen Stichpunkten kommt meine Anleitung auch auf die Länge deiner heraus - denn leider beschreibst du keine Details was man in cfdisk machen muss...

  • ...ich nutze eine virtuelle Maschine ( Virtualbox ) um das image zu verkleinern...

    Ist sicherlich auch ein Weg nach Rom. Aber für die meisten der Besucher hier im Forum ein ziemlicher Umweg über China :shy:

    "Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." Linus Benedict Torvalds, 28.9.2003


    Hast Du die Woche schon Deine Raspberry gesichert :shy: Bei mir tut das automatisch raspiBackup ;)

  • der umweg kommt immer auf den standounkt an ;) ich arbeite schon seit jahren mit VMs und images, sei es zum testen, config änderungen etc. darum wars für mich mit dem umweg über die VM einfacher, allerdings gabs beim o.g. klonen der gesamten HD auf eine kleine Probleme und ich musste die FAT 16 und die et4 partition nochmal einzeln auf die kleine HD klonen.


    PS : für ausführliche Anleitungen fehlt mir im mom die zeit daher stichpunkte, das ganze kommt nacher ins script. Der versierte user schaut sich das script an wenn er mehr wissen möchte und wie und was das script macht, der DAU führt es aus. kein Nerv die kleinsten Sachen 1000000 mal zu erklären, da gibs schon genug infos zu :

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.
    :bravo2:


    PSS : die VM geschichte hat einen Vorteil, der hier allerdings nicht zm tragen kommt :/ : änderungen optimierungen etc kann mit der VM gleich überprüfen da man das system starten kann, das geht mit einfachem dd leider nicht.


    PS : ist für Virtualbox eigentlich eine gastunterstürzung für ARM cpus geplant ? das wär super :)

    Edited once, last by speefak ().

  • Hallo,


    vielen Dank für die sehr ausführliche und kompetente Anleitung!
    Für ein regelmäßiges Backupverfahren sind die Schritte allerdings sehr aufwendig.
    Trotzdem habe ich sehr durch diese Anleitung gelernt und ich denke, daß ich Teile davon
    für einen Backup verwenden kann


    Vielen Dank


    Uwe

  • Zum Danke sagen gibt es unten Rechts einen Button, den ihr bitte anstelle eines extra Posts betätigt! --> [Blocked Image: http://www.forum-raspberrypi.de/images/english/postbit_l_add.gif]


    Wenn hier jeder ein "zum Danke sagen poste ich mal" täte, stünden in den Anleitungs-Threads 100000 Beiträge nur aus "Danksagungen" ... Das selbe Spiel wie mit individuellen Problemen die Anleitungsthreads voll zu kleistern: irgendwann wird es extrem unübersichtlich




    Und zu guter letzt: Keiner sollte regelmäßig ein vollständiges Abbild seiner SD erstellen (wurde hier aber auch schon erwähnt oder nicht?), das belastet die SD nur völlig unnötig und verkürzt rapide dessen Lebensdauer.


    Ein mal ein Abbild erstellen, dann davon ein Backup mounten und mithilfe von rsync nur noch veränderte Dateien aktualisieren, ist sinnvoller als jedesmal alles zu kopieren.


    Da das aber ein anderes Thema ist, hat das mit diesem Thread hier nichts mehr zu tun. Wer dazu mehr wissen möchte betätigt bitte die Forumsuche oben rechts!

  • ...Und zu guter letzt: Keiner sollte regelmäßig ein vollständiges Abbild seiner SD erstellen (wurde hier aber auch schon erwähnt oder nicht?), das belastet die SD nur völlig unnötig und verkürzt rapide dessen Lebensdauer.


    Ein mal ein Abbild erstellen, dann davon ein Backup mounten und mithilfe von rsync nur noch veränderte Dateien aktualisieren, ist sinnvoller als jedesmal alles zu kopieren.

    Das sehe ich absolut genauso. Allerdings verstehe ich den Punkt 'Belastung' im negativen Sinne nicht so ganz, denn beim DD wird die Karte ja nur gelesen - nicht geschrieben - und nur letzteres ist lebensdauerverkürzend für die SD Karte.

    "Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." Linus Benedict Torvalds, 28.9.2003


    Hast Du die Woche schon Deine Raspberry gesichert :shy: Bei mir tut das automatisch raspiBackup ;)

  • Hallo zusammen,


    seit ein paar Wochen gehöre ich auch zum "Raspberry Pi Fan und Spieleclub". ;) Bin sehr begeistert und habe mir neben den beiden B+ Teststellungen einen Pi 2 und letzte Woche noch den Pi 3 geholt. Ich habe den Pi auch schon erfolgreich in einer meiner Vorlesungen eingesetzt. Ich werde ihn auf jeden Fall weiterhin einsetzten und entwickel dazu derzeit ein "Vorlesungs-Image" bzw. portiere mein Altes. In diesem Zusammenhang habe ich ein paar Anmerkungen bzw. Ergänzungen zu der SD-Image Erstellung für diejenigen, die eine angepasste, wiederverwendbare Raspberry Pi Linux Distribution als Image unter Windows erstellen wollen.


    Auf https://www.raspberrypi.org/ und auch hier im Forum/Thread wird der Win32DiskImager zum lesen und schreiben von Images empfohlen. Ich habe ihn mit zwei Alternativen verglichen, dem USB Image Tool und ODIN. Hier meine Erkenntnisse und Ergebnisse mit ein paar persönlichen Bemerkungen:


    -----------------------------------------------------------------
    Größe und Belegung der verwendeten SD-Karte:
    -----------------------------------------------------------------
    Disk /dev/mmcblk0: 1.9 GiB, 1.977.614.336 bytes, 3862528 sectors


    Filesystem Size Used Avail Use% Mounted on
    /dev/root 1.8G 1.1G 533M 68% /
    /dev/mmcblk0p1 60M 20M 41M 34% /boot
    -----------------------------------------------------------------


    -----------------------------------------------------------------
    [1] Win32DiskImager (=> Projektseite)
    -----------------------------------------------------------------

    • Installation notwendig.
    • Endung wird nicht automatisch vergeben.
    • Irreführend Bezeichnung (Read/Write: Welche "Seite" ist Read und welche Write? Write Image oder Write SD?).
    • Zeit zum Erstellen eines Images (manuell gestoppt):

      • Dauer: 1:51 Min.
      • Größe des Images: 1.977.614.336 Byte (1,84 GB)
      • MD5: 9BD29D6076928034AAA70F847EEEA28D


    -----------------------------------------------------------------
    [2] USB Image Tool (=> Projektseite)
    -----------------------------------------------------------------

    • Keine Installation notwendig.
    • Zeit zum Erstellen eines Images (manuell gestoppt):

      • Dauer: 1:46 Min.
      • Größe des Images: 1.977.614.336 Byte (1,84 GB)
      • MD5: 9BD29D6076928034AAA70F847EEEA28D



    -----------------------------------------------------------------
    [3] ODIN (=> Projektseite)
    -----------------------------------------------------------------

    • Keine Installation notwendig.
    • Auswahl über Devicenamen (gewöhnungsbedürftig).
    • Beim Restore wird kein Fortschritt angezeigt.
    • Folgende Optionen für das Backup gesetzt:

      • Save all Blocks
      • GZip Compression
      • Store image in one file


    • Zeit zum Erstellen eines Images (Werte von ODIN):

      • Dauer: 2:54
      • Größe des Images: 800.285.299 Byte (763 MB)
      • MD5: 8609FD9F2D02A0677BF199D7FB0CDD16



    Fazit:


    Win32DiskImager und das USB Image Tool erstellen identische Images. Ich persönlich ziehe für solche Images das USB Image Tool vor, da es nicht installiert werden braucht. Es wird bei mir als "PortableApp" eingesetzt.


    ODIN ist mein Favorit für die Imageerstellung. Es kommt zwar nicht mit den offiziellen Images klar - dafür muss man weiterhin [1] oder [2] nutzen, aber im Gegensatz zu den beiden vorherigen komprimiert es das Image, was bei einer großen Anzahl von Images Platz auf der Platte schafft. In dem zuvor gezeigten Beispiel wird as Image auf ca. 40% reduziert. Wer genug Platz für seine Images hat, kann sich natürlich die Kompression sparen und so schneller Images erstellen. Der Einsatz bzw. Umstieg auf ODIN ist dann nicht notwendig. Für mich ist die Platzersparnis wichtiger als die Zeitersparnis.


    Die Tests sind ohne "Nullen" des freien Bereiches erfolgt. Wer noch kleinere Images erzeugen will, kann die Karte unter dem Pi mit folgendem Befehl vorbereiten:


    Code
    $ sudo dd if=/dev/zero of=/tmp/zero bs=32k; rm -f /tmp/zero


    Bei mir ist mit dieser Vorbereitung zum Beispiel aus einer 4 GB SD-Karte mit ca. 1,1 GB Belegung eine 380 MB große (bzw. kleine) Imagedatei geworden.



    [TOM]


  • was soll die dd Zeile bewirken ?

  • was soll die dd Zeile bewirken ?


    Damit wird der Speicherplatz einer SD Karte komplett mit nullen beschrieben, wodurch ein später erstelltes Image der SD Karte besser/kleiner komprimiert werden kann. Das hab ich auch in Beitrag#2 unter "Hauptmerkmal dieser Anleitung" beschrieben.


  • ... unter dem Pi mit folgendem Befehl vorbereiten:


    Code
    $ sudo dd if=/dev/zero of=/tmp/zero bs=32k; rm -f /tmp/zero


    ...


    jetzt wo ich gerade hier in der Nähe war: sorry, aber da fehlt imho was ...
    Wo ist die Angabe für die Grösse der Ausgabedatei ( also z.B. count= )?
    cu,
    -ds-

  • Das wird in diesem Fall nicht benötigt.. dd schreibt solange in die Datei /tmp/zero bis der Datenträger voll ist.



    Man muss dabei allerdings beachten das /tmp/ unter Umständen als tmpfs gemounted ist und somit nicht wirklich/direkt der freien Speicherplatz der SD beschrieben wird... Man kann die Datei (output file) aber auch einfach nach zum Beispiel /home/pi/ schreiben lassen was den selben Effekt hat. Es geht ja nur darum den noch freien Speicherplatz sozusagen platt zu machen.


    "sudo" kann man übrigens bei "sudo dd if=/dev/zero of=/tmp/zero bs=32k; rm -f /tmp/zero" auch weg lassen da jeder in /tmp/ schreiben darf ;)

  • Ah ja ... stimmt. Das ging ja darum das Image besser komprimieren zu können.
    Da hat mich die Aussage

    Quote


    Wer noch kleinere Images erzeugen will, kann die Karte unter dem Pi mit folgendem Befehl vorbereiten:


    auf die falsche Fährte gelockt :blush:
    Is aber auch schon früh heute ;)


    bye,
    -ds-

  • "Ah ja ... stimmt. Das ging ja darum das Image besser komprimieren zu können. " - Dito ...


    aber für ein image erstellt mit dd zwecks mount der imagedatei bringt das ganze auch nix. Partitionen verkleinern und dann mit dd sichern macht da mehr sinn.

    Edited once, last by speefak ().


  • Das wird in diesem Fall nicht benötigt.. dd schreibt solange in die Datei /tmp/zero bis der Datenträger voll ist.


    Danke, dass Du das Antworten übernommen hast [emoji106]


    [TOM]

  • Mal ne Frage zum freien Speicher. Nach der "Installation" von Jessie wird doch der freie Speicher "expanded". Kann man das rückgängig machen? Wenn man das System auf einer 8GB Karte installiert hat, und dieses "expandieren" rückgängig machen könnte, bräuchte man ja eigentlich nicht die kompletten 8GB zur Sicherung. Da könnte ja evtl. u.U vllt. eine 4GB Karte reichen ;)
    Oder geht das prinzipiell nicht rückgängig zu machen?

  • Ja. Siehe hier für die Details.

    "Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." Linus Benedict Torvalds, 28.9.2003


    Hast Du die Woche schon Deine Raspberry gesichert :shy: Bei mir tut das automatisch raspiBackup ;)