Ü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
  • Manuelle Wiederherstellung eines Backups

 

Inhaltsverzeichnis

Aufrufsyntax und -optionen

Wiederherstellungsszenario für Windows- und Macbenutzer

Wiederherstellungsszenario für Linuxbenutzer

Beispielaufrufe

 

Aufrufsyntax und -optionen

 

Hinweis

Für den Restore sollte immer dasselbe Operatingsystem benutzt werden auf welchem das Backup erstellt wurde. Es gibt Inkompatibiliäten bei geänderten Tools und der Restore bricht dadurch ab. Momentan ist es sfdisk welches sich zwischen Wheezy und Jessie geändert hat.

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.

Ab Version 0.6.3.2 können alle Optionen die etwas ein- oder ausschalten durch ein angehängtes + oder - gezielt ein oder ausgeschaltet werden. Beispiel: Die Option -z sowie die Option -z+ schaltet die Backupcompression ein. Mit der Option -z- wird dagegen die Backupcompression ausgeschaltet. Egal was in der Konfigurationsdatei in dem Parameter DEFAULT_ZIP_BACKUP steht. Damit kann eine Option in der Befehlszeile ausgeschaltet werden obwohl sie in der Konfigurationsdatei eingeschaltet ist.

 


Parameter Funktion Standard
-C Beim Formatieren wird mit der Option -c bei mkfs.ext4 auf Bad Blocks geprüft. Hinweis: Die Restorezeit wird dadurch erhöht. Verfügbar ab V0.6.3.2 Aus
-d

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

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

Keiner
-R

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. Der Parameter definiert die Partition auf welchem das root Verzeichnis restored werden soll. Beispiel: /dev/sdb1.

Achtung: Diese Option nur benutzen wenn sowohl eine SD Karte als auch ein externes Rootfilesystem auf USB Stick benutzt wird. Sonst reicht die Option -d.

Achtung: Die Partition wird neu formatiert. Deshalb aufpassen, dass es die richtige Partition ist und dass die Partition gross genug ist um die Partition des Backups aufzunehmen!

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

--resizeRootFS

--noResizeRootFS

Ab Version 0.6.3.2:

Während der Wiederherstellung kann die Rootpartition auf die maximal verfügbare Größe der SD Karte oder der externen Partition ausgedehnt werden.

Ein
-0 Es wird kein neues Paritionslayout auf der SD Karte erstellt sondern das existierende benutzt. Details dazu siehe FAQ #6 Aus
-1 Das Partitionslayout wird auf der SD Karte erstellt so wie es auf der Original SD Karte existiert und dabei werden sämtliche Fehler die entdeckt werden - incl Fehler dass die Ziel SD Karte zu klein ist - ignoriert.  Siehe FAQ #6 für weitere Details.
Hinweis: Diese Option kann unerwartete Ergebnisse habenBenutze die Option nur wenn Du weisst was Du tust.
 Aus


 


 

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/

 

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

Hinweis

Spam Kommentare werden gelöscht und nicht veröffentlicht. Die Überprüfung wird manuell vorgenommen und deshalb dauert es i.d.R. zwischen ein paar Stunden bis zu einem Tag bis ein Kommentar veröffentlicht wird.

Kommentare   
#271 framp 2018-11-05 20:06
Moin BLW/553/c,

besten Dank für Dein Feedback. Das ist eine interessante Information. Ich hatte schon den Fall dass es Probleme gab weil eine andere OS Version zum Restore benutzt wurde als die mit der der Backup erstellt wurde. Dass die raspiBackup Version eine Rolle spielt sollte eigentlich nicht so sein :cry:

Jetzt wuerde mich wirklich das Debuglog mit -v interessieren. Vielleicht hast Du ja Lust und Laune es zu erstellen und mir zuzuschicken :-*

Wenn nicht ist auch gut. Hauptsache Dein Backup konnte wieder restored werden (Der Trick die Version aus dem Backup zu ziehen ist pfiffig :-) )

Cu framp
Zitieren
#270 BLW/553/c 2018-11-05 19:58
Hallo Framp und Danke für die schnelle Antwort. Das Problem hat sich gelöst! Ich hatte für den Restore nicht die gleiche Version von raspiBackup.sh verwendet, wie für das Backup. Mit der gleichen Version (aus dem TAR-Archiv genommen) lief dann alles smooth.
Zitieren
#269 framp 2018-11-05 16:59
Moin BLW/553/c,

Du kannst noch die Option -v benutzen oder auch die aktuelle Beta wo Du weitere Meldungen von dd zum Fehler sehen solltest.

