Überblick

raspiBackup erstellt Backups vor Raspberry Pis. Das Script kann den erstellten Backup auch wieder restoren. Dabei werden auf der Ziel SD Karte neue Partitionen angelegt und dann mit dem entsprechenden Tool (dd, tar oder rsync) die Daten wieder restored. Das dd Backup kann man auch unter Windows restoren. Alle anderen Backuptypen benötigen eine Raspberry mit einem laufenden Raspbian oder ein anderes System, welches Linux als Betriebssystem hat. Ein manueller Restore der Daten mit den zuvor benutzten Backuptools dd, tar oder rsync ist natürlich auch möglich. Sollte ein externes Rootfilesystem gesichert worden sein wird es auch wieder auf ein externes Gerät zurückgespielt.

 

Funktionsübersicht

  • Einfacher Restore der Sicherung für Windows, Mac oder Linux Benutzer mit der Raspberry selbst
  • Meldungen in Deutsch und Englisch
  • Externes Rootfilesystem kann gesichert und restored werden wenn der normale Backupmodus und ein tar oder rsync backup benutzt wurde
  • Einsetzbar auch zum Klonen von einer Raspberry Pi
  • Einfacher Update des Scripts durch die aktuellste Version (-U Parameter)
  • Raspberry Pi kann sich selbst wiederherstellen

 

Inhaltsverzeichnis

Aufrufsyntax und -optionen

Wiederherstellungsszenario für Windows- und Macbenutzer

Wiederherstellungsszenario für Linuxbenutzer

Beispielaufrufe

 

Aufrufsyntax und -optionen

raspiBackup muss als Benutzer root oder per sudo aufgerufen werden.

raspiBackup.sh Option1 Option2 Option3 ... [Backupverzeichnis bzw Backupdatei] 

Je nachdem ob das Quellsystem nur die SD Karte benutzt oder sein Rootfilesystem extern ausgelagert hat sind zwei verschiedene Aufrufe des Restores zu unterscheiden, die durch den Parameter -R gesteuert werden.

Parameter Funktion Standard
-d

Ausgabedevice (die SD Karte). Beispiel: /dev/sda

Achtung: Dieses Device wird vollständig gelöscht und neu angelegt. Ab der Version 0.6.1.3 wird automatisch bei tar und rsync Backup die Größe der root Partition entsprechend verkleinert oder vergrößert wenn die SD Karte eine andere Größe hat als die SD Karte des Backups.

Keiner
-R

Partition auf welchem das root Verzeichnis restored werden soll. Beispiel: /dev/sdb1

Achtung: Die Partition wird neu formatiert. Deshalb aufpassen, dass es die richtige Partition ist!

Durch diese Option kann man Backups von Systemen restoren, die eine externe Partition als Rootpartition benutzen wie USB Sticks oder Festplatten. Dieses ist nur möglich wenn ein tar oder rsync Backup vorliegt.

Hinweis: Diese Option steht nur zur Verfuegung wenn der normale Backupmodus benuzt wurde. Im partitionsorientierten Modus (Option -P) kann keine externe Rootpartition mitgesichert werden.

Keiner
-0 Es wird kein neues Paritionslayout auf der SD Karte erstellt sondern das existierende benutzt. Details dazu siehe FAQ #6 Keiner


 

Wiederherstellungsszenario für Windows- und Macbenutzer

Sofern eine DD Backup erstellt wurde kann das mit dem Windows32DiskImager restored werden. Alternativ kann jedes Backup mit der Pi wiederhergestellt werden. Soll ein TAR oder RSYNC Backup wiederhergestellt werden muss dieser alternative Weg beschritten werden. Die folgenden Schritte sind notwendig:

1) Ein raspbian auf der Raspberry starten

2) Die SD Karte auf die wiederhergestellt werden soll muss in einem SD Kartenlesen angeschlossen werden

3) Das Medium, welches das Backup enthält (z.B. eine Platte) muss angeschlossen und gemounted werden bzw ein Netzwerklaufwerk mit den Backupdaten muss gemounted werden

