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. Bei USB boot Systemen kann eine beliebige Anzaahl von externen Partitionen restored werden ab der Release 0.6.6.
  • 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

  1. Restore auf eine SD Karte
  2. Restore auf eine SD Karte und eine externe Partition

 

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

Ab der Release 0.6.6 kann man die Extension .sh auch weglassen

raspiBackup 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
-G Anzeige des Restorefortschitts Aus
-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.

Hinweis: 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

 

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. Wird die Option ausgeschaltet mit --resizeRootFS- wird die Rootpartition so gross angelegt wie sie auf dem Originalsystem war. Diese Option wirkt nicht wenn die Option -P genutzt wurde beim Backup.

Ein
--updateUUIDs  Verfuegbar ab Release 0.6.5: Beim Restore werden immer die UUIDs bzw PARTUUIDs genommen die das Original hat. Mit dieser Option werden neue UUIDs und neue PARTUUIDs generiert. Aus  
-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. Aus


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 oder der USB Boot Mode benutzt wird wo keine SD Karte mehr benutzt wird muss noch per USB eine weitere Platte 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/ 

 

Restore auf eine USB Platte ohne SD Karte (USB boot mode)

  1. Das gesicherte System heisst im Beispielaufruf raspberrypi
  2. USB Platte die den Restore der Boot- und Rootpartition erhalten soll ist im Beispiel als sdf verfügbar. Achtung: Alle bestehenden Daten der USB Platte 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/

 

 

 

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 ***