Ich schätze Mal Deine SD Karte auf die Du restoren willst ist hinüber :sad:

Cu framp
Zitieren
#268 BLW/553/c 2018-11-05 00:10
Hallo framp,

ich versuche gerade auf Linux ein TAR-Backup von einem USB-Stick auf die SD-Karte zu spielen und erhalte dabei immer folgende Fehlermeldung:

??? RBK0030E: .mbr Datei Erzeugung mit dd endet fehlerhaft mit RC 1.
??? RBK0077E: Restore wurde fehlerhaft mit RC 117 beendet. Siehe vorhergehende Fehlermeldungen.

Woran kann das liegen?
Zitieren
#267 framp 2018-11-01 10:46
Moin Roland,

benutze doch bitte die aktuelle Beta mit der Option -l debug und schicke mir das Debuglog per eMail zu (Siehe Kontaktseite). Ohne dieses kann ich leider keine Aussage machen warum nur mmcblk0p1 gesichert wird ;-)

Cu framp
Zitieren
#266 Roland 2018-11-01 08:26
Hi framp.

Mir ging es eigenlich nur darum wie ich die drei Partitonen

/dev/mmcblk0p1: LABEL="BOOT" UUID="78C1-A4EB" TYPE="vfat" PARTUUID="4333b1f2-01"

/dev/sda1: LABEL="boot" UUID="D332-A79C" TYPE="vfat" PARTUUID="b7abddf3-01"

/dev/sda2: LABEL="system" UUID="a1389a4a-766a-43b7-a3dd-dc89722f63d7" TYPE="ext4" PARTUUID="b7abddf3-02"

konsistent sichern kann.

Ich stoppe ja schon diverse Services vorher aber das Script sichert leider nur mmcblk0p1.

Ich nutze das X820 Case mit HDD und einen PI3.

Gruß
Roland
Zitieren
#265 framp 2018-10-02 22:00
Moin Roland,

mache einen normalen offline Restore. Je nachdem was fuer einen Backup Du hast kann man technisch ein laufendes System restoren. Aber Du wirst damit zu 99.99% nicht gluecklich werden.

Cu framp
Zitieren
#264 Roland 2018-10-02 21:54
zitiere framp:
Moin Roland,

Ein laufendes System hat aktiven Hauptspeicher in dem diverse Dinge gecached sind. Wenn Du dann dem unter der Decke Dateien aenderst kommt kein konsistentes System raus.
raspiBackup sichert nur Dateien und keinen Hauptspeicher. Das koennen nur Virtualisierungsloesungen wie VMware mit ihren Snapshots.

Wieso willst Du eigentlich ein laufendes System restoren? Was bezweckst Du damit?

Cu framp


Hi framp.
Ich habe meine nextcloudpi Umgebung durch eine php7.2 Aktualisierung "etwas" zerschossen. Um nun nicht lange nach Fehler zu suchen möchte ich auf schnellstem Wege ein Restore machen...
Gruß Roland
Zitieren
#263 framp 2018-10-02 20:52
Moin Roland,

Ein laufendes System hat aktiven Hauptspeicher in dem diverse Dinge gecached sind. Wenn Du dann dem unter der Decke Dateien aenderst kommt kein konsistentes System raus.
raspiBackup sichert nur Dateien und keinen Hauptspeicher. Das koennen nur Virtualisierungsloesungen wie VMware mit ihren Snapshots.

Wieso willst Du eigentlich ein laufendes System restoren? Was bezweckst Du damit?

Cu framp
Zitieren
#262 Roland 2018-10-02 20:12
"•Raspberry Pi kann sich selbst wiederherstellen"

Folgendes Scenario habe ich hier:

RPI3+ bootet komplett von einer SSD (sda).
Die SD wird nur als "Ablage" genutzt.

Wie kann ich sda1/sda2 restoren quasi im laufenden Betrieb.

Ich habe Backups von Typ DD gemacht.

/dev/mmcblk0p1: LABEL="BOOT" UUID="78C1-A4EB" TYPE="vfat" PARTUUID="4333b1f2-01"

/dev/sda1: LABEL="boot" UUID="D332-A79C" TYPE="vfat" PARTUUID="b7abddf3-01"

/dev/sda2: LABEL="system" UUID="a1389a4a-766a-43b7-a3dd-dc89722f63d7" TYPE="ext4" PARTUUID="b7abddf3-02"

Thx.
Zitieren
#261 framp 2018-09-21 22:29
harrison hat einen Bug gefunden der gefixed ist. Git issuedazu.
Zitieren
#260 framp 2018-09-20 20:24
Moin harrison,

