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

  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.

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

 

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

Kommentare sind erwünscht. Aber um lästige Spamposts automatisch abzuweisen gibt es ein paar Dinge die zu beachten sind:
  1. Kommentare werden manuell überprüft und deshalb dauert es in der Regel einen Tag bis sie veröffentlicht werden.
  2. Kommentare mit dem Text http werden zurückgewiesen mit der Meldung Sie sind nicht berechtigt den Tag zu verwenden.
  3. Es muss mindestens eine Stunde zwischen weiteren Kommentaren gewartet werden.

Kommentare   
#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
#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