testen des restores von raspiBackp

    Hallo, ich möchte den Restore aus einem Backup , den ich mit raspiBackup.sh erstellt habe testen.

    Ich habe normalerweise keine SD Karte im Karetnleser sondern ich boote meinen raspberrypi von einer USB Platte mit root auf /dev/sda2 und /boot/firmware auf /dev/sda1. Ich habe eben ein Backup erstellt und möchte jetzt das Restore testen

    Kann ich das Backup aus dem laufenden System mit

    Code
    sudo raspiBackup.sh -d /dev/sda /backup/raspberrypi-rsync-backup-20251002-155513/

    starten. Ich starte raspiBackup von "/usr/local/bin/raspiBackup.sh". Bei diesem Kommando würde raspiBackup doch die aktuell gemountete root Partition überschreiben. Wie kann raspBackup die aktuell gemountete root Partition überschreiben ?

    Ich habe nur einen raspberryPi. Muss ich erste eine SD Karten einlegen und von der Booten. Und dann von der den Restore Job mit dem Ziele "externe USB Platte" starten ? Dann auf die als /dev/sdx gemountete USB Platte als Backup-Ziel angeben ? Wird dabei die root Partition auf der USB Platte wieder hergestellt, so dass ich wieder von der booten kann ? Anschließend SD Karte wieder raus und von der USB Platte booten ?

    Quote from peterwalber

    Wie kann raspBackup die aktuell gemountete root Partition überschreiben ?

    raspiBackup prüft ob Du Dein laufendes System überschreiben würdest. Das wird unterbunden da es Dein System zerstören würde.

    Du kannst von Deinem laufenden System Dein Backup restoren - aber Du musst dafür eine weitere USB Platte oder USB Stick anschliessen. Die wird dann vermutlich /dev/sdb heissen. Dann gibst Du mit der Option -d /dev/sdb beim Restore an. Nachdem der Restore endet fährst Du Dein System runter und klemmst Dein Originalsystem auf /dev/sda ab. Danach startest Du Dein System wieder und dann wird es von Deinem restorten System booten. Dann kannst Du Deine Anwendungen testen ob alles OK ist. Zum Schluss wieder Deine OriginalPlatte anschliessen und die zweite Platte oder Stick wieder abklemmen.

    Das restore hat leider nicht geklappt. Ich habe einen 128 GByte SANDisk USB Stick gekauft. Der hat auch diese Größe. Den habe ich eingesteckt und dann habe ich den Restore mit

    sudo raspiBackup.sh -d /dev/sdb /backup/Backup_20251002....

    gestartet.

    Die Bootpartiton (/dev/sdb1) konnte wohl noch erstellt werden. Bei der root Partition gab es aber den Fehler exitError117 . Was bedeutet das ? Und vorher ein Fehler "rsync --delete-v unkown option"


    20251016-180601 MSG 5979:                  --- RBK0055I: Zweite Partition (Rootpartition) wird auf /dev/sdb2 zurückgespielt.  
    20251016-180601 DBG 8170:                  --> mountAndCheck /dev/sdb2 - /tmp/raspiBackup 
    20251016-180601 DBG 3735:                      --> isMounted /tmp/raspiBackup 
    20251016-180601 DBG 3743:                      <-- isMounted 1 
    20251016-180601 DBG 8187:                          *** findmnt /tmp/raspiBackup 
    20251016-180601 DBG 8187:                              TARGET           SOURCE    FSTYPE OPTIONS 
    20251016-180601 DBG 8187:                              /tmp/raspiBackup /dev/sdb2 ext4   rw,relatime 
    20251016-180601 DBG 8188:                  <-- mountAndCheck 0 
    20251016-180601 DBG 6003:                  --- Excluding excludePattern 
    20251016-180601 DBG 2574:                  --> executeRsync  
    20251016-180601 DBG 2577:                      --- rsync  --numeric-ids -aHAPx --delete-v  --exclude=/@HOSTNAME@-backup.* "/backup/@HOSTNAME@/@HOSTNAME@-rsync- 
    backup-20251002-161754/" /tmp/raspiBackup 
    rsync: --delete-v: unknown option
    rsync error: syntax or usage error (code 1) at main.c(1795) [client=3.2.7] 
    20251016-180601 DBG 2544:                      --> ignoreErrorRC  
    20251016-180601 DBG 2555:                      <-- ignoreErrorRC 1 
    20251016-180601 DBG 2581:                  <-- executeRsync 1 
    20251016-180602 MSG 6016:                  ??? RBK0035E: Backupprogramm rsync endete beim Restore mit RC 1.  
    20251016-180602 DBG 2531:                  --> exitError 117
    20251016-180602 DBG 2538:                  <-- exitError 117
    20251016-180602 DBG 4771:                  --> cleanup  
    20251016-180602 MSG 4782:                      --- RBK0033I: Bitte warten bis aufgeräumt wurde.  
    20251016-180602 DBG 4919:                      --> cleanupRestore  
    20251016-180602 DBG 4923:                          --- Got trap EXIT 
    20251016-180602 DBG 4924:                          --- rc: 117 
    20251016-180602 DBG 2230:                          --> callExtensions post 
    20251016-180602 DBG 2302:                          <-- callExtensions  
    20251016-180602 DBG 3735:                          --> isMounted /tmp/raspiBackup 
    20251016-180602 DBG 3743:                          <-- isMounted 0 
    20251016-180602 DBG 4934:                          --- Umount /tmp/raspiBackup 
    20251016-180602 DBG 4938:                          --- Deleting dir /tmp/raspiBackup 
    20251016-180602 DBG 3735:                          --> isMounted /dev/sdb1 
    20251016-180602 DBG 3743:                          <-- isMounted 1

    --delete-v ist eine ungültige rsync Option. Die Frage ist wie das passiert ist. Leider hast Du das Restore Debuglog nicht beigefügt. Das liefert mir wesentlich mehr Informationen als Dein kleiner Debugausschnitt. Ohne das Debuglog kann ich leider nicht weiterhelfen :nosmile:

    Quote from __blackjack__

    Einzeln gibt es die ja.

    Ja. Ein Leerzeichen dazwischen würde das Problem schon lösen. Ich habe im Code nachgesehen und da sieht es OK aus. jetzt sehe ich mal im Log nach.

    --- RBK0009I: @HOSTNAME@: raspiBackup.sh V0.6.9 - 2023-11-21 (6638571) Do 16. Okt 18:03:37 CEST 2025 gestartet. 

    Ich kann mich düster daran erinnern dass es mal ein Problem mit dem -v gab. Deshalb gab es dann offensichtlich die Version 0.6.9.1 die das fixte.

    peterwalber Ich habe keine Ahnung wo Du diese alte raspiBackup Version hochgezogen hast. Nutzt Du diese auch zum Erstellen des Backups :shy: Mittlerweile ist die aktuelle raspiBackup Version 0.7.1.1 :cool:

    ich habe raspiBackup in 11 / 2023 auf dem offiziellen Weg installiert. Ja, mit dieser habe ich auch den Backup erzeugt. Wenn ich raspiBackup jetzt update, kann ich mit der neuen Version auch das Backup, das ich mit der Version V0.6.9 - 2023-11-21 erzeugt habe, restoren ? Soll ich mit

    sudo raspiBackupInstallUI.sh

    auf die neue Version updaten ?

    Edited once, last by peterwalber (October 16, 2025 at 8:03 PM).

    Ich teste viel mit raspiBackup - aber Backwardcompatibility zu testen für jede alte Release wäre mein Testtod.

    Im Prinzip solltest Du Dein 0.6.9 Backup auch mit 0.7.1.1 restoren können. Getestet ist das aber nicht.

    Ist es wirklich nur ein Test oder brauchst Du den Backup um Dein altes System zu restoren? Ich frage deshalb weil ein Du offensichtlich bislang keinen Restoretest durchgeführt hast und das Backup sehr aktuell ist.

    Wenn es ein Test ist würde ich Dich bitten zu Upgraden und zu testen on der Restore dann funktioniert. Wenn Du Dein altes System restoren willst kann ich Dir einen Fix zur Verfügung stellen denn Du willst sicherlich nicht lange rumprobieren. Aber danach bitte ich Dich trotzdem mit der aktuellen Version den Restore zu testen :wink1:

    es ist aktuell ein Test, ob ich mein System von dem Backup auch restoren kann. Gerne teste ich für Dich, ob ich das mit der alten Version erzeugte Backup mit einer raspBackup Version 0.7.1.1 auch restoren kann. Wenn das funktioniert, ist es doch in Ordnung.

    Wenn das nicht geht, erstelle ich ein neues Backup mit version 0.7.1.1. und versuche damit zu restoren

    Ok. Dann upgrade mal und teste den Restore. Wenn er failed kannst Du ja mit Option -V wieder die 0.6.9 aktivieren. Dann baue ich Dir einen Fix auf 0.6.9.

    Es gibt aber noch eine Alternative: Du setzt einfach in der Konfigurationsdatei DEFAULT_VERBOSE=0 oder rufst den Restore mit der zusätzlichen Option -v- auf. Ohne den verbose Modus wird der Restore auch mit 0.6.9 funktionieren.

    es scheint nicht zu funktionieren. Es läuft gut los, aber nach einiger Zeit (immer erst beim restore des root filesystems auf /dev/sdb2 mit rsync) kommt es zu folgendem Fehler


    20251016-221052 DBG 2752:                  --> executeRsync  
    20251016-221052 DBG 2755:                      --- rsync  --numeric-ids -aHAx --delete --force --sparse -v  --exclude=/@HOSTNAME@-backup.* "/backup/@HOSTNAME@/ 
    @HOSTNAME@-rsync-backup-20251002-161754/" /mnt/raspiBackup 
    rsync: [receiver] write failed on "/mnt/raspiBackup/home/@USER@/.thunderbird/rw1ixgmj.default-release-1/Mail/Local Folders/reisen.sbd/Urlaub 2010.msf": Input/o 
    utput error (5) 
    rsync error: error in file IO (code 11) at receiver.c(381) [receiver=3.2.7] 
    rsync: [sender] write error: Broken pipe (32) 
    20251016-221530 DBG 2720:                      --> ignoreErrorRC  
    20251016-221530 DBG 2733:                      <-- ignoreErrorRC 11 
    20251016-221530 DBG 2759:                  <-- executeRsync 11 
    20251016-221530 MSG 6810:                  ??? RBK0035E: Backupprogramm rsync endete beim Restore mit RC 11  
    20251016-221530 DBG 2707:                  --> exitError 117 
    20251016-221530 DBG 2714:                  <-- exitError 117

    nicht immer bei der gleichen Datei, aber immer dieser Fehler. Aber ich bin nicht sicher, ob das an den unterschiedlichen Versionen (Backup mit 0.6.9,restore mit 0.7.1.1) liegen kann. Ich versuche, einen Backup mit 0.7.1.1 zu erstellen.

    Ja. Das funktioniert perfekt mit dem tmp Verzeichnis. Die Hardlinks bleiben erhalten.

    Leider hast Du hast das erste Debuglog noch mal angehängt. Anyhow - die Fehlermeldung ist eindeutig und ein Lese-/Schreibfehler vom rsync. D.h. der Fehler von 0.6.9 ist jetzt weg.

    ich vermute Dein Restoredevice ist nicht OK (write failed). Auch kann es sein dass Dein SD Adapter nicht OK ist oder auch die Stromversorgung in die Knie geht. Jedenfalls liegt die Ursache irgendwo in der HW und nicht in raspiBackup.

    Ich würde an Deiner Stelle checken dass Du ein Original Netzteil nutzt und somit kein Spannungsproblem hast und dann auf eine andere SD Karte restoren.

    Es kam bislang keine Rückmeldung von Dir. Ich denke nicht nur ich bin sehr daran interessiert ob Du einen Restore hinbekommen hast :shy:

    Sehr merkwürdig :conf: Dass beim restore rebootet wird ist mir bislang noch nicht untergekommen.

    Zeige mal ein aktuelles Log vom Restore. Vielleicht finde ich noch eine weiter Indikation. Vielleicht nutzt Du auch mal die Option -v und beobachtest bei welcher Datei, die restored wird, ein Reboot stattfindet. Vielleicht ist das immer dieselbe?

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login