PARTITIONBASED_BACKUP=0 wirkt nur beim Backup. Beim restore wird anhand der vorhandenen Dateien herausgefunden welcher Backupmode vorliegt.

Was genau die Ursache fuer den Fehler ist kann ich so nicht sagen. Schicke mir bitte das Debuglog an meine eMail (Siehe Kontaktseite) zur Analyse zu.

Cu framp.
Zitieren
#259 harrison 2018-09-19 23:28
Guten Abend Framp,
habe ein rsync-Backup von SD-Karte (/boot) und USB-Platte (root-FileSystem) im Normalmodus auf einen USB-Stick (/backup) gemacht. Alles ohne Fehlermeldung.
(backup.img, backup.mbr und backup.sfdisk werden im Verzeichnis angelegt)
Der Restore schlägt dagegen fehl.
Restore-Aufruf:
raspiBackup.sh -d /dev/sdc -R /dev/sdd1 /backup/rsync-backup-20180919-221913/
Restore-Fehlermeldung:
Zugriff auf '/backup/rsync-backup-20180919-221913/*.blkid' (*.parted'/*.fdisk) nicht möglich: Datei oder Verzeichnis nicht gefunden
??? RBK0077E: Restore wurde fehlerhaft mit RC 108 beendet.
Der Restore hat ein partitionbasiertes Backup erkannt,
-> 20180919-225837: DBG -- PartitionbasedBackup detected? 1
obwohl in der log-Datei folgendes steht:
20180919-225836: DBG -- PARTITIONBASED_BACKUP=0 (kommt wohl aus der conf-Datei)
Warum?
Ich verwende die aktuelle Version 0.6.4.
Thx
Zitieren
#258 Jan 2018-07-30 11:15
Hallo Framp,
Ich habe jetzt die Restore versugt weil die 8Gb SD karte segmentation faults gibt. Aber es ended sehr schnell im Fehler RC 117, auch wenn Ich es mit eine neue SD kart von 64 Gb versuche nach reboot.
Ich kann nicht finden was diese Fehler sein soll, auch wenn ich eine der andere backups brauche gibt das dasselbe RC 117.

Hiermit das letzte Teil des logs:
!!! RBK0066W: Device /dev/sdc will be overwritten with the saved boot and root partition.
--- RBK0038I: Are you sure? y/N y
--- RBK0050I: Restoring backup from /media/pi/2a784356-1ec4-43a4-a198-ac8b42d5d256/raspberrypi/raspberrypi-tar-backup-20180722-030002.
--- RBK0051I: Restoring mbr from /media/pi/2a784356-1ec4-43a4-a198-ac8b42d5d256/raspberrypi/raspberrypi-tar-backup-20180722-030002/raspberrypi-backup.mbr to /dev/sdc.
??? RBK0030E: .mbr file creation with dd failed with RC 1.
??? RBK0077E: Restore failed with RC 117. Check previous error messages.

Was bedeutet dieses error?
Zitieren
#257 framp 2018-06-04 19:19
Für die Mitleser,

Markus hat ein raspiBackup Image welches per Stretch erzeugt wurde versucht mit einem Weezy zu restoren. Leider hat sich das sfdisk inzwischen inkompatibel zwischen Wheezy und Stretch geändert :cry:

D.h. es ist tunlichst angeraten ein backup auf der OS version zu restoren auf dem es erstellt wurde. Leider speichert raspiBackup beim backup nicht ab welches OS version benutzt wird und kann deshalb auch nicht auf diese Inkompatibilitaet in einer Meldung hinweisen :sigh:
Zitieren
#256 framp 2018-06-02 12:39
Moin Markus,

der SD Karte ist wohl zu heiss geworder. Oder hat der Blitz eingeschlagen? :-*

Bei den Ausgaben kann ich nicht sehen was die Ursache ist. Lsse den restore noch mal mit der Option Code:-l debug laufen und schicke mir das Debuglog zur Analyse zu. Meine eMail findest Du auf der Kontaktseite ;-)

PS: Du bist nicht der Erste dem das passiert. Und ich sach noch ... :roll:

Cu framp
Zitieren
#255 Markus 2018-06-02 12:06
Hier noch das Log aus der Log-Datei:

