Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv
 

Ü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

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

Hinweis:  Eine Partition wie z.B. /dev/sda1 führt zu einem Fehler.

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.

Hinweis: Diese SD Karte darf nicht die aktuell vom Betriebssystem benutzte SD Karte sein. Es muss eine zweite mit einem Kartenleser angeschlossene Karte sein.

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   
#319 framp 2019-07-31 20:36
Moin hardl,

[end Kernel panic - not syncing:VFS: Unable to mount root fs on unknown-block7179,2) ]
Das Image ist mist. Siehe mein vorhergehenden Kommentar.

Cu framp
Zitieren
#318 framp 2019-07-31 20:34
Moin hardl,

Zitat:
Das Image davon ist genauso groß, wie die Ziel-SD:
Das Image muss so gross sein wie die Quell SD :roll: Wenn es so gross ist wie die Ziel SD hast Du die Ziel SD gesichert, nicht die Quell SD. Keine Ahnung wie Du das geschafft hast :-*

Cu framp
Zitieren
#317 hardl 2019-07-31 15:21
Inzwischen habe ich auch einen Schirm angeschlossen:
Stop ist bei:
[end Kernel panic - not syncing:VFS: Unable to mount root fs on unknown-block7179,2) ]
Zitieren
#316 hardl 2019-07-31 14:06
Hier habe ich nochmals die Größen der beiden SD`s aufgelistet.
Original SD:
/dev/mmcblk0
Disk /dev/mmcblk0: 29.8 GiB, 31973179392 bytes, 62447616 sectors

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 93802 85611 41.8M c W95 FAT32 (LBA)
/dev/mmcblk0p2 98304 62447615 62349312 29.7G 83 Linux

Ziel-SD:
Disk /dev/sda: 29.7 GiB, 31914983424 bytes, 62333952 sectors

Device Boot Start End Sectors Size Id Type
/dev/sda1 8192 93802 85611 41.8M c W95 FAT32 (LBA)
/dev/sda2 98304 62447615 62349312 29.7G 83 Linux

Die zu kopierende ist ca. 60 MB größer.

Das Image davon ist genauso groß, wie die Ziel-SD:
openHABianPi-dd-backup-20190729-145742.img
31.914.983.424 Byte (31,92 GB auf dem Volume)
Zitieren
#315 framp 2019-07-31 14:00
Moin hardl,

daran kann es nicht liegen. Es muss irgendwo in Deinem Setup ein HW/SW Problem geben. Was zeigt denn der Schirm beim Booten des Images welches vom dd Backup erstellt wurde?

Cu framp
Zitieren
#314 hardl 2019-07-31 10:04
Hallo framp,
ist es möglich, dass ich schon beim Anmelden auf dem Raspi bei openHAB Fehler mache und somit nicht die ganze SD im Backup enthalten ist?

Anmeldung im Terminal(MAC) mit "ssh openhabian@openhabianpi"
Passwort
Ausgabe: [09:47:27] openhabian@openHABianPi:~$
Eingabe: "sudo bash"
Passwort
Ausgabe:[09:50:50]root@openHABianPi:/home/openhabian#
"cd /"
Ausgabe:[09:52:40] root@openHABianPi:/#
Eingabe: "sudo raspiBackup.sh -a : -o : -m detailed"

Nachdem bei mir noch nie ein Backup funktioniert hat, egal ob mit raspiBackup mit dd, rsync oder direkt dd, rsync, von der Eingabe, muss ich mal alles infrage stellen.
Zitieren
#313 framp 2019-07-30 22:09
Moin Hardl,

:cry: . Ein dd Backup wird 1 zu 1 restored und sollte sofort wieder starten. D.h. entweder ist das Backup korrupt oder das restorte Image.

Dann bleibt nur noch mal einen Schirm an die Raspi anzuschliessen und nachzusehen was fuer Fehlermeldungen auf dem Schirm erscheinen.

Allerdings ist es haeufig schwer aus den Ausgaben zu erkennen wo das Problem liegt.

Cu framp
Zitieren
#312 hardl 2019-07-30 21:58
Es sind 2 Stück 32GB SD Karten und das Sichern auf das NAS ging in 45 Minuten.
Nachdem ich das Image auf die Festplatte gezogen und mit Etcher auf die SD kopiert habe, braucht das Restore ca. 40 Minuten.
Es gibt auch keine Fehlermeldungen, aber beim Booten blinkt der Raspi 2x und dann nichts mehr.
Zitieren
#311 framp 2019-07-30 14:30
Moin hardl,

ein dd Backup wird von raspiBackup mit dem Linux tool dd restored. Das klappt aber auch mit dem win32diskimager (selbst getestet) und andere raspiBackup Benutzer haben von erfolgreicher Nutzung von Etcher zum Restore des dd Backups berichtet. Zu Apple-Pi Backer habe ich keine Kenntnis.

3.5 Stunden ist sehr lang. Hast Du so eine riesige SD Karte gesichert? Oder liegt es an der langsamen NAS Anbindung da Du davon Dein Backup liest?

Kennst Du FAQ26? Wenn Deine Ziel SD Karte nur ein Byte kleiner ist bekommst Du beim Restore Fehler. Dann musst Du Dir eine groessere SD Karte besorgen oder das existierende Image verkleinern (mit pishrink z.B.) Ansonsten mal das dd Backup auf eine USB Platte oder USB Stick kopieren und restoren. Kann sein dass auch Deine NAS Anbindung beim Restore Probleme macht.

Cu framp
Zitieren
#310 hardl 2019-07-30 13:29
Moin framp,
dank Deiner Unterstützung ist es mir gelungen, mit raspiBackup unter dd auf meinem QNAP NAS, ein Image von Openhab ohne Fehlermeldung zu erstellen. Das habe ich mit Etcher auf eine neue SD gespielt. Auch mit ApplePi-Baker kommt nach 3 1/2 Std. die Meldung : Error - Error reading/writing input and/or output file(s)
Die SD bootet aber nicht.
Ist das mit Restore raspiBackup anders?
Zitieren
#309 framp 2019-07-29 22:20
Moin Yuan,

raspiBackup kannst Du nicht zum Clonen von SD zu SSD benutzen. SD->SD, SSD->SSD und SD(boot)/SSD(root)->SD(boot)/SSD(root) geht dagegen.

D.h. Du musst nur einmal Deinen SD Inhalt manuell ohne raspiBackup auf Deine SSD clonen. Wie das geht habe ich hier beschrieben.

Danach kannst Du raspiBackup benutzen um ein Backup von Deiner SSD anzufertigen.

Cu framp
Zitieren
#308 Yuan 2019-07-29 21:36
Hi Framp,

zuerst möchte ich mich bei dir herzlichen bedanken, dass du so ein tolles Skript entwickelt hast und immer gepflegt hast. Ich habe dein Skript immer gebraucht und bis jetzt auch alles funktioniert.

Momentan habe ich vor, mein Raspberry Pi nicht von SD-Karte sondern von ein SSD über USB zu booten, dadurch ich mir keine Sorge über die Lifetime der SD-Karte machen muss.

Ich habe ein Backup aus mein 16GB MicroSD Karte erstellt und möchte auf ein 120GB Samsung 840EVO SSD zurückzuspielen. Der Backup und Restore lief ohne problem. Die Partition "boot" ist auch in der SSD zu sehen.

Nun kann das System nicht von SSD gebootet werden. Ich habe vorher das Boot von SSD mit den aktuellen Raspbian Buster Lite ohne Problem mehrmals geschafft. Das System auf meiner SD-Karte soll auch die Aktuelles sein.

Könnten Sie irgendwie feststellen, woran das Problem liegen kann?

Vielen Dank für weitere Hilfe.
Beste Grüße aus Ingolstadt
Yuan
Zitieren
#307 ahmet 2019-07-29 13:46
zitiere framp:
Moin ahmet,

danke fuer die Info. Mir ist die Ursache beim Lesen des Codes aufgefallen:
Initial ist /etc/crontab.d/raspiBackup
Code:
0 5 * * 0 root /usr/local/bin/raspiBackup.sh

Bei Dir steht bei der 0 ein * und das erzeugt den Fehler. Hast Du die Datei manuell editiert? Die geaenderte Syntax bedeutet es wird jeden Tag gesichert. Das wird aber nicht vom Installer unterstuetzt. Ich kann mir das mal merken und vielleicht bringe ich die Option 'taeglich' in einer naechsten Release rein.

Cu framp


morgen framp, nein eigentlich nicht kann es mir auch nicht erklären aber ich passe es an, danke für die schnelle hilfe!
Zitieren
#306 framp 2019-07-29 11:25
Moin ahmet,

danke fuer die Info. Mir ist die Ursache beim Lesen des Codes aufgefallen:
Initial ist /etc/crontab.d/raspiBackup
Code:<br />0 5 * * 0 root /usr/local/bin/raspiBackup.sh<br />
Bei Dir steht bei der 0 ein * und das erzeugt den Fehler. Hast Du die Datei manuell editiert? Die geaenderte Syntax bedeutet es wird jeden Tag gesichert. Das wird aber nicht vom Installer unterstuetzt. Ich kann mir das mal merken und vielleicht bringe ich die Option 'taeglich' in einer naechsten Release rein.

Cu framp
Zitieren
#305 framp 2019-07-29 10:26
Moin sarcos,

da ist irgendwo der Wurm drin :cry: . Kannst Du mir bitte ddie Debuglogs vom Backup und Restore an diese eMail schicken damit ich nach der Ursache suchen kann?

Vielen Dank.

Cu framp
Zitieren
#304 sarcos 2019-07-28 23:02
Hallo,
leider bekomme ich bei meinem Restore-Versuch immer den Fehler "??? RBK0061E: Keine Bootpartitionsdateien in /backup/openHABianPi/openHABianPi-rsync-backup-20190728-182855 gefunden die mit openHABianPi-backup beginnen."

Auf der Website finde ich leider nichts zu dem Fehler, das Backup ließ sich fehlerfrei erstellen. Laut log versucht das Programm .img, .tmg, .sfdisk. und .mbr zu finden, die in dem Verzeichnis aber nicht angelegt sind. Muss ich vorher noch einen anderen Schritt durchführen?

Danke!
Zitieren
#303 ahmet 2019-07-28 21:19
zitiere framp:
Moin ahmet,

vielen Dank fuer den Hinweis. Ich habe versucht den Fehler zu reproduzieren, es aber nicht geschafft :cry:

Koenntest Du vielleicht mal die Ausgabe von
Code:sudo cat /etc/cron.d/raspiBackup bei Dir zeigen?

Cu framp


Hallo framp, sicherlich. Die Ausgabe schaut wie folgt aus:
---------------------------------------------------------
#
# Crontab entry for raspiBackup.sh
#
# (C) 2017-2019 framp at linux-tips-and-tricks dot de
#
# Create a backup once a week on Sunday morning at 5 am (default)
#
0 2 * * * root /usr/local/bin/raspiBackup.sh
-------------------------------------------------------------
Zitieren
#302 framp 2019-07-28 16:21
Moin ahmet,

vielen Dank fuer den Hinweis. Ich habe versucht den Fehler zu reproduzieren, es aber nicht geschafft :cry:

Koenntest Du vielleicht mal die Ausgabe von
Code:sudo cat /etc/cron.d/raspiBackup bei Dir zeigen?

Cu framp
Zitieren
#301 ahmet 2019-07-28 15:15
Hallo,

habe einen Fehler in der InstallationsUI entdeckt. Folge ich M3>C9>R2 (Wochentag des wöchtentlichen Backups) fliege ich aus dem Programm und es kommt folgende Meldung:
/usr/local/bin/raspiBackupInstallUI.sh: Zeile 2150: *: Syntax Fehler: Operator erwartet. (Fehlerverursachendes Zeichen ist \"*\").

mfg
Zitieren
#300 Senfsosse 2019-04-19 19:29
Hallo framp,

ja, das Ziel ist 32 GB, die Quelle 16 GB. Debug-Log ist unterwegs.

Gruß
Senfsosse
Zitieren
#299 framp 2019-04-19 16:03
Moin Senfsosse,

Du benutzt den partitionsorientierten Modus (Option -P). In diesem gibt es keine automatische Groessenanpassung falls die Ziel SD Karte zu klein ist. eigentlich sollte raspiBackup das feststellen und eine entsprechende Fehlermeldung schreiben. Pruefe bitte ob die Ziel SD Karte wirklich groesser ist als die Quell SD Karte (Siehe hier.
Falls ja schicke mir bitte das Debuglog zu zwecks Analyse (eMail siehe Kontakt Seite).

Cu framp
Zitieren
#298 Senfsosse 2019-04-19 13:47
Hallo framp,

ich habe mein erstes rsync Backup erstellt und anschließend den Restore versucht. Der schlägt aber fehl mit

>>> Created a new DOS disklabel with disk identifier 0x0b77cd68.
/dev/sda1: Created a new partition 1 of type 'W95 FAT16 (LBA)' and of size 63 MiB.
Partition #1 contains a vfat signature.
/dev/sda2: Created a new partition 2 of type 'Extended' and of size 14,8 GiB.
/dev/sda3: Created a new partition 5 of type 'Linux' and of size 32 MiB.
Partition #5 contains a ext4 signature.
/dev/sda6: Start sector 204800 out of range.
Failed to add #6 partition: Das numerische Ergebnis ist außerhalb des gültigen Bereiches


Hast du 'ne Idee, was da im Argen ist?

Grüße
Senfsosse
Zitieren
#297 framp 2019-03-29 08:13
Moin Lars,

BananaPi teste ich nicht aber es müsste mit raspiBackup funktionieren. Benutze doch mal die Option Code:-l debug beim Backup und Restore und schicke mir logs per email zu. Siehe dazu die Kontaktseite.

Cu framp
Zitieren
#296 lars 2019-03-28 23:54
ich habe den schnellstart befolgt und mit
sudo raspiBackup.sh -a : -o : -m detailed
das erste backup erstellt, ohne fehlermeldung. das wollte ich nun testen mit
sudo raspiBackup.sh -d /dev/sdb /backup/bananapi/bananapi-rsync-backup-20190328-213712/
aber es bricht mit fehler RC 102 und RBK0061E: Unable to find bootpartition files ab.
was ist der grund?
wonach soll ich suchen?
Zitieren
#295 motofix 2019-03-20 17:57
Hallo framp,
meine Fehlerbeschreibung hat sich erledigt.
Die SD-Karte hatte im Cardreader keinen richtigen Kontakt.
Restore läuft.
Vielen Dank für dieses Tool. Werde noch etwas tiefer einsteigen.
Gruß motofix
Zitieren
#294 framp 2019-01-27 18:11
Moin Bernd,

ach so - das willst Du machen :roll:

Nein, auf ein laufendes System einen Backup zurueckzuspielen mag gelingen - macht aber keiner da das System in einen undefinierbaren Zustand kommen wird der einfach unbrauchbar ist.

Cu framp
Zitieren
#293 Bernd 2019-01-27 18:04
Hallo framp,
das mit den Schlauch durchschlagen hat soweit geklappt, da ich verstanden habe, dass ich das Backup nur auf einen 'andere - 2-SD-Karte' zurückspielen kann!

Mein Test sollte auf die einzige im Raspi eingetseckte (also gebootete) SD-Karte das Backup zurück spielen. Klappt so nicht!

Also, ich haben verstanden!

Danke + Gruß
Bernd
Zitieren
#292 framp 2019-01-27 17:50
Moin Bernd,

dann versuche ich mal den gordischen Schlauch zu durchschlagen :-)

So wie ich es sehe Du hast ein Backup auf /dev/sda1, welches auf /backup gemounted ist, gesichert. Nun willst Du es auf eine andere SD Karte zurückspielen. Dazu musst Du eine weitere SD Karte mit einem SD Kartelesen in Deine Raspberry einstecken. Die taucht dann vermutlich bei Dir dann als /dev/sdb bei Code:sudo fdisk -l | egrep "^Disk /|^/dev" auf.

Den Befehl habe ich oben angegeben. Nur ist es da umgekehrt: /dev/sda ist eine 16GB SD Karte und /dev/sdb1 ist eine USB Platte von 300GB welches das Backup enthaelt.

Cu framp
Zitieren
#291 Bernd 2019-01-27 17:35
Hallo framp,
ich stehe auf'n Schlauch.

pi@pi3:~ $ df -h
Dateisystem Größe Benutzt Verf. Verw% ingehängt auf
/dev/root 15G 3,2G 11G 24% /
devtmpfs 460M 0 460M 0% /dev
tmpfs 464M 0 464M 0% /dev/shm
tmpfs 464M 12M 452M 3% /run
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 464M 0 464M 0% /sys/fs/cgroup
/dev/mmcblk0p1 44M 23M 22M 51% /boot
tmpfs 93M 0 93M 0% /run/user/1000
/dev/sda1 7,1G 3,8G 3,0G 57% /backup

somit kein /dev/sbd vorhanden.
welches /dev/??? muss ich umount + benutzen?

Danke + Gruß
Bernd
Zitieren
#290 framp 2019-01-27 16:28
Moin Bernd,

siehe Beitrag 288. Ich hatte das übersehen und den Beitrag entsprechend updated.

Cu framp
Zitieren
#289 Bernd 2019-01-27 16:27
zitiere framp:
Moin Bernd,

Du musst nur die neue SD Karte umounten mit
Code:sudo umount /dev/sda1

Aber ACHTUNG! Stelle sicher dass /dev/sda1 das Deine SD Karte ist und nicht irgendeine angeschlossene Platte !!!

Cu framp


sda1 ist mein USB-stick mit den Backup-Dateien.
Die SD-Karte ist die, von der ich das Backup gemacht haben.
Zum Testen wollte ich also das Backup auf die SD-Karte zurück spielen.

Danke + Gruß
Bernd
Zitieren
#288 framp 2019-01-27 16:17
Moin Bernd,

auf /dev/sda1 liegt Dein Backup. Das wird so überschrieben! Du musst fuer -d Deine SD Karte angeben, also z.B. /dev/sdb !!!

Dann muss es heissen
Code:sudo raspiBackup.sh -d /dev/sdb /backup/pi3/pi3-rsync-backup-20190127-120126/

Cu framp
Zitieren
#287 Bernd 2019-01-27 15:31
Hallo framp,
Backup wie beschrieben auf /dev/sda1/backup.
Für das restore benutze ich:
sudo raspiBackup.sh -d /dev/sda1 /backup/pi3/pi3-rsync-backup-20190127-120126/

und erhalte den Fehler:
??? RBK0154E: Ein Restore ist nicht möglich wenn eine Partition von /dev/sda1 ge mounted ist.
Was mache ich falsch.

Danke + Gruß
Bernd
Zitieren
#286 framp 2019-01-27 14:58
Moin Bernd,

so ganz verstehe ich Deine Frage nicht :sad: . Diese Seite beschreibt doch genau wie es geht. Wo verstehst Du etwas nicht?

Cu framp
Zitieren
#285 Bernd 2019-01-27 14:04
Hallo framp,
Ich habe wie beschrieben einen USB-Stick in das Verzeichnis /backup geladen (mount /dev/sda1 /backup) und raspiBackup als RSYNC ausgeführt. Das Backup liegt nun unter /backup/pi3/pi3-rsync-backup-20190127-120126. pi3 ist dabei mein Raspi der gesichert wurden.

Nun möchte ich das Backup testen, also restore ausführen, ohne die Hardware zu verändern.
Wie lautet der Aufruf?

Danke + Gruß
Bernd
Zitieren
#284 framp 2019-01-23 20:04
Moin waldbone,

raspiBackup ist ein AllOrNothing Tool. D.h. wenn Du nur Teile aus dem Backup restoren willst musst Du - wie Du schon geschrieben hast - mit Linux Bordmitteln arbeiten. Wie das geht habe ich ja geantwortet.

Cu framp
Zitieren
#283 waldbone 2019-01-23 08:28
Vielen Dank für die Info.
Und wie mache ich es in meinen zwei Beispielen mit dem raspiBackup-Tool?
Zitieren
#282 framp 2019-01-18 20:25
Moin waldbone,

das ist zwar nicht der Normalfall aber es geht mit dem raspiBackup Backup:

Du kannst jedes tar Backup mit
Code:cd /; tar -xvzf /backup/mmcblk0p5.tar.gz
oder
Code:cd /; tar -xvf /backup/mmcblk0p5.tar
restoren. Denke aber daran vorher die Partition auf die Du restoren willst zu löschen - ausser Du willst die Dateien des Backups dazufügen ;-)

Cu framp
Zitieren
#281 waldbone 2019-01-18 09:29
Hallo, ich bin grad das Tool ausführlich am testen und bisher funktioniert das Sichern sehr gut. Aufgrund der Größe meiner Partition (120GB) wähle ich als Backuptyp tar (gezippt und ungezippt), sowie ein partitionsorientierter Backup.

Einige Auszüge aus der raspiBackup.conf:
DEFAULT_BACKUPTYPE="tar"
DEFAULT_ZIP_BACKUP="0"
DEFAULT_PARTITIONBASED_BACKUP="1"

Jetzt hab ich zwei Backups, mit folgenden Kommandos erstellt:
a.) sudo raspiBackup.sh -t tar
b.) sudo raspiBackup.sh -t tar -z

Meine Frage ist: Wie kann ich jetzt die einzelne Partition (z.B. sda2) mit Linux-Boardmittel wiederherstellen?

Vorschlag von Rasbian ist ja das Backup mit 'sudo dd if=/dev/sda2 | gzip > backup.gz' zu sichern und mit 'gunzip -c backup.gz | sudo dd bs=4M of=/dev/sda2' wiederherzustellen. Wie ist aber das Kommando bei TAR-Archiven?
Zitieren
#280 framp 2019-01-16 20:09
Moin Chris,

schicke mir doch mal ein Debauglog von einem Backuplauf zu (eMail siehe Kontakt Seite). Daraus kann ich dann sehen wie Dein Environment genau aussieht und es mal versuchen bei mir nachzustellen um zu eruieren wo das Problem liegt.

Kann aber etwas dauern da ich momentan ziemlich busy bin.

Cu framp
Zitieren
#279 Chris 2019-01-16 19:55
Genau, ich nutze den USB-Bootmode. Klappt super. Nur das Backup ist das Problem. Er stopt einfach während des Boot -Vorgangs. So als würde er keine Partition finden von der er Booten soll. Habe daher von SD-Karte gebootet und in die cmdline.txt auf der Boot partition die für dev/sda1 (Usb-HDD) ausgelesene UUID eingetragen. Allerdings weiß ich nicht ob sich diese UUID nicht ändert wenn nur die HDD ohne SDkarte angeschlossen ist. Das hatte ich nicht mehr probiert. Ich bin dann irgendwann auf Backuptyp TAR umgestiegen und das schien vielversprechend. Doch jetzt gerade bin dabei ein Backup testhalber zurückzuspielen und er hängt wieder beim booten. Diesesmal kommt er weiter bis zur meldung: Failed to mount sysfs at /sys: No such file or directory Das gleiche mit proc und devtmpfs. Es muss doch eine funktionierende gescheite Lösung geben =(!
Zitieren
#278 framp 2019-01-12 10:10
Moin Chris,

herzlichen Glueckwunsch zum erfolgreichen Restore mit raspiBackup. Da hast Du ja noch ein weiteres Geschenk vom Weihnachtsmann bekommen :-)

Du schreibst dass Du Boot+Rootfs auf die USB HDD ausgelagert hast. Benutzt Du den USB Bootmode der Raspi. ?

Ich muss gestehen dass der USB Bootmode nicht Teil der Regressiontestsuite ist, da der USB Bootmode nicht auf einer VM getestet werden kann und ein manueller Test zu zeitaufwaendig wie auch der SD Kartenverschleiss zu hoch ist (Siehe Details dazu hier).

Ich stimme Dir aber zu dass es eigentlich keinen Unterschied machen sollte. Was fuer Fehler bekommst Du denn so?

Cu framp
Zitieren