4) Falls die Rootpartition ausgelagert wurde muss eine weitere Platte angeschlossen werden, die die Rootpartition enthält, welche wiederhergestellt werden soll

Dabei wird üblicherweise die SD Karte /dev/sda, die Backuppartition /dev/sdbx und eine eventuelle Rootpartition /dev/sdcx. Wird ein Netzlaufwerk benutzt ist die Rootpartition dann üblicherweise /dev/sdbx

Die aktuelle Gerätebelegung kann anders sein und sollte immer mit

sudo parted -l 

überprüft werden um zu vermeiden dass andere Partitionen irrtümlicherweise überschrieben werden.

 

Wiederherstellungsszenario für Linuxbenutzer

Dieses sieht genauso aus wie das für Windows- und Macbenutzer. Im Unterschied braucht aber die Raspberry Pi nicht benutzt sondern wird die SD Karte mit dem SD Kartenleser an das Linuxsystem angeschlossen, die Backuppartition gemounted und eine Partition für ein eventuelles externes Rootfilesystem bereitgestellt.

 

Beispielaufrufe

Notwendige Hardware für den Restore:

1) Eine laufende Raspberry Pi mit einem laufenden raspbian oder einem anderen Linux Betriebssystem oder ein anderer Linux Rechner mit installiertem raspiBackup.

2) Einen angeschlossener SD Kartenleser und eingelegte neuer SD Karte

3) Ein angeschlossenes Backupdevice (per USB oder Netz)

4) Falls eine externe Rootpartition wiederherzustellen ist muss noch per USB eine weitere Platte oder SD Karte angeschlossen sein.

 

Restore auf eine SD Karte

  1. Das gesicherte System heisst im Beispielaufruf raspberrypi
  2. SD Karte die den Restore der Boot- und Rootpartition erhalten soll ist im Beispiel als sdf verfügbar. Achtung: Alle bestehenden Daten der SD Karte werden nach einer Sicherheitsabfrage von raspiBackup vor dem Restore gelöscht.
  3. Das zu restorende Backup ist unter /remote/raspifix/disks/backup/rsync/raspberrypi/raspberrypi-rsync-backup-20141230-213032/ verfügbar
  4. Hier ist beschrieben wie man den aktuellen Wert für -d herausfinden kann
sudo raspiBackup.sh -d /dev/sdf /remote/raspifix/disks/backup/rsync/raspberrypi/raspberrypi-rsync-backup-20141230-213032/

Sollte das zu restorende Backup ein tar oder dd Backup sein sieht der Aufruf wie folgt aus

sudo raspiBackup.sh -d /dev/sdf /remote/raspifix/disks/backup/tar/raspberrypi/raspberrypi-tar-backup-20141230-213032.tar

oder

sudo raspiBackup.sh -d /dev/sdf /remote/raspifix/disks/backup/dd/raspberrypi/raspberrypi-dd-backup-20141230-213032.img

 

Restore auf eine SD Karte und eine externe Partition

  1. Das gesicherte System heisst raspberrypi
  2. Es wurde auf /dev/sda eine entsprechend grosse Partition /dev/sda1 angelegt um den Restore aufzunehmen. Eine Formatierung ist nicht notwendig.
  3. Die SD Karte die den Restore der Bootpartition erhalten soll ist im Beispiel als sdf verfügbar. Achtung: Alle bestehenden Daten der SD Karte werden nach einer Sicherheitsabfrage von raspiBackup vor dem Restore gelöscht.
  4. Die externe Rootpartition auf der das Rootfilesystem restored werden soll liegt im Beispiel auf sda1. Achtung: Alle Daten der Partition /dev/sda1 werden nach einer Sicherheitsabfrage von raspiBackup vor dem Restore gelöscht.
  5. Das zu restorende Backup ist unter /remote/raspifix/disks/backup/rsync/raspberrypi/raspberrypi/-rsync-backup-20141230-213032/ verfügbar
  6. Hier ist beschrieben wie man den aktuellen Wert für -d und -R herausfinden kann
sudo raspiBackup.sh -d /dev/sdf -R /dev/sda1 /remote/raspifix/disks/backup/rsync/raspberrypi/raspberrypi-rsync-backup-20141230-213032/ 

 