20180602-115736: MSG --- RBK0128I: Logdatei ist /home/pi/raspiBackup.log.
20180602-115736: MSG --- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt.
20180602-115739: MSG !!! RBK0065W: Gerät /dev/sdb wird repartitioniert und die gesamten Daten werden gelöscht.
20180602-115739: MSG
20180602-115739: MSG !!! RBK0100W: Gerät /dev/sdb wird mit dem Backup beschrieben.
20180602-115740: MSG --- RBK0038I: Bist Du sicher? j/N
20180602-115742: MSG --- RBK0009I: raspberrypi3: raspiBackup.sh V0.6.3.2a (1015c57) um Sa 2. Jun 11:57:42 CEST 2018 gestartet.
20180602-115742: MSG --- RBK0097I: Partitioniere und formatiere /dev/sdb.
20180602-115742: MSG --- RBK0052I: Partition(en) werden auf /dev/sdb erstellt.
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdb: 14772 cylinders, 64 heads, 32 sectors/track
Old situation:
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/sdb1 8192 93236 85045 c W95 FAT32 (LBA)
start: (c,h,s) expected (4,0,1) found (0,130,3)
end: (c,h,s) expected (45,33,21) found (5,204,60)
/dev/sdb2 94208 30253055 30158848 83 Linux
start: (c,h,s) expected (46,0,1) found (5,220,24)
end: (c,h,s) expected (1023,63,32) found (1023,254,63)
/dev/sdb3 0 - 0 0 Empty
/dev/sdb4 0 - 0 0 Empty

sfdisk: unrecognized input: dos
20180602-115743: MSG
Usage: umount -h | -V
umount -a [-d] [-f] [-r] [-n] [-v] [-t vfstypes] [-O opts]
umount [-d] [-f] [-r] [-n] [-v] special | node...
Usage: umount -h | -V
umount -a [-d] [-f] [-r] [-n] [-v] [-t vfstypes] [-O opts]
umount [-d] [-f] [-r] [-n] [-v] special | node...
20180602-115743: MSG ??? RBK0077E: Restore wurde fehlerhaft mit RC 112 beendet. Siehe vorhergehende Fehlermeldungen.
Zitieren
#254 Markus 2018-06-02 12:05
Hallo,
ich habe beim Restore des Backups leider ein kleines Problem und komme nicht weiter... Ich weiß, es heißt erst das Backup testen, aber wie es der Teufel so will, ist das System erst abgeschmiert, bevor ich eine neue SD organisieren konnte... Also spiele ich das Backup auf die Karte auf, von dem es kommt. Folgende Aufrufe haben ich gemacht und dabei nachfolgeneden Output bekommen:

pi@raspberrypi ~ $ sudo fdisk -l | egrep "^Disk /|^/dev"
Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes
/dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA)
/dev/mmcblk0p2 122880 31116287 15496704 83 Linux
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
/dev/sda1 2048 1953521663 976759808 7 HPFS/NTFS/exFAT
Disk /dev/sdb: 15.5 GB, 15489564672 bytes
/dev/sdb1 8192 93236 42522+ c W95 FAT32 (LBA)
/dev/sdb2 94208 30253055 15079424 83 Linux
pi@raspberrypi ~ $ sudo raspiBackup.sh -m detailed -d /dev/sdb /mnt/fritzbox/Backup_RPi/RPi3/raspberrypi3/raspberrypi3-tgz-backup-20180523-192041/
--- RBK0009I: raspberrypi: raspiBackup.sh V0.6.3.2a (1015c57) um Sa 2. Jun 11:57:36 CEST 2018 gestartet.
--- RBK0128I: Logdatei ist /home/pi/raspiBackup.log.
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt.
!!! RBK0065W: Gerät /dev/sdb wird repartitioniert und die gesamten Daten werden gelöscht.

!!! RBK0100W: Gerät /dev/sdb wird mit dem Backup beschrieben.
--- RBK0038I: Bist Du sicher? j/N j
--- RBK0009I: raspberrypi3: raspiBackup.sh V0.6.3.2a (1015c57) um Sa 2. Jun 11:57:42 CEST 2018 gestartet.
--- RBK0097I: Partitioniere und formatiere /dev/sdb.
--- RBK0052I: Partition(en) werden auf /dev/sdb erstellt.

??? RBK0077E: Restore wurde fehlerhaft mit RC 112 beendet. Siehe vorhergehende Fehlermeldungen.


Nur zur Info, an dem RPi, mit dem ich das Restore mache, hängt noch eine externe HD.

Kann mir hier jemand helfen?

Vielen Dank im Vorraus

Markus
Zitieren
#253 framp 2018-04-01 21:23
Moin Lscheff,

das klingt sehr merkwürdig. Hast Du beim Backup Fehlermeldungen bekommen? Ansonsten lass mal den Backup mit der Option -l debug durchlaufen und schicke mir das Log an meine eMail (-> Kontakt Seite):