Kommentare sind erwünscht. Aber um lästige Spamposts abweisen zu können gibt es ein paar Dinge die zu beachten sind:
  1. Kommentare mit dem Text http werden sofort zurückgewiesen mit der Meldung Sie sind nicht berechtigt den Tag zu verwenden. zz
  2. Kommentare werden manuell überprüft und es dauert deshalb in der Regel einen Tag bis sie veröffentlicht werden.

    Kommentare   
    #383 CHRIStian. 2021-09-05 16:46
    zitiere Andi:
    Hi framp,
    jetzt hat alles wunderbar geklappt.
    Hier noch mal mein Setup:
    sda1: boot
    sda2: root
    sda5: backup und daten

    Backup erstellen:
    sudo raspiBackup.sh -m detailed --ignoreAdditionalPartitions

    Backup wiederherstellen:
    sudo raspiBackup.sh -g -0 -d /dev/sda /home/pi/sda5mount/backup/raspberrypi-rsync-backup-20210802-153743

    in raspiBackup.sh folgende Zeilen auskommentiert:

    if (( $PARTITIONBASED_BACKUP && ( SKIP_SFDISK || $FORCE_SFDISK ) )); then
    writeToConsole $MSG_LEVEL_MINIMAL $MSG_NO_SKIP_OR_FORCE_ALLOWED
    exitError $RC_PARAMETER_ERROR
    fi

    und

    if isMounted "$RESTORE_DEVICE"; then
    writeToConsole $MSG_LEVEL_MINIMAL $MSG_RESTORE_DEVICE_MOUNTED "$RESTORE_DEVICE"
    exitError $RC_MISC_ERROR
    fi

    Ein absolut geniales Tool.
    Vielen Dank für deine Arbeit!
    Beste Grüße,
    Andi


    Vielen Dank! Das ist genau der Anwendungsfall den ich auch brauche.
    Liebe Grüße
    CHRIStian.
    Zitieren
    #382 CHRIStian. 2021-09-05 16:35
    zitiere Andi:
    Hi framp,
    jetzt hat alles wunderbar geklappt.
    Hier noch mal mein Setup:
    sda1: boot
    sda2: root
    sda5: backup und daten

    Backup erstellen:
    sudo raspiBackup.sh -m detailed --ignoreAdditionalPartitions

    Backup wiederherstellen:
    sudo raspiBackup.sh -g -0 -d /dev/sda /home/pi/sda5mount/backup/raspberrypi-rsync-backup-20210802-153743

    in raspiBackup.sh folgende Zeilen auskommentiert:

    if (( $PARTITIONBASED_BACKUP && ( SKIP_SFDISK || $FORCE_SFDISK ) )); then
    writeToConsole $MSG_LEVEL_MINIMAL $MSG_NO_SKIP_OR_FORCE_ALLOWED
    exitError $RC_PARAMETER_ERROR
    fi

    und

    if isMounted "$RESTORE_DEVICE"; then
    writeToConsole $MSG_LEVEL_MINIMAL $MSG_RESTORE_DEVICE_MOUNTED "$RESTORE_DEVICE"
    exitError $RC_MISC_ERROR
    fi

    Ein absolut geniales Tool.
    Vielen Dank für deine Arbeit!
    Beste Grüße,
    Andi


    Vielen Dank! Das ist exakt der Anwendungsfall den ich auch brauche!
    Liebe Grüße
    CHRIStian.
    Zitieren
    #381 Andi 2021-08-02 18:01
    Hi framp,
    jetzt hat alles wunderbar geklappt.
    Hier noch mal mein Setup:
    sda1: boot
    sda2: root
    sda5: backup und daten

    Backup erstellen:
    sudo raspiBackup.sh -m detailed --ignoreAdditionalPartitions

    Backup wiederherstellen:
    sudo raspiBackup.sh -g -0 -d /dev/sda /home/pi/sda5mount/backup/raspberrypi-rsync-backup-20210802-153743

    in raspiBackup.sh folgende Zeilen auskommentiert:

    if (( $PARTITIONBASED_BACKUP && ( SKIP_SFDISK || $FORCE_SFDISK ) )); then
    writeToConsole $MSG_LEVEL_MINIMAL $MSG_NO_SKIP_OR_FORCE_ALLOWED
    exitError $RC_PARAMETER_ERROR
    fi

    und

    if isMounted "$RESTORE_DEVICE"; then
    writeToConsole $MSG_LEVEL_MINIMAL $MSG_RESTORE_DEVICE_MOUNTED "$RESTORE_DEVICE"
    exitError $RC_MISC_ERROR
    fi

    Ein absolut geniales Tool.
    Vielen Dank für deine Arbeit!
    Beste Grüße,
    Andi
    Zitieren
    #380 Marian 2021-08-02 17:19
    zitiere framp:
    Moin Andi,

    sorry - ich habe vergessen dass Du -P nutzt. Dann muss noch

    if (( $PARTITIONBASED_BACKUP && ( SKIP_SFDISK || $FORCE_SFDISK ) )); then
    writeToConsole $MSG_LEVEL_MINIMAL $MSG_NO_SKIP_OR_FORCE_ALLOWED
    exitError $RC_PARAMETER_ERROR
    fi

    auskommentiert werden (# an den Anfang der Zeile schreiben) .

    Aber wie gesagt: Teste das alles erst mal auf einem Testsystem ! Du bewegst Dich auf einem ungetesteten Codepfad :sad:

    Cu framp


    Hallo framp,

    das wahr auch mein Problem warum die Wiederherstellung von sda1 und sda2 mit dem Backup auf sda3 nicht funktioniert hat.
    Ich warte dafür jetzt aber auf das neue Release.

    Für das /media/pi Problem habe ich das Github issue #351 erstellt.

    Mfg Marian
    Zitieren
    #379 Andi 2021-08-02 16:02
    zitiere framp:
    Moin Andi,

    sorry - ich habe vergessen dass Du -P nutzt. Dann muss noch

    if (( $PARTITIONBASED_BACKUP && ( SKIP_SFDISK || $FORCE_SFDISK ) )); then
    writeToConsole $MSG_LEVEL_MINIMAL $MSG_NO_SKIP_OR_FORCE_ALLOWED
    exitError $RC_PARAMETER_ERROR
    fi

    auskommentiert werden (# an den Anfang der Zeile schreiben) .

    Aber wie gesagt: Teste das alles erst mal auf einem Testsystem ! Du bewegst Dich auf einem ungetesteten Codepfad :sad:

    Cu framp


    Hi framp,
    das hat leider nicht funktioniert:

    grep: /home/pi/pladde5/rootBackup/raspberrypi-das_erste_test_backup/raspberrypi-rsync-backup-20210802-131421/raspberrypi-backup.parted: No such file or directory
    ??? RBK0001E: Unexpected program error occured. (9df3c1e), Linenumber: 6479, Error: This error should not occur.
    ??? RBK0148E: @@@@@@@@@@@@@@@@@@@@ Stacktrace @@@@@@@@@@@@@@@@@@@@

    Es sieht so aus dass meine backup platte die ich vorher unter pladde5 gemountet hatte vom programm vorzeitig geunmounted wurde.
    Jedenfalls ist sie nach der fehlermeldung nicht mehr gemounted.

    Könnte ich das backup nicht auch einfach anstatt mit -P -T "1 2" mit --ignoreAdditionalPartition erstellen?

    Vielen Dank,
    Andi
    Zitieren
    #378 framp 2021-08-02 15:46
    Moin Andi,

    sorry - ich habe vergessen dass Du -P nutzt. Dann muss noch

    if (( $PARTITIONBASED_BACKUP && ( SKIP_SFDISK || $FORCE_SFDISK ) )); then
    writeToConsole $MSG_LEVEL_MINIMAL $MSG_NO_SKIP_OR_FORCE_ALLOWED
    exitError $RC_PARAMETER_ERROR
    fi

    auskommentiert werden (# an den Anfang der Zeile schreiben) .

    Aber wie gesagt: Teste das alles erst mal auf einem Testsystem ! Du bewegst Dich auf einem ungetesteten Codepfad :sad:

    Cu framp
    Zitieren
    #377 Andi 2021-08-02 15:16
    zitiere framp:
    Moin Andi,

    ja das musst Du.

    Ich habe uebrigends einen issue im Github dazu aufgemacht. Ich denke in der naechsten Release wirst Du nichts mehr auskommentieren muessen :-)

    Cu framp


    Vielen Dank,
    habe es probiert, kriege aber diese Fehlermeldung:
    Option -0 and -1 are not supported with option -P.

    Lg,
    Andi
    Zitieren
    #376 framp 2021-08-02 12:52
    Moin Andi,

    ja das musst Du.

    Ich habe uebrigends einen issue im Github dazu aufgemacht. Ich denke in der naechsten Release wirst Du nichts mehr auskommentieren muessen :-)

    Cu framp
    Zitieren
    #375 Andi 2021-08-02 12:06
    zitiere framp:
    Hm ... daran habe ich nicht gdeacht. Die Ueberpruefung macht bei Option -0 keinen Sinn. Du musst raspiBackup.sh ein wenig aendern. Du musst entweder die folgenden Zeilen loeschen - oder besser - jeweils ein # an den Anfang der jeweiligen Zeile schreiben. Aber Achtung: Wenn Du die Datei unter Windows aenderst solltest Du notepad++ benutzen damit Du keine Windows Only Zeichen reinbringst (CR LF statt LF)


    Hallo framp,
    Muss ich dann auch diese Änderung vornehmen bevor ich mit diesem befehl restore?
    sudo raspiBackup.sh -g -0 -d /dev/sda /media/mounted/backup/raspberrypi/raspberrypi-rsync-backup-20141230-213032/

    Vielen Dank,
    Andi
    Zitieren
    #374 framp 2021-08-02 11:09
    Moin Andi,

    alle Restoreoptionen sind auf HTTPS://www.linux-tips-and-tricks.de/de/13-raspberry/240-restore-eines-mit-raspibackup-sh-erstellten-backups/ beschrieben. Dort findest Du auch die Option -0 (kein Oh sondern Null :lol: ).

    Aber bevor Du das auf Deinem Produktivsystem durchfuehrst solltest Du vorher das Ganze auf einem Testsystem testen ;-)

    Cu framp
    Zitieren
    #373 framp 2021-08-02 11:02
    Moin Marian,

    Zitat:
    Evtl. wird eine solche Funktion noch implementiert da in Zukunft wohl mehr Pis mit größeren SSDs betrieben werden und ich nur das reine System aber auf der gleichen SSD sichern möchte bevor ich upgrades durchführe.
    Ich habe einen issue im Github dazu erstellt. Ich denke im naechsten Release wird die Funktion dann drin sein. (HTTPS://github.com/framps/raspiBackup/issues/349)


    Wenn ich danach ein USB Massenspeicher anschließe wird dieser wie gewohnt automatisch in /media/pi gemountet aber auf dem wiederhergestellten System habe ich für die gemounteten Laufwerke darin angeblich keine Berechtigung und er lässt sie mich nicht öffnen.


    Ohne weitere Informationen kann ich nichts dazu sagen. Bislang wurde mir so ein Problem nicht gemeldet.

    Zeige doch mal folgende Info:
    1) ls -la /media/pi auf dem Originalsystem
    2) ls -la /media/pi vom rsync Backupverzeichnis
    3) ls -la /media/pi auf dem restoreten System

    Cu framp
    Zitieren
    #372 Andi 2021-08-02 01:25
    hallo,
    ich habe eine platte mit folgender konfiguration:
    sda1: boot
    sda2: root
    sda3: backup und daten

    Ich habe schon erfolgreich ein backup der boot und root partition erstellt mit:
    sudo raspiBackup.sh -m detailed -P -T "1 2"
    wie stelle ich dieses backup wieder her, ohne dass meine platte neu formatiert wird und damit meine sda3 daten partition erhalten bleibt?

    Vielen Dank,
    Ani
    Zitieren
    #371 Marian 2021-08-02 00:07
    zitiere framp:
    Moin Marian,

    Es sollte beides funktionieren: Sowohl -P -T "1 2" als auch --ignoreAdditionalPartition. Ich habe aber beides nicht getestet. So wie ich es sehe hat Staphan die 2te Variante genutzt. -B muss nicht genutzt werden denn das dd Boot Image wird in die /boot Partition geschrieben und ueberschreibt nichts.

    Aber ich weise darauf hin dass Du Dich in einem nicht unterstuetzten Anwendungsfall von raspiBackup bewegst und er nicht Teil des Regressiontests ist und somit nicht getestet ist. D.h. teste bevor Du es an einem Produktionssystem nutzt erst einmal auf einem Testsystem ob das alles wie gewuenscht funktioniert. Nicht dass Du Dir irgendwas zerschiesst ;-)

    CU framp


    Die Option mit -P -T "1 2" und -d /dev/sda -0 und der angepassten sh für das gemountete Laufwerk hat in meinem Test leider nicht funktioniert, die Standardvariante dd boot image habe ich noch nicht testen können.

    Ich werde wohl aber vorerst wieder davon Abstand nehmen und mein System wie bisher auch auch der SD Karte laufen lassen. Evtl. wird eine solche Funktion noch implementiert da in Zukunft wohl mehr Pis mit größeren SSDs betrieben werden und ich nur das reine System aber auf der gleichen SSD sichern möchte bevor ich upgrades durchführe.

    Mein Wiederherstellungstest mit Standardeinstellungen auf dem geplanten Produktivsystem auf SD Karte verlief soweit erfolgreich mit einer kleinen Einschränkung. Wenn ich danach ein USB Massenspeicher anschließe wird dieser wie gewohnt automatisch in /media/pi gemountet aber auf dem wiederhergestellten System habe ich für die gemounteten Laufwerke darin angeblich keine Berechtigung und er lässt sie mich nicht öffnen.
    Das löschen des /media/pi Ordners mit root rechten löst zwar das Problem, da der Ordner danach richtig neu angelegt wird aber kannst du das Problem bestätigen?

    Was die Geschwindigkeit des Backups betrifft kein Vergleich zu meinen alten dd backups, danke dafür.
    Zitieren
    #370 framp 2021-07-31 22:44
    Moin Marian,

    zitiere Marian:

    Wie muss ich das Backup erstellen mit der Option -P -T "1 2" oder ist --ignoreAdditionalPartitions evtl. mit -B ausreichend da er ja sonst ein dd der boot partition erstellt.


    Es sollte beides funktionieren: Sowohl -P -T "1 2" als auch --ignoreAdditionalPartition. Ich habe aber beides nicht getestet. So wie ich es sehe hat Staphan die 2te Variante genutzt. -B muss nicht genutzt werden denn das dd Boot Image wird in die /boot Partition geschrieben und ueberschreibt nichts.

    Aber ich weise darauf hin dass Du Dich in einem nicht unterstuetzten Anwendungsfall von raspiBackup bewegst und er nicht Teil des Regressiontests ist und somit nicht getestet ist. D.h. teste bevor Du es an einem Produktionssystem nutzt erst einmal auf einem Testsystem ob das alles wie gewuenscht funktioniert. Nicht dass Du Dir irgendwas zerschiesst ;-)

    CU framp
    Zitieren
    #369 Marian 2021-07-31 03:22
    zitiere Stephan:
    Hallo framp,
    super, restore lief nun durch und hat funktioniert!
    Vielleicht kannst du das ja in einer Folgeversion mit aufnehmen .... wäre super wenn dies über die Config eingestellt werden kann.
    Danke für den Support!
    Gruß
    Stephan


    Hallo ich habe das gleiche vor wie Stephan muss ich die Änderung im Code auch noch vornehmen.
    Wie muss ich das Backup erstellen mit der Option -P -T "1 2" oder ist --ignoreAdditionalPartitions evtl. mit -B ausreichend da er ja sonst ein dd der boot partition erstellt.

    Mfg Marian
    Zitieren
    #368 Andreas 2021-05-20 07:30
    zitiere framp:
    Moin Andreas,

    die Bootpartition standardmaessig wird immer so gross angelegt wie sie zum Zeitpunkt des Backups war. Du kannst aber ein Backup mit der Option -B erzeugen. Wenn Du das restorest wird Deine vorgegebene Partitionsgroesse nicht ueberschrieben.

    D.h. Du kannst entweder mit resizefs oder per GUI mit gparted die Bootpartition resizsen oder Du fertigst noch einmal ein Backup mit der Option -B an und restorest das.

    Ich hoffe ich konnte Deine Frage ausreichend beantworten.

    Cu framp


    Vielen Dank, framp! Natürlich beantwortet das meine Frage allumfassend. Ein gründlicheres Studium der Anleitung hätte mich sicher der Lösung auch allein nähergebracht - so habe ich übersehen, dass die Boot-Partition standardmäßig als dd Backup erstellt wird. Sorry und nochmal vielen Dank. Beste Grüße, Andreas
    Zitieren
    #367 framp 2021-05-19 21:17
    Moin Andreas,

    die Bootpartition standardmaessig wird immer so gross angelegt wie sie zum Zeitpunkt des Backups war. Du kannst aber ein Backup mit der Option -B erzeugen. Wenn Du das restorest wird Deine vorgegebene Partitionsgroesse nicht ueberschrieben.

    D.h. Du kannst entweder mit resizefs oder per GUI mit gparted die Bootpartition resizsen oder Du fertigst noch einmal ein Backup mit der Option -B an und restorest das.

    Ich hoffe ich konnte Deine Frage ausreichend beantworten.

    Cu framp
    Zitieren
    #366 Andreas 2021-05-19 07:09
    Hallo framp,

    eine Frage bitte zum Restore, ich habe ein generelles Verständnisproblem. Zum Umzug eines Systems auf einen größeren USB-Stick habe ich auf diesem Stick zwei entsprechend größere Partitionen angelegt. Der Restore mit der Option "-0" funktioniert tadellos, der Raspi startet ohne Probleme. Das Filesystem auf der Boot-Partition ist allerdings nach dem Restore genauso groß wie auf dem alten, kleineren USB-Stick. Müsste ich mit "resize2fs" das Filesystem nach dem Restore vergrößern, damit die gesamte Partition verwendet wird?

    Danke vorab, Andreas
    Zitieren
    #365 framp 2021-04-27 21:07
    Einen Workaround nicht. Aber einen Hinweis wo Du nachsehen und vermutlich manuell korrigieren musst:

    In /boot/cmdline.txt und /etc/fstab stehen UUIDs der Partitionen, Die muessen zu den existierenden UUIDs der Partitionen passen die die Partitionen bei Dir haben. Mit "sudo blkid" bekommst Du die existierenden UUIDs angezeigt.

    Irgendwas passt da nicht zusammen und deshalb kann raspiBackup die UUID nicht in /boot/cmdline.txt updaten. Was genau nicht stimmt kann ich im Debuglog sehen. Das musst Du kontrollieren und korrigieren. Vermutlich findest Du dann auch raus warum raspiBackup Probleme hat.

    Cu framp
    Zitieren
    #364 Gregor 2021-04-27 20:02
    zitiere framp:
    Moin Gregor,

    RBK0208W erklaert warum das Image nicht bootet. Um die Ursache zu finden brauche ich das Debuglog. Erstelle bitte einen Issue im Github und haenge das Debuglog an.

    Cu framp

    Hallo framp,

    werde ich machen! Hast du vielleicht trotzdem einen Workaround für mich. Würde mir einen ganzen Tag reworken ersparen. :sad: Danke!
    Zitieren
    #363 framp 2021-04-27 19:42
    Moin Gregor,

    RBK0208W erklaert warum das Image nicht bootet. Um die Ursache zu finden brauche ich das Debuglog. Erstelle bitte einen Issue im Github und haenge das Debuglog an.

    Cu framp
    Zitieren
    #362 Gregor 2021-04-27 19:01
    Hallo framp,

    ich habe gesehen, du hast das mounten und unmounten integriert, das ich mir so gewünscht habe. :-)
    Danke!

    Ich habe gerade ein komplett neues Raspberry OS aufgespielt und bin jetzt beim Restortest angelangt. Ich restore hier ein tgz mit dem Pi auf eine baugleiche microSD Karte ohne externer Partition. Aus mir völlig unerfindlichen Gründen erhalte ich den Fehler "RBK0208W Es konnte keine UUID in /boot/cmdline.txt für root erneuert werden" und die SD-Karte bootet nach Fertigstellung im Pi nicht. Ich fürchte ich bin nicht genug Expert um den Fehler eigenständig zu korrigieren. Lg Gregor
    Zitieren
    #361 framp 2021-01-08 14:44
    Freut mich dass es geklappt :-)

    mit der Config braucht man da nichts zu aendern. Das ist ein Fehler im Script den ich fixen werde. Der Codepfad ist nur noch nie durchlaufen worden weil noch niemand auf die Idee gekommen ist raspiBackup so zu verwenden wie Du es tust :roll:

    Cu framp
    Zitieren
    #360 Stephan 2021-01-08 12:59
    Hallo framp,
    super, restore lief nun durch und hat funktioniert!
    Vielleicht kannst du das ja in einer Folgeversion mit aufnehmen .... wäre super wenn dies über die Config eingestellt werden kann.
    Danke für den Support!
    Gruß
    Stephan
    Zitieren
    #359 framp 2021-01-07 19:12
    Hm ... daran habe ich nicht gdeacht. Die Ueberpruefung macht bei Option -0 keinen Sinn. Du musst raspiBackup.sh ein wenig aendern. Du musst entweder die folgenden Zeilen loeschen - oder besser - jeweils ein # an den Anfang der jeweiligen Zeile schreiben. Aber Achtung: Wenn Du die Datei unter Windows aenderst solltest Du notepad++ benutzen damit Du keine Windows Only Zeichen reinbringst (CR LF statt LF)

    Zitat:
    if isMounted "$RESTORE_DEVICE"; then
    writeToConsole $MSG_LEVEL_MINIMAL $MSG_RESTORE_DEVICE_MOUNTED "$RESTORE_DEVICE"
    exitError $RC_MISC_ERROR
    fi
    Zitieren
    #358 Stephan 2021-01-07 19:06
    hallo framp,
    funktioniert nicht .... es kommt leider folgende Fehlermeldung
    Zitat:
    ??? RBK0154E: Ein Restore ist nicht möglich wenn eine Partition von /dev/sda gemounted ist.
    Habe die Parameter -g -0 -d vewendet. muss aber mit sda3 mounten, da dort ja die Sicherung ist. Gibt es eine andere Möglichkeit ?
    Gruß Stephan
    Zitieren
    #357 framp 2021-01-07 18:54
    Verstehe. Dann ist es auch nicht schlimm wenn doch was schiefegehen sollte. Glaube ich zwar nicht ... aber Du weisst ja :-*
    Zitieren
    #356 Stephan 2021-01-07 18:24
    zitiere framp:

    Ich habe Dein ungewoehnliches Szenario nicht getestet denn ein Backup sollte auf einem anderen Medium abgelegt werden als das System. Es sollte aber funktionieren. Trotzdem rate ich Dir die dritte Partition noch irgendwo zur Sicherheit extern zu sichern. Der Teuffel ist ein Eichhoernchen :cry:

    Cu framp


    Hallo framp,
    das Backup geht eben auf der SSD wesentlich schneller als ich das über das Netzwerk schick, und die Dienste auf de raspi stehen dan wieder zur Verfügung. Nach dem Backup kopiere ich die Backups dann über das Netzwerk auf eine sichere Store.
    Gruß Stephan
    Zitieren
    #355 framp 2021-01-07 17:44
    Moin Stephan,

    mit der Option -0 wird bewirkt dass die existierende Partitionierung genutzt wird und somit auch Deine 3te Partition nicht geloescht wird. --resizeRootFS funktioniert nur wenn nicht die Option -0 benutzt wird. Die Option -d musst Du angeben denn damit wird angegeben wohin zu Restoren ist.

    Ich habe Dein ungewoehnliches Szenario nicht getestet denn ein Backup sollte auf einem anderen Medium abgelegt werden als das System. Es sollte aber funktionieren. Trotzdem rate ich Dir die dritte Partition noch irgendwo zur Sicherheit extern zu sichern. Der Teuffel ist ein Eichhoernchen :cry:

    Cu framp
    Zitieren
    #354 Stephan 2021-01-07 15:23
    Hallo framp,
    habe ein Raspi mit SSD vo der ich auch boote.
    auf der 3.Partition habe ich die Backups liegen.
    • sda1 /boot
      sda2 /root
      sda3 /store als (/media/store gemountet)

    Nun möchte ich das letzte rsync Backup auf sda3 gezielt in die sda1 und sda2 restoren.

    sudo RaspiBackup.sh --resizeRootFS- -0 /dev/sda /media/store/raspberrypi .......
    den Parameter -d darf ich ja nicht benutzen, da ansonsten die komplette SSD (also auch die Sicherungen aud sda3) gelöscht werden.
    Ist der Parameter --resizeRoorFS- überhaupt notwendig, wenn der Parameter -0 angegeben ist ?
    Wäre schön, wenn kurzfristig geholfen wird.... :-)
    Gruß
    Stephan
    ist dies so richtig ?
    Zitieren
    #353 framp 2020-12-07 21:16
    Moin Gunther,

    vielen Dank dass Du die Beta testest. Leider hilft mir die Fehlermeldung nicht viel. Ich benoetige das Debuglog vom Backup und Restore. Entweder stellst Du das irgendwo ins Netz und schreibst hier die URL oder Du schickst mir die Logs per eMail. Die eMail findest Du auf der Kontaktseite :-)

    CU framp
    Zitieren
    #352 Gunther 2020-12-07 20:29
    Hallo framp,
    ich hab die Version 0.6.6 auf dem Raspi. Backup funktioniert hervorragend. Jetzt wollte ich zum Testen ein restore machen. Befehl und Fehlermeldung sehen so aus.
    sudo raspiBackup.sh -d /dev/sdb /media/usb-platte/backup_raspi/raspberrypi-dd-backup-20201206-023001
    /usr/local/bin/raspiBackup.sh: Zeile 1318: ((: 0
    Zitieren
    #351 framp 2020-11-28 11:42
    Moin Mike,

    ein Restore auf ein laufendes System geht nicht bzw liefert unberechenbare Ergebnisse :cry: .

    Du musst an eine Raspberry einen USB SD Kartenleser einstecken und dort eine SD Karte einstecken auf die dann restored wird :-)

    Cu framp
    Zitieren
    #350 Mike 2020-11-28 11:24
    Moin zusammen,

    ich erstelle mittels raspiBackup ein rsync Backup auf meine Synology. Und das funktioniert prima.
    Aber ich stehe auf dem Schlach, wie der Restore funktioniert.
    Kann ich mit der laufenden/bestehenden SD Karte direkt ein Restore starten (auf sich selbst als Ziel)?
    Beim Pi kann ich ja keine zweite Karte installieren?
    Zitieren
    #349 framp 2020-10-26 19:31
    Moin Wolfgang,

    es sieht mir so aus als wenn bei Dir irgendwas von /dev/sda2 benutzt wird. Mit

    lsof | grep /dev/sda2

    solltest Du sehen wer oder was noch /dev/sda2 benutzt.

    Cu framp
    Zitieren
    #348 Wolfgang 2020-10-25 22:06
    Hallo framp,

    vielen Dank für Deinen Tip. sda1 ist über /boot gemounted, sda2 über /. Wenn ich sudo umount /dev/sda2 ausführe, erscheint: target is busy, wenn ich dasselbe mit sda1 mache, findet Raspi die Befehle nicht mehr. Möglicherweise hängt das mit meinem Umzug auf USB Platte (USB Boot Mode) ohne SD Karte zusammen. Alle meine Versuche zur gewaltsamen Entfernung der Mounts führen zum Kollaps.

    Dein Vorschlag in Kommentar #309 zum Umzug der root-Partition auf USB-SSD mit dem Erhalt der SD-Karte als Bootpartition im System habe ich studiert. Ich wäre aber gerne die SD-Karte los. Siehst Du noch eine Möglichkeit, meinen jetzigen USB Boot Mode für raspiBackup zu retten?
    Gruß
    Wolfgang
    Zitieren
    #347 framp 2020-10-19 18:09
    Moin Wolfgang,

    der Restore Befehl ist schon richtig. Das Problem ist dass eine oder sogar beide Partitionen von /dev/sda bei Dir gemounted ist. Das fuehrt zu Fehlern beim Restore. Du musst einfach nur
    sudo umount /dev/sda{1,2}
    vor dem Restore ausfuehren um alle Partitionen von /dev/sda zu umounten ;-) Dann wird der Restore durchlaufen.

    Cu framp

    PS: Ich lebe nicht an der Kueste. Man sagt Moin auch weiter suedlich :lol: .
    Zitieren
    #346 Wolfgang 2020-10-19 17:48
    Hallo Framp,
    vielen Dank für Deine Antwort. Deine Begrüßung "Moin" lässt mir das Herz aufgehen, weil ich viele Urlaube an der Nordsee verbracht habe. Wohltuende Laute in schlimmen Zeiten!

    Ich habe für den Restorebefehl
    sudo.raspiBackup.sh -d /dev/sda /media/usb/raspberrypi/....weiterer backupPfad
    benutzt. Kam Fehlermeldung:
    Ein Restore ist nicht möglich wenn eine Partition von /dev/sda gemounted ist. Restore wurde fehlerhaft mit RC 102 beendet.
    Habe noch nicht begriffen, wie der Restoremechanismus geht! Auf Disk sda befinden sich die Partitionen sda1 (Boot) und sda2 (root), auf Disk2 sdb befindet sich sdb1 über den Mount /media/usb die BackupDatei. Nur diese beiden Partitionen - so meine ich - sind im Backup gesichert und müssen wieder zurück nach sda.

    Muss ich das Restore mit -d getrennt machen, also
    ... -d /dev/sda1 ... und dann im zweiten Durchgang
    ...-d /dev/sda2 ....?
    Oder müssen sda1 und sda2 in einen Befehl gepackt werden, aber wie? Am backupPfad kann es doch nicht liegen!
    Bitte nochmals um Deine Hilfe.
    Gruß
    Wolfgang
    Zitieren
    #345 framp 2020-10-14 22:27
    Moin Wolfgang,

    Du benutzt den USB Boot Modus wo keine SD Karte mehr benutzt wird. Dann musst Du die Option -R bei USB Boot Mode nicht benutzen. Es reicht

    raspiBackup -d /dev/sdaX backupPfad

    anzugeben wobei /dev/sdaX das USB Geraet ist auf dem Du Deinen Backup restoren willst.

    Durch Deinen Kommentar habe ich gesehen dass auf der Restoreseite ein Beispiel fuer den Fall fuer den USB Mode fehlt. Das werde ich gleich ergaenzen :-)

    Cu framp
    Zitieren
    #344 Wolfgang 2020-10-14 22:19
    Hallo Framp

    mit Hilfe Deiner ausgezeichneten Arbeit zum Thema RaspiBackup - und nach der verlustreichen Überwältigung meiner Windows-Denke - habe ich es geschaftt, meinen Raspi etwas umzubauen und eine komplettes rsync-Backup zu erstellen und zu speichern. Kompliment an Dich für diese tolle Vorlage.

    Nun kannst Du bezüglich der Hinweise für das Restore eines bestehenden Backups nicht jede denkbare Konstallation abbilden. Weil das so ist würde ich Dich gerne fragen, wie der Restorebefehl für mein System aussehen soll:

    pi@raspberrypi:~ $ lsblk
    NAME MM M SIZE RO TYPE MOUNT POINT
    sda 8:0 0 232,9G 0 disk
    ├─sda1 8:1 0 256M 0 part /boot
    └─sda2 8:2 0 232,6G 0 part / ist wohl root
    sdb 8:16 0 223,6G 0 disk
    └─sdb1 8:17 0 223,6G 0 part /media/usb hier ist RaspiBackup

    Gebootet wird von einer USB-SSD (sda), eine zweite USB-SSD (sdb) dient als Speichermedium. In dieser Konstellation habe ich das Backup erstellt. Beide SSD's sind wegen der Rückübertragung der Rechte in ext4 formatiert. Es gibt keine SD-Karte mehr. Mein Problem ist/sind die Funktion/en des/der Parameter im Restore-Befehl:

    sudo raspiBackup.sh xxxParameterxxx /Pfad für das Backup

    Aus Deiner Tabelle "Parameter/Funktion/Standard" geht hervor, dass das Ausgabedevice -R als Option für Systeme mit einer externen Rootpartition steht.

    Ich bin mir aber nicht sicher, wie der Parameterteil ausformuliert werden muss, damit Bootpartition, Partitionslayout und Masterbootrecord wieder an den richtigen Stellen landen.

    Ich würde mich sehr freuen, wenn Du mir einen Hinweis geben könntest.

    Gruß
    Wolfgang
    Zitieren
    #343 Kelley 2020-09-14 23:57
    Thanks for finally writing about >Restore
    Zitieren
    #342 Flo 2020-04-24 14:37
    Alles klar, dann weiß ich Bescheid.
    Danke für die Hilfe und ein schönes Wochenende noch.
    Zitieren