Wie kann man die Gerätenamen der externen SD Karte und externen Platte herausfinden?

Auf demr raspberry muss man folgenden Befehl eingeben:

fdisk -l | egrep "^Disk /|^/dev"

Die Ausgabe sieht dann z.B. wie folgt aus:

pi@raspberrypi:~# sudo fdisk -l | egrep "^Disk /|^/dev"
Disk /dev/mmcblk0: 8011 MB, 8011120640 bytes
/dev/mmcblk0p1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          122880    15646719     7761920   83  Linux
Disk /dev/sda: 15.5 GB, 15548284928 bytes
Disk /dev/sdb: 300.1 GB, 300069052416 bytes
/dev/sdb1               1   586072367   293036183+  ee  GPT

Nun sieht man dass die interne SD Karte /dev/mmcblk0 8GB gross ist, die neue externe SD Karte /dev/sda 16Gb gross ist und die externe Platte /dev/sdb auf die die Rootpartition gebracht werden soll ist 300GB gross und hat eine Partition /dev/sdb1.

Somit sind ist der Parameter für  -d /dev/sda (Externe SD Karte). Falls eine externe Rootpartition mitgesichert wurde ist noch -R /dev/sdb1 (Externe Rootpartition) notwendig. Die Parameter müssen natürlich den lokalen Gegebenheiten angepasst werden.

 

Hinweis

EIn Backup sollte regelmäßig getestet werden ob der Restore immer noch funktioniert und auch immer noch alle Daten beinhaltet. Nichts ist so frustrierend wenn man in dem Moment, wo man das Backup benötigt, feststellt, dass das Backup korrupt ist oder nicht alle Daten enthält. Ein Test ist bei der Raspberry recht einfach. Eine neue SD- Karte einlegen, das Backup restoren und von der neuen SD-Karte booten.

Falls aus irgendwelchen Gründen der Restore mit dem Script fehlschlägt kann man natürlich jederzeit die vom Script gesicherten Daten mit den Standard Linuxtools, die zum Backup genutzt wurden - dd, tar oder rsync - wieder restoren. Allerdings geht das dann nicht so bequem wie mit dem Script.
 

Kommentar schreiben

Spam Kommentare sind sinnlos !
Vor der Publizierung wird jeder Beitrag auf Spam geprüft. Leider dauert es deswegen bis ein Kommentar sichtbar wird. Dafür erhält aber kein Subscriber Spam eMails.
Die eMail ist optional und nicht öffentlich sichtbar. Sie ist notwendig um eMail Benachrichtigungen zu Antworten auf Kommentare zu erhalten. Sie wird auch u.U. auch vom Seitenbetreiber genutzt um offline Kontakt aufzunehmen.

Spam comments are useless !
Any comment will be reviewed first and checked for spam. Unfortunately this delays the publishing of comments but will protect subscribers from spam.
eMail is optional and hidden and is required to get update notifications for any comments. In addition your eMail may be used by the website owner to get in contact with you offline.


Kommentare   

+1 #128 framp 2017-06-23 22:48
Moin e-raser,

ich habe Deine ganze Sache die letzten Tage genauer getestet und geprüft:

zu 1) Das war ein Bug. Bislang hat ihn niemand bemerkt weil immer sofort ntp das Datum korrigiert hat. Das ist in der aktuellen Version gefixed.
zu 2) Das konnte ich nicht reproduzieren

Ansonsten stellte ich fest dass ein Jessie Image, welches mit tar gesichert und restored wird keine IP bekommt. Also genau dass was Du erfahren hast. Bei Wheezy gibt es keine Probleme mit tar Backups. Das irre ist, dass ein Jessie Image welches per rsync gesichert und restored wird ohne Probleme eine IP bekommt :kopfkratz:

Ich werde das weiter untersuchen und hoffentlich die Ursache finden. :crossingfingers:

Cu framp
Zitieren
+1 #127 framp 2017-06-20 20:21
Moin e-raser,

freut mich dass Dein System wieder läuft :thumbsup:

Vielen Dank auch für den Update und die ausführlichen Infos. Ich habe heute morgen Deinen Kommentar gelesen und mir nach meiner Antwort vorgenommen die Ursache dieses Problems jetzt mal genauer zu analysieren. Ich bin wie Du im Forenbeitrag ja gesehen hast auch schon auf das Problem gestossen.

Zu Deinen weiteren Punkten die Du entdeckt hast:

1) Habe ich auch schon festgestellt. Eigentlich setzt raspiBackup die Raspi fake rtc auf das aktuelle Restoredatum. Bei Wheezy ist dann die Zeit OK. Ich muss mal prüfen was sich da bei Jessie geändert hat.
2) Sehr merkwürdig. Ich prüfe das mal bei einem restoreten Jessie.
3+4) Das sind beides Serverdienste. Wenn Du sie nicht -o vor dem Backup gestoppt hast kann ich mir vorstellen, dass das die Ursache ist

Zu Deinen Fragen:
a) 3 und 4 ist sehr wahrscheinlich. 1 und 2 hat sicherlich andere Ursachen
b) raspiBackup sichert alle Daten - ausser Verzeichnisse die wirklich nicht benötigt werden oder die Du mit weiteren Optionen excludest
c) siehe (a)

Cu framp
Zitieren
0 #126 e-raser 2017-06-20 19:37
@framp,

--> Lösung #1 zum dhcpcd-Problem hat geholfen. Habe das für mich auch so dokumentiert, für mögliche zukünftige raspiBackup-Res tores sind also schonmal 3 Stunden Nerven und Zeit eingespart.

Allerdings hatte ich weitere Probleme nach dem Restore, welche ich nicht vorenthalten will - ggf. sind einige davon ja auch "irgendwie" (wie das dhcpcd-Problem) auf das Backup zurück zu führen (tar in meinem Fall):
1) Uhrzeit ist falsch --> klar, ntp synct sich via Netz, zurückzuführen auf das dhcpcd-Problem = gelöst
2) "ping adress-or-IP" nicht möglich, Fehler: "Ping: icmp open socket: Operation not permitted". Lösung gem. https://ubuntuforums.org/showthread.php?t=927709: "sudo chmod u+s /bin/ping" ! Auch sehr seltsam, vor dem Backup haben die Filerechte ja auch gepasst.
3) Webmin: Defekt (Anzeige/Fehler "Require proc/proc-lib.p l failed : Died at (eval 118) line 1." für die meisten Module). ==> Problem: In /proc darf man als User nicht schreiben --> Neuinstallation Webmin (auf alte Config aufbauend) nötig!, am einfachsten (sofern via Paketlisten installiert) via "sudo apt-get install --reinstall webmin"
4) VNC-/X-Sessions : einige Einstellungen (Erweiterungen) für die Taskleiste (= lxpanel) fehlten und mussten neu hinzugeklickt werden.

Sonst soweit nichts entdeckt. V. a. 3 ist ekelig (wenn auch 'leicht' zu fixen) und vermutlich auf "in Betrieb während raspiBackup läuft" zurück zu führen.

Abschliessende offene Frage:
Sind diese o. g. Probleme nach einem raspiBackup (tar)-Restore ggf. darauf zurückzuführen, dass
a) raspiBackup im laufenden Betrieb sichert
b) bestimmte Verzeichnisse nicht mitsichert
c) bestimmte Dateien sich während dem Backup ändern (ich die zugehörigen Dienste also vorher stoppen/nachher wieder starten sollte)?

Erstmal aber nochmal vielen Dank für deine Hilfe mit den Lösungsoptionen - hat mir einige Stunden gespart :-)
Zitieren
+1 #125 framp 2017-06-20 07:56
Moin e-raser.

Das ist natürlich sehr blöd :cry: Besonders weil es jetzt im Ernstfall auftritt. Hast Du keinen Restoretest gemacht wie ich es an verschiedenen Stellen empfehle?

Anyhow:

Folgende Lösungsmöglichk eiten sehe ich:

1) Starten des Backups mit einem angeschlossenen Monitor und Tastatur. Dann
Code:sudo ifup eth0
sudo dhcpcd eth0

Dann bekommt Deine Raspi wieder eine IP. Allerdings nur bis zum naechsten Restart :sad: Wenn Du nun den dhcpcd5 deinstallierst und wieder installierst ist das Problem behoben:
Code:sudo apt-get remove dhcpcd5
sudo apt-get install dhcpd5


2) Wiederaufnahme des Threads und vielleicht hat ja noch jemand aus der Community eine andere Idee

3) Vielleicht hat ja jemand der hier mitliest ein Jessie am laufen und die Lösung. Bei mir läuft kein Jessie.

4) Wie im verlinkten Beitrag gesagt auf networkd umstellen.

Ich druecke Dir die Daumen dass eine der Lösungsmöglichk eiten zum Erfolg führt.

Solltest Du irgendwie rausbekommen was die Ursache für dieses blöde Verhalten ist wäre es nett dieses hier mitzuteilen damit andere Benutzer von Jessie nicht auch in dieses Loch reinfallen.

Cu framp
Zitieren
0 #124 e-raser 2017-06-20 03:39
Hi framp,

ich musste nun zum ersten Mal den Ernstfall durchführen und ein Image restoren. Alles prima soweit, BIS auf eine gravierende Sache: Kein Netzwerk. Ist ein Raspbian Jessie und genau das Problem, welches du hier beschrieben hast:
http://www.forum-raspberrypi.de/Thread-raspbian-geklontes-jessie-image-bekommt-keine-netzwerkverbindung

Nur... was ist nun die akute Lösung für mich? An das Quellsystem (microSD tot...) komm ich nicht mehr ran um dhcpcd rauszuwerfen, ich kann nur noch das Zielsystem (also die wiederhergestel lte Kopie) modifizieren.