Cu framp
Zitieren
#252 Lscheff 2018-04-01 20:42
ich nutze die aktuelle Version und bis aufgrund des dhcp Problems auf rsync umgestiegen.
Habe heute festgestellt bei einem restore dass keine img, mbr, sfdisk Dateien abgelegt wurden. daher auch kein Restore möglich.
ich habe eine neue Installation auf eine 128GB Karte gemacht und dann ca. 4 Probeläufe durchgeführt.
Wo ist mein Fehler?
Zitieren
#251 framp 2018-04-01 10:39
Moin MadTrinity,

freut mich dass der restore nun geklappt hat. ZU Deinem dhcp Problem: Das ist bekannt und wurde u.A. hier schon behandelt ;-)

Cu framp
Zitieren
#250 MadTrinity 2018-04-01 06:19
Hallo Leute,

Danke für eure Hilfe also madm4x mit deinem blkid konnte ich nichts anfangen.

Danke framp mit deinem post konnte ich das Backup erfolgreich zurückspielen ausser Dhcpd scheint alles zu funktionieren

Danke nochmal
Gruss
Mad
Zitieren
#249 framp 2018-03-31 21:28
Moin MadTrinity,

es gibt einen Unterschied zwischen /dev/sda und /dev/sda1: Ersteres ist ein Device/Gerät. Letzteres ist eine Partition.

madm4x hat es geschrieben: Du musst beim Restore ein Gerät angeben - also /dev/sda - keine Partition. Beim ersten Restoreversuch hast Du richtigerweise /dev/sda angegeben. Da war aber /dev/sda1 noch gemounted :sigh: Jetzt hast Du plötzlich ein /dev/sda1 genommen :cry:

Versuche es noch mal wieder mit /dev/sda :-)

Cu framp
Zitieren
#248 madm4x 2018-03-31 20:34
zitiere framp:

Lass mich wissen wenn das noch nicht ausreicht ;-)

Cu framp


Da er schreibt das Null Linuxkenntnisse vorhanden sind, wird das befürchte ich nicht ausreichen ;)

@Mad

bevor du das Backup wiederherstellst solltest du erstmal rausfinden auf welchem Laufwerksname deine neue SD liegt bzw. eingebunden ist. Am einfachste ist das denke ich mit dem Befehl "blkid" .. in der Ausgabe siehst du dann welches Device deine neue SD Karte hat.

Denn /dev/sda sollte oder ist in der Regel immer die Karte auf der sich das System befindet von dem Bootest und mit dem du gerade arbeitest. Und darauf sollte ja wohlkaum das Backup zurück gespielt werden. ;)

Die Neue SD Karte sollte daher eher /dev/sdb oder /dev/sdc lauten so das der Befehl dann raspiBackup.sh -d /dev/sdb oder sdc sein müsste. Und wenn du dir unsicher bist führst du als erstes "blkid" aus und schließt dann die neue SD Karte an. Anschließen führst du "blkid" nochmal aus und siehst welches Device neu hinzugekommen ist.

VG
Zitieren
#247 MadTrinity 2018-03-31 20:14
Hi framp,
danke für deine mühe, linux ist nicht meine Welt habe versucht damit was anzufangen leider ohne erfolg.

sudo parted -l
Model: Generic Mass-Storage (scsi)
Disk /dev/sda: 31,9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 4194kB 31,9GB 31,9GB primary fat32 lba


Model: SD SL32G (sd/mmc)
Disk /dev/mmcblk0: 31,9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 4194kB 70,3MB 66,1MB primary fat32 lba
2 70,3MB 31,9GB 31,8GB primary ext4

sudo mount | grep /dev/sda
/dev/sda1 on /media/pi/3363-6538 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

dann habe ich mal sudo umount /dev/sda1
und danach nochmal das zurückspielen ausprobiert

sudo raspiBackup.sh -d /dev/sda1 /media/NetBackup/raspberrypi/raspberrypi-tar-backup-20180315-051002/
--- RBK0009I: raspberrypi: raspiBackup.sh V0.6.3.1 (590ae9c) um Sa 31. Mär 20:10:47 CEST 2018 gestartet.
??? RBK0086E: Wiederherstellungsgerät darf keine Partition sein.
??? RBK0077E: Restore wurde fehlerhaft mit RC 107 beendet. Siehe vorhergehende Fehlermeldungen.

Was muss ich den jetzt machen habe eine neue SD Karte in den USB Adapter gesteckt da möchte ich gerne das Backup was auf der NAS liegt zurückspielen.

Was muss ich machen?

Gruß
Mad
Zitieren
#246 framp 2018-03-31 17:48
Moin Mad,

