Raspi4 – dd Backup SD-Card (Terminal)

Änderungsstand: 2020-03-02

Folgendes ist ab sofort zu beachten! Der /sharedfolders -Ordner wird nicht mehr verwendet! Es werden ab nun die direkten Einhängepunkte angegeben. Infos darüber gibt es hier.

Backup bewusst nicht automatisiert, warum auch immer 🙂

Da ich mächtig Probleme hatte, das Boardeigene dd Backup von OMV wiederherzustellen, machte ich mir Gedanken, einen anderen Weg zu finden. Hier das Ergebnis.

Wir sichern die komplette SD-Card mit dem dd-Befehl und legen die daraus erstellte *.img auf einer Datenplatte ab. Hierfür nehmen wir allerdings nicht die Möglichkeit, die OMV von Haus aus anbietet, sondern arbeiten mit dem Terminal! Ich empfehle, eine SD-Card mit mind. der gleichen Größe zu verwenden, da es sonst zu Problemen kommt. Und da reichen echt schon paar klitzekleine kbit aus. Im Zweifelsfall dann doch eine Größere nehmen.

Als Erstes in OMV einen „Freigabeordner“ erstellen. Ich nenne diesen in meinen Beispiel Backup-dd. Man kann natürlich auch einen Ordner im Terminal, außerhalb von OMV erstellen, sollte dann aber die folgenden Befehle anpassen. Wie das geht, werdet ihr mittlerweile wissen.

Ab ins Terminal und wichtige Werte checken:

blkid -o list

/dev/mcblk0 ist immer die SD-Card, die das Betriebssystem beinhaltet. Meist mit der Endbezeichnung p1 und p2. Alle anderen Laufwerke werden als sd eingebunden (z.B. sda, sdb, sdc usw.)

Um das Image zu erstellen, folgenden Befehl im Terminal eingeben Das Beispiel beinhaltet meine eigenen Werte. Da wir die komplette SD-Card sichern wollen, ignorieren wir die Zusätze p1 und/oder p2! Bitte nach Euren Werten anpassen!

sudo dd if=/dev/mmcblk0 of=/srv/dev-disk-by-label-Extern/Backup-dd/raspi4.img bs=4M status=progress

Für 32 GB, bei einer Schreibrate von ca. 43,8 MB/s waren das etwa 12 Minuten. Übrigens kann dieser Befehl, ohne den Zusatz status=progress, auch in den „Geplanten Aufgaben“ in OMV als Cron-Job angelegt werden, was aber hier gerade nicht thematisiert wird!

Wenn fertig, können wir entweder das Backup mit BalenaEtcher oder Win32DiskImager auf einer SD-Card schreiben oder das soeben angelegte Backup.img, Raspi-Intern auf die Neue SD-Card schreiben. Dieses Beispiel zeige ich jetzt. Die neue SD-Card mit einem Card-Reader o.Ä. anschließen und wieder den folgenden Befehl ausführen und die Werte checken, Wichtig wäre hier die visuelle Ausgabe unter „mount point“ von (not mounted):

blkid -o list

Jetzt kann das eben angelegte Backup auf die neue SD-Card geschrieben werden. Auch hier wieder meine eigenen Werte, wobei meine neue SD-Card in diesem Beispiel /dev/sdc ist (unbedingt darauf achten, dass der Zusatz 1 oder 2 etc. hier NICHT mit angegeben wird!:

sudo dd if=/srv/dev-disk-by-label-Data/Backup-dd/raspi4.img of=/dev/sdc bs=4M status=progress && sync

Für 32 GB, bei einer Schreibrate von ca. 20,4 MB/s (leicht schwankend) waren das etwa 27 Minuten.

Wenn fertig, wurde die System-SD-Card quasi 1 zu 1 über den kleinen Umweg eines Images auf einer neuen SD-Card kopiert/geklont und ist nun funktionsfähig einsetzbar. Durch den angehängten sync-Befehl könnt ihr nun auch die neu beschriebene SD-Card, ohne Zweifel, einfach entfernen. Jetzt wäre übrigens der allerbeste Zeitpunkt, das Restore zu testen! Es wäre fatal, wenn irgendetwas schief gelaufen ist!

Mit…

sudo shutdown now

…den Raspi herunterfahren, dann ausschalten oder Stecker ziehen und die SD-Karten tauschen.

Verwendet man nun z.B. eine 64GB SD-Card, um ein Backup einer 32GB SD-Card zu tätigen, hätte man quasi 32GB der Kapazität in den Wind geschossen. Mit dem Befehl…

sudo raspi-config

… kann man unter Punkt 7 und dann Punkt 1 den restlichen ungenutzen Speicherplatz wieder zum „rootfs“ hinzufügen. Dies geschieht dort automatisch. Erstellt man das Restore mit BalenaEtcher, benötigt man diesen Schritt auch!

Vor- und Nachteile dieser Backup-Restore Variante:

  • Backup und Restore sind im laufenden Betrieb möglich
  • Kein „Mounten“ der neuen SD-Card nötig
  • Man muss sich nicht um die Boot-Partition kümmern (wird automatisch erstellt) [ob das sicher ist bzw. so empfohlen wird, kann ich noch nicht einschätzen. Von 4 Versuchen, funktionierten bei mir alle 4 bestens]
  • Vorhandene Datenbanken können mit gesichert werden, ohne vorher deaktiviert werden zu müssen
  • Leider kein inkrementelles Backup möglich, deshalb eine etwas langwierigere Angelegenheit, als das bei z.B. rsync der Fall wäre

Ich tätigte für mich, bevor ich das Script kannte, manuell, nach der Fertigstellung des Einrichtens des Raspi`s, dieses Backup auf einer zweiten SD-Card. Danach folgen weitere Backups, wenn eine große Veränderung ansteht, wie z.B. ein Kernelupdate oder geplante Änderungen des Systems oder Ähnliches. Hierbei mag ich es sehr, dass ich nicht jedesmal die System-Karte entfernen muss, weil ich Baubedingt, jedesmal erst das Gehäuse aufschrauben müsste, um ein Backup zu tätigen.