Brauche hier DRINGEND Hilfe, das System ist schon viele Stunden offline und die Nachtschicht hat sich bisher leider nicht gelohnt... :-(
Zitieren
0 #123 framp 2017-05-12 19:23
Moin Chris,

wie man sieht ist es absolut wichtig zu testen ob alles funktioniert wenn man raspiBackup einsetzen moechte. Speziell da Du keine Raspi benutzt sondern eine Bananapi. Allerdings sollte es damit auch funktionieren.
Du hast mir ja schon das restore log zugechickt. So wie ich es sehe ist schon beim Backup was schief gelaufen.

Kannst Du bitte noch mal ein Backup erstellen und mir von dem Lauf das Log zuschicken?

Cu framp
Zitieren
0 #122 Chris 2017-05-12 10:51
Hallo framp,

ich wollte gerade ein Restore vom meinem erstellten Backup machen, um zu testen, ob dies auch im Notfall funktioniert.
Es ist ein tar-Backup, wo die root-Partition auf einer externen Platte liegt. Mein Befehl lautet:
raspiBackup.sh -d /dev/sdb -R /dev/sda3 /media/driveb/r aspibackup/bana napi/bananapi-t ar-backup-20170 511-030001/

Nun bekomme ich aber leider eine Fehlermeldung:
--- RBK0009I: bananapi: raspiBackup.sh V0.6.2 (554d0d7) um Fri May 12 10:27:36 CEST 2017 gestartet
--- RBK0128I: Logdatei ist /root/raspiBackup.log
--- RBK0116I: Konfigurationsd atei /usr/local/etc/ raspiBackup.con f wird benutzt
--- RBK0138I: Bootbackup /media/driveb/r aspibackup/bana napi/bananapi-t ar-backup-20170 511-030001/bana napi-tar-backup -20170511-03000 1.tar wird benutzt
--- RBK0068I: Bootpartitionsd ateien des Backups aus dem Verzeichnis /media/driveb/r aspibackup/bana napi/bananapi-t ar-backup-20170 511-030001 die mit bananapi-backup beginnen werden benutzt
!!! RBK0018W: Ziel /dev/sdb mit 15.06 GiB ist größer als die Backupquelle mit 14.16 GiB. Die root Partition wird entsprechend vergrößert um den ganzen Platz zu benutzen
!!! RBK0065W: Gerät /dev/sdb wird repartitioniert und die gesamten Daten werden gelöscht
--- RBK0067I: Momentane Partitionen auf /dev/sdb:
Number Start End Size Type File system Flags
1 1.05MB 15213MB 15212MB primary ext4
--- RBK0146I: Keine Partitionstabel le auf /dev/sda gefunden
!!! RBK0069W: Bootpartition /dev/sdb1 wird formatiert und erhält die zurückgespielte Bootpartition
!!! RBK0070W: Rootpartition /dev/sda3 wird formatiert und erhält die zurückgespielte Rootpartition
--- RBK0038I: Bist Du sicher? j/N
j
--- RBK0050I: Backup wird von /media/driveb/r aspibackup/bana napi/bananapi-t ar-backup-20170 511-030001 zurückgespielt
--- RBK0051I: Master boot backup wird von /media/driveb/r aspibackup/bana napi/bananapi-t ar-backup-20170 511-030001/bananapi-backup.mbr auf /dev/sdb zurückgespielt
--- RBK0052I: Partition(en) werden auf /dev/sdb erstellt
!!! RBK0004W: Zweite Partition wird von 0 Bytes auf 915.09 MiB angepasst
??? RBK0111E: Fehler beim Erstellen der Partitionen.RC
??? RBK0077E: Restore fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen . RC: 112

Was mach ich falsch?

Gruß, Chris
Zitieren
0 #121 framp 2017-03-04 09:44
Moin Kurt,

Code:-l debug -m detailed -L current funktioniert. Ich habe darüber schon diverse Logs erstellen lassen und analysiert. Du musst mal den genauen Befehl (copy/paste) hier mitteilen.

Eigentlich funktioniert das Rückspielen auf eine kleinere SD Karte funktionieren. Aber nur wenn Du tar oder rsync benutzt hast. DD geht nicht. Ausser Du hast DEFAULT_DD_BACK UP_SAVE_USED_PA RTITIONS_ONLY benutzt und Deine Partition auf der 32GB Karte auf < 16 GB angelegt.

Sofern Du keinen DD Backup versuchst zu restoren kann ich Dir auch die aktuelle Betaversion V0.6.1.3b-4-bet a3 zuschicken und Du testest die mal aus.

Cu framp
Zitieren
0 #120 Kurt 2017-03-03 11:19
Moin framp,

habe gerade erfolgreich einen restore eines backups einer 32GB Karte auf eine 32GB SD Karte gemacht. Das gleiche auf eine 16 GB Karte schlug fehl mit dem Fehler:

--- RBK0009I: raspberrypi: raspiBackup.sh V0.6.1.3b um Fr 3. Mär 11:04:16 CET 2017 gestartet
??? RBK0015E: Ein Fehler ist aufgetreten mit Rückgabewert=112
??? RBK0077E: Restore fehlerhaft bendet: Create partition error (RC 112).

In beiden Fällen habe ich folgenden Befehl verwendet (V 0.6.1.3b):
sudo raspiBackup.sh -d /dev/sdc /media/Back/raspberrypi/raspberrypi-rsync-backup-2017…

Ich wollte dann die zusätzlichen Optionen -l 1 -m 1 bzw. -l debug -m detailed -L verwenden, da kam aber der Fehler:
RBK0147E: 1 (bzw. debug) nicht gefunden.

In Deinem blog fand ich einen Hinweis vom 24.9.16 (Helmut) mit gleichem obigem Fehler, auf den Du auch geantwortet hattest.

Frage: ist ein restore auf eine kleinere SD Karte noch nicht möglich?

Danke.
Kurt
Zitieren
0 #119 framp 2017-01-05 10:09
Moin Saschko,

freut mich dass es nun funktioniert :thumbsup:.

Zugegebernermassen hatte ich auch solch eine Vermutung und haette das mit dem Log auch sehr schnell rausgefunden. Aber bevor ich hier lange Frage und Antwort spiele frage ich lieber immer gleich nach dem Log. Da steht die Wahrheit drin :lol:

Cu framp
Zitieren