Deinen Kommentar habe ich zum Anlass genommen die Fehlermeldung RBK0154E hier zu dokumentieren. Lass mich wissen wenn das noch nicht ausreicht ;-)

Cu framp
Zitieren
#245 MadTrinity 2018-03-31 12:29
Hallo,
habe mir eine neue SD Karte geholt und wollte ein Backup auf die neue Karte zurückspielen.
Das Backup liegt auf meiner NAS, die neue SD Karte ist in einem Adapter am USB eingesteckt.

Blick da nicht so richtig durch
habe es so probiert

sudo raspiBackup.sh -d /dev/sda /media/NetBackup/raspberrypi/raspberrypi-tar-backup-20180315-051002/

bekomme aber eine Fehlermeldung
--- RBK0009I: raspberrypi: raspiBackup.sh V0.6.3.1 (590ae9c) um Sa 31. Mär 12:26:32 CEST 2018 gestartet.
??? RBK0154E: Ein Restore ist nicht möglich wenn eine Partition von /dev/sda gemounted ist.
??? RBK0077E: Restore wurde fehlerhaft mit RC 102 beendet. Siehe vorhergehende Fehlermeldungen.

Kann mir einer bitte schreiben wie ich das Backup jetzt auf die neue Karte bekomme. Es sind nahezunull Linux kentnisse vorhanden.

Vielen Dank vorab
Gruß
Mad
Zitieren
#244 framp 2018-03-24 12:43
Moin Kuppi,

Zitat:
Warum sollte ein Restore auf die gleiche SD-Karte funktionieren, wenn es von einem rsync Backup erfolgreich funktioniert und das System anschließend einwandfrei läuft?
Weil vielleicht andere Stellen auf der SD Karte benutzt werden und keine defekten dabei sind. Mir wurden schon ganz verueckte Fehler bercihtet durch defekte SD Karten. Ist aber nur eine Vermutung meinerseits.

Zitat:
Es treten Fehler auf das Hardware nicht korrekt eingebunden wird, zumeist wird das WLAN nicht eingebunden oder es gibt Schwierigkeiten mit dem Bluetooth. Zuletzt hat bei mir ein Restore von einem tar Archiv gebootet und bei Start von X hat sich das System aufgehangen.
Das könnte natuerlich auch ein Timingproblem beim Booten sein. Ich habe das Gefuehl dass das u.U. mit dem dhcp auch ein Timingproblem sein koennte. Ist aber auch nur eine Vermutung :roll:

Zitat:
Ja, ich benutze für meine Backups nun immer rsync und bestätige das klappt damit auch das Restore.
Ich benutze auch rsync und da laeuft alles ohne Probleme. Ehrlich gesagt finde ich von den drei Backupmethoden, dd, tar und rsync auch rsync das bester Verfahren. Es werden nicht immer alle Daten kopiert und man hat die BackupDaten nicht in einer Datei gepackt sondern gleich griffbereit. Dadurch kann man eben schnell mal einzelene Dateien manuell aus dem Backup zurueckholen wenn man merkt dass eine /etc Datei verhunzt wurde :-)
Zitat:
Ich bin mir nicht ganz sicher ob dass das Backup auch auf nicht Linux Filesysteme funktioniert.
Nein, es funktioniert nicht. rsync benoetigt ext3/4 da es nur da Hardlinks gibt.

Probleme mit tar gibt es immer wieder so dass ich manchmal ueberlegt habe tar ganz rauszunehmen aus raspiBackup. Aber es gibt auch viele Benutzer von tar die haben keine Probleme. Deshalb lasse ich es drin - auch wenn es immer wieder deshalb Problemberichte und Diskussionen gibt.

Cu framp
Zitieren
#243 Kuppi 2018-03-24 12:20
Hallo framp,
das es an einer defekten SD-Karte liegt schließe ich aus. Warum sollte ein Restore auf die gleiche SD-Karte funktionieren, wenn es von einem rsync Backup erfolgreich funktioniert und das System anschließend einwandfrei läuft?

Nein, es liegt nicht daran das keine IP Adresse bezogen wird. Es treten Fehler auf das Hardware nicht korrekt eingebunden wird, zumeist wird das WLAN nicht eingebunden oder es gibt Schwierigkeiten mit dem Bluetooth. Zuletzt hat bei mir ein Restore von einem tar Archiv gebootet und bei Start von X hat sich das System aufgehangen.

Ja, ich benutze für meine Backups nun immer rsync und bestätige das klappt damit auch das Restore. Ich bin mir nicht ganz sicher ob dass das Backup auch auf nicht Linux Filesysteme funktioniert, das teste ich noch mal aus. Aktuell verwende ich immer ein EXT4 Filesystem formatiertes Volume, dann kann man sicher sein das es auch funktioniert.

