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

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.

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.

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 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   
    #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
    #341 framp 2020-04-24 13:30
    Moin Flo,

    Antwort kurz und knapp: Nein. Ein rsync Backup reicht.

    Warum?

    Es gab schon mal jemanden der hat danach gefragt. Es gibt eine kleine Diskussion und Erklaerungen meinerseits dazu in dem Kommentar HTTPS://www.linux-tips-and-tricks.de/de/raspibackup/#comment-3287 ff. Lies Dir das bitte mal durch :-)

    Cu framp
    Zitieren
    #340 Flo 2020-04-24 12:27
    Alles gut. ;)

    Ja, werde den Restoretest vll vierteljährlich oder alle zwei Monate mal machen, mal schauen. Den initialen Restoretest hab ich schon gemacht.

    Um nochmal auf meine Frage zurückzukommen: Muss ich jetzt beim rsync Backup alle inkrementellen Backups wiederherstellen oder reicht das letzte? Wenn ich immer nur die Änderungen sichere, gehen mir ja Daten verloren, wenn ich nur das letzte Backup wiederherstelle, oder nicht?
    Zitieren
    #339 framp 2020-04-24 11:23
    zitiere Flo:
    ...Ja, ich benutze rsync (siehe mein erster Post). Deswegen auch die Frage mit dem Backup, ob ich, wenn ich mehrere Backups vorhalte, alle restoren muss, um ein Klon der SD Karte im Pi zu erhalten...


    Hatte ich nicht mehr im Kopf. Bei so vielen Anfragen verliert man schon mal den Ueberblick und jedesmal den ganzen Thread wieder zu lesen ist mir zu aufwaendig :-*

    Aber dann bist Du ja bestens gewappnet gegen eventuelle Ausfaelle - auch wg der USV.

    Nur nicht vergessen immer mal wieder einen Restoretest durchzufuehren. Ab der raspiBackup Version 0.6.5 die demnaechst publiziert wird wirst Du auch immer regelmaessig daran erinnert :-)

    Cu framp
    Zitieren
    #338 Flo 2020-04-24 11:03
    Ja, ist es. Und den Pi sichere ich mit insgesamt zwei USVs (eine große APC und ein StromPi mit Battery Hat) gegen einen plötzlichen Stromausfall ab. Also bis am Pi wirklich die Lichter ausgehen, muss schon bissl was passieren und dann hab ich glaub ich andere Probleme.

    Ja, ich benutze rsync (siehe mein erster Post). Deswegen auch die Frage mit dem Backup, ob ich, wenn ich mehrere Backups vorhalte, alle restoren muss, um ein Klon der SD Karte im Pi zu erhalten.
    Zitieren
    #337 framp 2020-04-24 09:17
    Moin Flo,

    das ist gut dass die Wetterstation die Daten puffert. Um die Backupzeit klein zu halten solltest Du rsync benutzen. Das ist bis auf das erste mal ja immer ein inkrementeller Vollbackup ;-)

    Cu framp
    Zitieren
    #336 Flo 2020-04-24 07:45
    Ehrlich gesagt hab ich kein Problem damit, z.B. einmal im Monat einen Restore zu machen, so zeitintensiv ist das nicht. Falls es mich auf Dauer doch stört, werde ich das evtl angehen.

    Meine Wetterstation besteht aus einem Außenmodul und einer Basis, die per USB an den Pi angeschlossen ist. Der Pi frägt dann alle 30 Minuten die Basis ab, ob sie neue Einträge hat und wenn ja, überträgt er sie in die Datenbank und erstellt die entsprechenden Graphen. Jetzt ist es Gott sei Dank so, dass die Basis auch einen internen Speicher hat, in dem die Messwerte über mehrere Wochen (mind. 4 Wochen) gespeichert werden. Das heißt, solange die Basis Strom hat, verliere ich keine Daten, die Messwerte werden nur nicht auf der Webseite dargestellt. Im Katastrophenfall mach ich also zuerst den Restore von RaspiBackup, dann tausche ich die SD Karten, dann stelle ich das Backup der Wetterstation wieder her (
    Zitieren
    #335 framp 2020-04-23 23:39
    Moin Flo,

    das was Du Dir vorstellst kannst Du mit raspiBackup recht schnell erreichen. Allerdings musst Du dazu ein wenig bash Code schreiben. Entweder arbeitest Du Dich mal in bash Scripting ein oder Du kennst jemanden der sich damit auskennt und Dir hilft. Wenn Du Dich ein wenig in bash Scripting eingelesen hast wird Dir sicherlich auch im Raspberry Forum geholfen werden -> HTTPS://forum-raspberrypi.de/forum/

    Wie Du waehrend der Downtime keine Wetterdaten verlieren willst verstehe ich nicht. Raspi down - keine Wetterdaten mehr :sad:

    Cu framp
    Zitieren
    #334 Flo 2020-04-23 22:20
    Also unbedingt muss das Image nicht komprimiert werden, bei 2,5 GB ist das für mich nicht so entscheidend. :D

    Das Mounten und Unmounten des Backup Pfades des raspiBackupWrapper Skripts brauche ich hoffentlich nicht, hab mir dafür autofs eingerichtet. Leider konnte ich es noch nicht mit raspiBackup testen, aber vll komme ich am Wochenende dazu.

    Da ich leider keine Ahnung habe, wie ich so ein Skript schreiben würde, werde ich das erst mal lassen. Der Restoreprozess dauert wie gesagt ja auch nicht lange und im Katastrophenfall verliere ich dadurch nicht allzu viel Zeit. Und im besten Fall verliere ich durch die Downtime nicht einmal Daten an der Wetterstation, was auch sehr wichtig ist.

    Ich kann formulieren, was so ein Skript für mich können müsste, aber selber kann ich sowas nicht erstellen. Meine Anforderungen wären:

    -Erstellen eines Images auf Basis des raspiBackupRestore2image.sh in einen von mir konfigurierbaren Ordner mit einem gleichbleibenden, definierten Namen (wenn möglich ohne pishrink)
    -Restore des Backups auf einer SD Karte auf einem entfernten Server
    -Löschen des lokalen Images nach erfolgreichem Abschluss (ggf. mit E-Mail Benachrichtigung zum erfolgreichen Abschluss des Restoreprozesses)
    Zitieren
    #333 framp 2020-04-23 21:46
    Moin Flo,

    ich habe gerade mal genauer nachgesehen und festgestellt das das Script auch pishrink aufruft um das Image minimal zu machen. Weiss nicht ob das in Deinem Sinne ist.

    Jedenfalls schreibt raspiBackup in eine Datei rein wo das Backup erstellt wurde. In raspiBackupWrapper findest Du den entsprechenden Code:

    Code:
    function readVars() {
    if [[ -f /tmp/raspiBackup.vars ]]; then
    source /tmp/raspiBackup.vars # retrieve some variables from raspiBackup for further processing
    # now following variables are available for further backup processing
    # BACKUP_TARGETDIR refers to the backupdirectory just created
    # BACKUP_TARGETFILE refers to the dd backup file just created
    else
    echo "/tmp/raspiBackup.vars not found"
    exit 42
    fi
    }


    Vermutlich ist es besser Du benutzt eines der Wrapperscripts als template und baust Dir Dein eigenes Script zusammen :-)

    Cu framp
    Zitieren
    #332 Flo 2020-04-23 20:38
    Jetzt musst du mir nochmal helfen.

    Mit dem raspiBackupRestore2Image.sh Skript erzeuge ich neben dem Backup ein Image des Pis, das ich auf meiner zweiten SD Karte wiederherstellen soll. Wenn ich dich richtig verstanden habe, soll ich dazu einen dd Befehl am Ende des raspiBackupRestore2Image.sh Skripts einfügen, der so aussehen könnte:

    dd if=/pfad/zum/image/Image Filename | ssh benutzer@IP_des_OMV_Servers "cat > /dev/sdX"

    Das X in sdX steht für den Laufwerksbuchstaben meiner SD Karte im OMV Server.

    Jetzt würde ich gerne nur noch wissen, unter welchem Pfad das Image zu finden ist und wie der korrekte Ausdruck für Image Filename ist. Kurzum: Wie sieht das if des dd Befehls aus?

    Ist das so korrekt oder hab ich was übersehen?
    Zitieren
    #331 framp 2020-04-23 19:25
    Ok. Ich glaube jetzt habe ich verstanden was Du willst.

    Da weise ich Dich noch mal auf raspiBackupRestore2Image.sh hin. Damit wird automatisch beim Backup ein Restore in eine Image Datei gemacht. Du muesstest dann nur noch dieses Image in einerm angepassten raspiBackupRestore2Image.sh am Ende auf Deine zweite Backup SD Karte kopieren ;-)

    Cu framp
    Zitieren
    #330 Flo 2020-04-23 19:08
    Ok, ich versuchs nochmal zu erklären, was meine Idee war:

    Mein Plan wäre es gewesen, dass der Pi mit raspiBackup einmal in der Woche ein Vollbackup von sich selbst auf dem NanoPi M4 mit OMV erstellt und OMV nach 2-3 Stunden von sich aus das neu erstellte Backup auf einer zweiten Backup SD Karte, die im OMV Server permanent steckt, wiederherstellt. Somit hätte ich vollautomatisch ein aktuelles Klon meiner SD Karte vom Pi und müsste bei einem Ausfall der SD Karte im Pi nur die zweite SD Karte aus dem OMV Server in den Pi stecken.

    Der Unterschied zu jetzt ist, dass ich den Restoreprozess manuell machen muss, was natürlich auch kein Problem ist. Ich werde mir dazu vermutlich eine Notiz mit dem Befehl an einem geeigneten Ort hinterlegen, dann muss ich den Befehl nicht erst wieder nachschauen. ;)

    Und nein, mir ist der Befehl auf keinen Fall zu lang, das passt alles. :)

    Ich hoffe, es ist jetzt deutlicher geworden, was ich machen möcht. ;)
    Zitieren
    #329 framp 2020-04-23 18:19
    Moin Flo,

    irgendwie habe ich Dich wohl immer noch nicht richtig verstanden. cron benutzt Du um regelmaessig was zu tun. Du willst doch nichtregelmaessig restoren.

    Wenn Dir die Optionen fuer den Restore mit raspiBackup zu lang sind (so viele sind es doch nicht... ) kannst Du einen Comman Alias erstellen oder auch ein kleines bash Script schreiben in dem der Aufruf mit entsprechenden Optionen stattfindet.

    Cu framp
    Zitieren
    #328 Flo 2020-04-23 18:07
    Servus Framp,

    Ok, gut zu wissen. Dann werde ich auf jeden Fall mehrere Backups vorhalten, bei einer derzeitigen Backupgröße von 2,5 GB ist das nicht so speicherlastig.

    Zu 2. Mir ging es ehrlich gesagt rein um die Automatisierung des Restoreprozesses, aber wenn das nicht geht, kann ich damit auch leben. Aktuell dauert der Restoreprozess 20-25 Minuten, das ist absolut im Rahmen. Ich habe mich nur gefragt, ob es möglich wäre, die Wiederherstellung durch Eintragung eines Befehls in die Crontab zu automatisieren, aber wenn das nicht geht, muss ich das Backup eben manuell wiederherstellen.

    Grüße
    Flo
    Zitieren
    #327 framp 2020-04-22 22:27
    Moin Flo,

    zu Frage 1: Ein Backup ist ein Full Backup des Systems. Du brauchst also zum Restore nur ein Backup. Du scheinst im Hinterkopf Deltabackups zu haben. D.h. wenn Du im Backupfall nur das letze erstellte Backup brauchst reicht 1 Backup. Ich wuerde aber immer mehrere vorhalten. Lieber etwas mehr als zu wenig :-)

    zu Frage 2: Wie man den Restore zu automatisieren kann hat bislang noch niemand gefragt. Ehrlich gesagt ist das auch fuer mich ein einmaliger Vorgang. Was ich mir aber vorstellen kann was Du im Hinterkopf hast ist ein tar oder rsync Backup zu erstellen und davon ein dd Backup welches Du per Windows restoren kannst zu erstellen. Ist meiner Meinung nach Overkill aber das geht :-)

    Gehe mal auf HTTPS://github.com/framps/raspiBackup/tree/master/helper und siehe Dir raspiBackupRestore2Image.sh an :-)

    Cu framp
    Zitieren
    #326 Flo 2020-04-22 22:08
    Hallo Framp,

    vielen Dank für dieses coole Tool, es gefällt mir ehrlich gesagt richtig gut. Vor allem die breite Anwendbarkeit was unterschiedliche Backupmethoden, Backupziele und Quellsysteme angeht, haben es mir angetan und ich bin gespannt, was ich damit noch alles machen kann.

    Kurz zu meinem bisherigen Einsatzszenario:
    Ein Raspberry 3B mit weewx (Software für meine Wetterstation) und div. Sicherheitssoftware sichert per rsync auf ein gemountetes NFS Laufwerk eines Openmediavault Servers (Hardware: NanoPi M4 + eMMC + SATA hat + Crucial MX500 SSD; Falls gewünscht, kann ich zu der Einrichtung des OMV Servers auch ein paar Zeilen schreiben). Der Restore erfolgt unter OMV auf eine SD Karte, die in einem USB 3.0 Adapter steckt.

    Mein Ziel ist es, dass der Pi einmal in der Woche ein Backup von sich selbst auf den OMV Server erstellt und der das Backup dann auf die SD Karte wiederherstellt. Somit hätte ich quasi jede Woche ein aktuelles Klon der SD Karte und müsste bei einem Ausfall der primären SD Karte nur die Backup SD Karte in den Pi stecken.

    Jetzt endlich zu meinen Fragen:

    1. Am einfachsten ist das ganze natürlich, wenn ich die Anzahl vorzuhaltender Backups auf 1 stelle, weil ich dann nur ein Backup restoren muss. Wenn ich aber einstelle, dass zwei Backups vorgehalten werden sollen, muss ich ja auch beide Backups restoren, um ein komplettes Klon der SD Karte zu erhalten, richtig? Oder übersehe ich da was?

    2. Gibt es eine Möglichkeit den Restore Prozess zu automatisieren? Im Aufruf des Skripts muss man ja den Pfad angeben, in dem das Image liegt, aber dieser Pfad ändert sich ja immer mit dem Datum. Gibt es eine Möglichkeit, den Befehl zum Restore so zu gestalten, dass immer automatisch das aktuellste Image im Backup Ordner genommen wird?

    Ich hoffe, es ist klar, was ich meine, ansonsten stehe ich natürlich gerne für Rückfragen zur Verfügung.

    Vielen Dank schon mal für die Hilfel!

    Viele Grüße
    Flo
    Zitieren
    #325 framps 2020-01-20 20:12
    Moin Felix,

    Zitat:
    Wie könnte ich es eleganter machen?
    So ganz verstehe ich Deine Frage nicht. Wenn Du ein Backup restorest wird es i.d.R. eine neue SD Karte sein auf die Du restorest. Auf ein laufendes System zu restoren ist vielleicht moeglich (Ich habe es nicht ausprobiert) aber das Ergebnis ist nicht deterministisch.

    Zitat:
    Mein Restore hat noch Fehler rsync: send_files failed to open
    Das bedeutet das root keinen Readzugriff auf die Backupdaten hat. Du musst die Sambaberechtigungen ueberpruefen.

    Cu framp
    Zitieren
    #324 Felix 2020-01-20 19:49
    Hi framp,

    Da war mein Denkfehler! Erst mounten, dann restoren. :-) Besten Dank.
    Wie könnte ich es eleganter machen? Wenn ich mir das Kistchen zerschieße habe ich ja i.d.R. kein laufendes System darauf, daher dieser Ansatz die SD Karte neu zu bespielen, Ich kann ja nicht auf einem laufenden System einen restore fahren?!

    Mein Restore hat noch Fehler rsync: send_files failed to open "..." Permission denied (13)
    Vermutlich weil Nutzer pi auf der Quelle ohne sudo arbeitet. Eine Idee, wie ich das sicher (!) lösen kann?

    Besten Dank & Gruß
    Zitieren
    #323 framp 2020-01-20 09:18
    Moin Felix,

    Du musst erst Dein Samba Laufwerk auf ein lokales Verzeichnis (z.B. /remote/raspberrybackups oder auch /mnt) mounten. Dann gibst Du diesen Pfad beim Restore an :-)

    Eigentlich ist raspiBackup dafuer gedacht auf einer raspBerry auch fuer den Restore ausgefuehrt zu werden. Aber es wird i.A. auch auf einem Linuxrechner funktionieren. Speziell Mint wird tun und ist getestet denn ich restore meine Backups auch auf meinem Mintrechner :lol:

    Cu framp
    Zitieren
    #322 Felix 2020-01-19 21:48
    Guten Abend,

    nach erfolgreichem Einrichten und Erzeugen der ersten Sicherungen über das Wochenende, steht nun ein Restoretest an.

    Die Sicherung möchte ich direkt von der am pi angeschlossenen externen Festplatte über eine Samba Freigabe auf die neue, leere SD Karte in meinem Rechner (Linux Mint) schreiben lassen. Wie mache ich das?

    Der Restorebefehl akzeptiert die Pfadangabe der Quelle mit smb:/// nicht. Wo ist mein Denkfehler? :-)

    Danke und Gruß,
    Felix
    Zitieren
    #321 framp 2019-12-14 15:24
    Moin Marco,

    nachdem ein aenhliches Feedback schon letztes Jahr kam habe ich das kleine Erdmaennchen (es ist kein Hund :-) ) deaktiviert. Aktivieren werde ich es aber wieder wenn ich den Code so geaendetr habe dass man ihn durch einen Klick stoppen bzw verschwinden lassen kann. Es ist mittlerweile Tradition auf dieser Webseite dass zur Weihnachtszeit ab dem 1. Advent bis zum 24.12.das kleine Erdmaennchen rumwackelt.

    Cu framp
    Zitieren
    #320 Marco 2019-12-14 13:48
    Hallo zusammen,
    ich finde eure Seite ja echt super.
    Aber es ist für mich kaum auszuhalten, dass mir ein Hund mit Schal immer wieder über den Text fliegt. Ich versuche mich zu konzentrieren, das Ding nervt einfach nur.
    Zitieren