Gruß,
Kuppi...
Zitieren
#242 framp 2018-03-23 18:26
Moin Kuppi,

wenn Du beim tar Backup beim restorten System unterschiedliches Fehlerverhalten bekommst liegt es vermutlich an einer defekten SD Karte.

Wenn das Verhalten immer gleich ist und keine IP Adresse bezogen wird findest Du direkt unter Deinem kommentar jemanden der selbige Erfahrung gemacht. Dort habe ich auch Hinweise auf loegliche Lösungen genannt:

1) rsync benutzen
2) networkd und nicht dhcpcd benutzen

Auch ich habe dieses Verhalten be Restoretests mit raspiBackup bei Jessie und Stretch festgestellt und versucht eine Lösung zu finden - dann aber nach Tagen der Suche und des Testens aufgegeben :sad:

Cu framp
Zitieren
#241 Kuppi 2018-03-22 16:48
Die erstellten Backups lassen sich nur lauffähig wieder Restoren wenn der Backup Typ rsync ist. Das Backup läuft auch mit tar durch (unabhängig ob mit ZIP oder ohne Komprimierung), aber wenn ich das Backup auf ein Device Restore startet der Raspberry zwar aber läuft nicht richtig. Mal wird Hardware nicht korrekt erkannt, mal bleibt das System beim Bootvorgang irgenwo hängen, etc...etc...
Wiederhole ich den Vorgang mit identischer Hardware (also gleiches Device unter /backup gemountet) nur im Mode rsync und stelle das Restore wieder her, dann läuft alles. Ich vermute das es mit Links (symbolisch oder auch hard) zusammen hängt, bin aber nicht sicher. Auf jeden Fall bekomme ich ein lauffähiges Restore nur von einem rsync erstellten Backup wieder hergestellt, alles andere funktioniert nicht.

Jemand ähnliche Erfahrung oder einen Tipp für mich?

Danke und besten Gruß,
Kuppi...
Zitieren
#240 framp 2018-03-21 22:09
Moin Lscheff,

zitiere Lscheff:

1000 Dank. Hat prima funktioniert, zumindest sieht das nach den ersten Tests gut aus :D
:thumbsup:

zitiere Lscheff:

Kann man nicht ein Diff der dhcpcd5 Installation (Inhalte und Rechte) vorher/nachher machen?


Ich habe Tage spendiert um die Ursache rauszufinden und letztendlich aufgegeben :cry: Ja, kann man sicherlich. Ich habe wie gesagt irgendwann aufgegeben. Es scheint auch irgendwie mit Deinem Router bzw der dhcp Konfig zusammenzuhängen. Das tar bei Jessie ist neu und unterstuetzt weitere Attribute wie xattr. Es kann sein dass dass man damit das Problem loesen kann.

Man muss nur Zeit investieren :-*

Cu framp
Zitieren
#239 Lscheff 2018-03-21 21:40
Hi framp,

ja Jessie und tar backup.

1000 Dank. Hat prima funktioniert, zumindest sieht das nach den ersten Tests gut aus :D

Wenn die De- und Installation von dhcpcd5 erfolgreich war, dann liegt es doch sicher an fehlenden Dateien oder Rechten. mir ist aufgefallen, dass beim ersten Booten die Datei rc.local eine Fehlermeldung gezeigt hat. Kann man nicht ein Diff der dhcpcd5 Installation (Inhalte und Rechte) vorher/nachher machen?
Zitieren
#238 framp 2018-03-20 23:16
Moin Lscheff,

ich vermute mal dass Du ein tar Backup unter Jessie hastdenn nur da weiss ich von einem dhcp Problem beim Restore (Siehe hier) :roll:

Die einzige Möglichkeit die ich kenne erfordert
1) einen angeschlossenen Monitor
2) eine angeschlossene Tastatur
3) eine Kabelverbindung

Dann logon als pi und
Code:sudo dhcpcd eth0<br />sudo apt-get remove dhcpcd5<br />sudo apt-get install dhcpcd5<br />

Vermutlich geht es auch mit einer WLAN Verbindung aber dann muss wlan0 anstatt eth0 benutzt werden.

Cu framp
Zitieren
#237 Lscheff 2018-03-20 22:24
Hi framp,

Habe (glücklicherweise) ein Backup gemacht bevor meine SD Karte dahin ging. Jetzt habe ich das Problem mit dem dhcp nach dem restore. Kannst du mir bitte den workaround geben, damit mein raspi wieder arbeiten kann?
Zitieren
#236 framp 2018-03-01 20:07
Moin dgh,

dieses Szenario wurde nicht beruecksichtigt.

Ich sehe aber drei Moeglichkeiten für Dich:

1) Du probierst es einfach mal aus. Es gibt eine gewisse Wahrscheinlichkeit dass es funktioniert. Dann benutzt noch Du -l debug beim restore und schickst mir das Debuglog per email zu. Vielleicht kann ich es ja relativ schnell fixen.

2) Du definierst die zwei Partitionen (boot und root) auf der SSD und benutzt restore wobei Du auch eine SD Karte benutzt. Dann kopierst Du per DD die Bootpartition des Backups auf die SSD. Anschliessend updatest Du in /etc/fstab die uuid der Bootpartition und nimmst dabei die uuid der Rootpartition aus der fstab.

Cu framp
Zitieren
#235 dgh 2018-03-01 10:07
Hallo,

mein System bootet im Moment von SD und die root partition ist auf einer SSD.
Gesichert wurde immer mit der tar option.Es wurde auch ein image von der boot partition auf der sd erstellt.

Nun möchte ich so restoren (auf eine ssd oder auf eine sd), dass ich das ganze System (root & boot) wieder auf einem einzigen Medium habe.

Wie sieht dazu der restore Befehl aus ? Geht das überhaupt ?

Gruss
Zitieren
#234 framp 2018-02-10 18:43
Moin Matze,

so wie ich es sehe sollte ausser der Homematik SW nicht weiter gestoppt werden müssen.
Vielleicht liest ja auch ein Homematic Benutzer hier mit und kann Dir dazu seinen Kommentar abgeben. Oder Du fragst auch mal im Homematic SW Forum nach ob da jemand raspiBackup benutzt und was er stoppt.

Cu framp
Zitieren
#233 Matze 2018-02-10 18:13
Nabend,

welche Services muss ich vor dem Backup beenden? Könnt ihr mir einen Rat geben? Auf meinem Pi3 läuft die Homematic-Software. Bisher stoppe ich nur "cron".

pi@PiVccu:~ $ service --status-all
[ + ] alsa-utils
[ + ] avahi-daemon
[ + ] bluetooth
[ - ] console-setup.sh
[ + ] cron
[ + ] dbus
[ + ] dphys-swapfile
[ + ] fake-hwclock
[ - ] hwclock.sh
[ - ] keyboard-setup.sh
[ + ] kmod
[ + ] lxc
[ + ] lxc-net
[ + ] lxcfs
[ + ] networking
[ - ] nfs-common
[ - ] paxctld
[ - ] plymouth
[ - ] plymouth-log
[ + ] procps
[ + ] raspi-config
[ + ] rpcbind
[ - ] rsync
[ + ] rsyslog
[ + ] ssh
[ - ] sudo
[ + ] triggerhappy
[ + ] udev

Gruss Matze
Zitieren
#232 Matze 2018-02-08 10:01
Hi framp,

Dank deiner schnellen Hilfe funktionniert der Restore jetzt bei mir. Besten Dank.

Backup mit "rsync" habe ich mit Hilfe der "FAQ 17" überprüft, rsync funktioniert tatsächlich. Ich dachte es wird immer ein komplettes Backup erstellt, weil ich die Speichergröße von den einzelnen Backups verglichen habe, ist immer identisch.

Danke schön

Gruss
Matze
Zitieren
+1 #231 framp 2018-02-07 20:37
Moin Matze,

die Meldunge bekommst Du wenn Du fuer Option -d eine Partition angibst, also z.B. /dev/sda1. Du kannst nicht auf eine Partition restoren. Es muss eine ganze SD Karte sein wie z.B. /dev/sda.

Bist Du sicher dass rsync immer ein komplettes Backup erstellt? Siehe dazu FAQ 17

Cu framp
Zitieren
#230 Matze 2018-02-07 15:05
Hallo,

ich habe von meinem RaspberryPi3, auf dem Raspian Stretch läuft, erfolgreich ein "dd" und ein "tar" Backup erstellt. Bei "rsync" hatte ich Probleme, es wurde jedesmal ein komplettes Backup erstellt.
DIe Backups werden auf meiner Synology NAS abgelegt, das mounten des Laufwerks war kein Problem.
Nun wollte ich zum Test von meinem Laptop (LinuxMint) das Backup auf eine leere SD-Karte (steckt im externen Kartenleser) zurückschreiben.
Nun erscheint aber folgende Fehlermeldung: "RBK0086E Wiederherstellungsgerät darf keine Partition sein".
Wie bekomme ich das Problem gelöst?

Gruss
Matze
Zitieren