raspiBackup - Wiederherstellen eines Backups

Details
Kategorie: raspiBackup
Auch verfügbar:  English (US) 
Zugriffe: 70242

Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv
 

raspiBackup kann erstellte Backups naürlich 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.

In der letzten Zeit bekomme ich immer wieder Issues in github weil der Restore abbricht. Ein Restore sollte immer mit demselben OS vorgenommen werden wie dem mit dem das Backup erstellt wurde. Oftmals kann ein jedes Linux OS genutzt um ein Backup zu restoren aber das kann dazu führen dass der Restore abbricht wenn die Linux Tools die zum Backup und Restore genutzt werden inkompatible Änderungen vorgenommen haben zu dem OS welches zum Restore genutzt wird. Aktuell gibt es eine inkompatible Änderung in sfdisk bei Bullseye zu den Vorgängerversionen. Deshalb lieber immer gleich dasselbe OS zum Restore nehmen!

 

 

raspiBackup - Wiederherstellen eines Backups

 

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 PARTUUIDs und LABELs des Originals restored. Dieses erzeugt i.d.R. Probleme wenn man das restorte System am Originalsystem mounted. Mit dieser Option werden neue PARTUUIDs beim restore 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 haben. Benutze 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   
    #456 framp 2023-11-30 18:25
    Moin Bernd,

    ab 0.6.7 gibt es einen Restoreextensionpoint. Dort wuerde ich es einbauen.

    Cu framp
    Zitieren
    #455 Bernd 2023-11-30 11:07
    Hallo,
    danke für den Link zum syncUUIDs.sh.
    Nur wie binde ich das Script an raspiBackup ein. Im Backup- oder Restore-Prozess ???
    mfg Bernd
    Zitieren
    #454 framp 2023-11-29 21:09
    Moin Bernd,

    es gibt ein Script von mir: HTTPS://github.com/framps/raspberryTools/blob/master/syncUUIDs.sh was die UUIDs syncen soll. Must Du mal testen ob das bei Dir funktioniert.

    Cu framp
    Zitieren
    #453 framp 2023-11-29 20:41
    Mojn Baerd,

    BTW: Es gab gerade im Raspberry Forum eine Diskussion ob noch mixed mode unterstuetzt werden muss von raspiBackup. Du nutzt ihn noch - gut zu wissen :-) Keine Angst - der wird auch nicht verschwinden in den naechsten Releases. ich bleibe immer backward compatible - auch wenn das manchmal Probleme in der Programmierung bereitet ...

    Cu framp
    Zitieren
    #452 framp 2023-11-29 20:35
    Moin Bernd,

    Dein Usecase war nie angedacht bei raspiBackup. Aber mit ein paar Tweeks geht es dann doch :-D

    Vielen Dank fuer Deinen ausfuehrlichen Bericht. Ich sehe da dass es eine Ecke gibt wo ich noch etwas fixen muss: Bei den weiteren Partitionen, also nicht nur 1-2. Anyhow wuerde ich die nofail Option bei Deinen externen Partitionen in der fstab zufuegen ;-)

    Cu framp
    Zitieren
    #451 Bernd 2023-11-29 11:37
    Hallo framp,

    Original fstab:
    proc /proc proc defaults 0 0
    PARTUUID=264f3462-01 /boot vfat defaults 0 2
    PARTUUID=76d82778-02 / ext4 defaults,noatime 0 0
    PARTUUID=76d82778-03 /media/usbplatte/ ntfs-3g defaults,auto,umask=000,users,rw 0
    PARTUUID=76d82778-05 /mnt/raspiBackups/ ext4 defaults 0
    # a swapfile is not a swap partition, no line here
    # use dphys-swapfile swap[on|off] for that

    ausgeführt:
    sudo raspiBackup.sh -d /dev/sda /mnt/raspiBackups/pi3/pi3-rsync-backup-20231129-030001

    lt. raspiBackup.msgr
    --- RBK0102I: PARTUUID wird von 76d82778-02 auf 8685d191-02 in /boot/cmdline.txt geändert.
    --- RBK0102I: PARTUUID wird von 76d82778 auf 8685d191 in /etc/fstab geändert.
    --- RBK0102I: PARTUUID wird von 264f3462-01 auf 8685d191-01 in /etc/fstab geändert.

    cmdline.txt auf clone sda1 nach restore
    console=serial0,115200 console=tty1 root=PARTUUID=8685d191-02 rootfstype=ext4 fsck.repair=yes rootwait
    ==> OK

    fstab auf clone sda2 nach restore
    proc /proc proc defaults 0 0
    PARTUUID=8685d191-01 /boot vfat defaults 0 2
    PARTUUID=8685d191-02 / ext4 defaults,noatime 0 0
    PARTUUID=8685d191-03 /media/usbplatte/ ntfs-3g defaults,auto,umask=000,users,rw 0
    PARTUUID=8685d191-05 /mnt/raspiBackups/ ext4 defaults 0
    # a swapfile is not a swap partition, no line here
    # use dphys-swapfile swap[on|off] for that
    ==> entspricht der raspiBackup.msgr - Meldung

    USB-Laufwerk abgetrennt, die SD-Karte entfernt dafür sda in den Kartenslot:
    !!! Raspi startet nicht !!!

    fstab auf clone sda2 nach restore manuell geändert
    proc /proc proc defaults 0 0
    PARTUUID=8685d191-01 /boot vfat defaults 0 2
    PARTUUID=8685d191-02 / ext4 defaults,noatime 0 0
    #PARTUUID=8685d191-03 /media/usbplatte/ ntfs-3g defaults,auto,umask=000,users,rw 0
    #PARTUUID=8685d191-05 /mnt/raspiBackups/ ext4 defaults 0
    # a swapfile is not a swap partition, no line here
    # use dphys-swapfile swap[on|off] for that
    ==> die Partitionen 03 und 04 sind mit oder ohne USB-Festplatte physisch nicht vorhanden, also Einträge 03 und 04 manuell auskommentieren oder entfernen

    !!! Raspi startet !!!

    Sicherlich ist der Restore-Prozess nicht auf meine speziellen MIX-Modus ausgelegt, aber ich kann damit leben. Eventuell die Clone-fstab per Script nacharbeiten.

    Ich habe meinen Clone. Der Rest ist dann Handarbeit!

    Danke für Deine Hilfe und raspiBackup
    mfg Bernd
    Zitieren
    #450 Bernd 2023-11-28 19:50
    Hallo framp;
    lt. meiner Dokumentation sollte ich die richtigen Dateien erwischt haben.
    Morgen werde ich weiter testen und natürlich aufpassen.
    Und berichten.
    mfg Bernd
    Zitieren
    #449 framp 2023-11-28 18:39
    Moin Bernd,

    nein, nicht Hardlinks. Du musst tierisch aufpassen dass Du die richtigen Dateien änderst. Dummerweise gibt es sie zweimal und Du kannst schnell die falsch erwischen.

    Ich hatte damals als ich den Mixed Mode in raspiBackup eingebaut habe auch öfter beim Testen an der falschen Stelle geändert :(

    Cu framp
    Zitieren
    #448 Bernd 2023-11-28 17:52
    Hallo framp,
    Nachtrag:
    habe soeben festgestellt, dass die Änderungen die ich in der cmdline und fstab der zweiten (restored) SD-Karte durchgeführt habe auch (nur) in der fstab des Originalsystems geschrieben wurden??? Hardlinks ???
    Start ist OK
    mfg Bernd
    Zitieren
    #447 Bernd 2023-11-28 17:27
    Hallo framp,
    genau so dachte ich es mir auch und bin mehrmals so verfahren. Aber es funktioniert leider nicht.
    Zumal in der raspiBackup.msgr steht:
    --- RBK0184I: Rootpartitionscheck gestartet.
    --- RBK0295I: /boot/cmdline.txt und /etc/fstab werden synchronisiert.
    --- RBK0102I: PARTUUID wird von 76d82778-02 auf cc0c6a8c-02 in /boot/cmdline.txt geändert.
    --- RBK0102I: PARTUUID wird von 264f3462 auf cc0c6a8c in /etc/fstab geändert.
    --- RBK0033I: Bitte warten bis aufgeräumt wurde.
    usw.
    Die cmdline.txt und fstab im Restore entsprechen dem Originalen.
    Wie gesagt, die manuellen Änderungen sind ohne Erfolg.
    Habe auch schon ein dritte SD-Karte für das Restore eingesetzt.
    Noch eine Idee?
    mfg Bernd
    Zitieren
    #446 framp 2023-11-28 16:30
    Moin Bernd,

    das geht schon. Nur musst Du nach dem Restore ohne -R noch zwei Aenderungen am restorten System machen:
    1) In der /etc/fstab musst Du die PARTUUID von / anpassen. Es muss die von /boot sein - nur am Ende nicht -01 sondern -02.
    2) In /boot/cmdline.txt musst Du hinter root= die geaenderte PARTUUID von / aus der /etc/fstab schreiben

    Dann sollte das System booten.

    Cu framp
    Zitieren
    #445 Bernd 2023-11-28 14:17
    Hallo framp,
    mit der Option -R muss ich eine Partition auserhalb meiner zweiten SD-Karte bestimmen, die ich nicht habe.
    Ich wollte das Restore zu Testzwecken auf einer einzelnen SD-Karte haben, also wieder auf einer Karte zusammenführen, als Clone benutzen. Nur für den Fall dass die USB-Festplatte mal ausfällt.
    Geht das mit raspiBackup ?
    mfg Bernd
    Zitieren
    #444 framp 2023-11-28 12:43
    Moin Bernd,

    bei Deinem Mixed Mode, also /boot auf SD Karte und /root auf USB musst Du zusaetzlich die Option -R nutzen. Siehe dazu HTTPS://www.linux-tips-and-tricks.de/de/wiederherstellen Abschnitt "Restore auf eine SD Karte und eine externe Partition"

    Cu framp
    Zitieren
    #443 Bernd 2023-11-28 12:27
    Hallo,
    ich nutze einen Raspberrypi-3B.
    Bootpartition: SD-Karte
    Rootpartition: USB-Festplatte (sdb2)
    RaspiBackup angelegt OK.
    Das Restore soll auf eine zweite SD-Karte sda erfolgen.
    Welche Parameter sollte ich nutzen, wenn die Zweite SD nach dem restoren, durch einstecken in den SD-Schacht und entfernten USB-Laufwerk sofort startbar ist.
    Mit der Option -d funktioniert es nicht wie gewollt.
    mfg Bernd
    Zitieren
    #442 Maddin 2023-07-29 13:21
    Falls jemand vor dem selben Problem stehen sollte. Mit dem Raspberry Pi Imager unter "other Image" funktioniert es super!
    Zitieren
    #441 framp 2023-07-27 18:17
    Moin Mardin,

    interessante Frage. Mit einer Raspberry und Linux geht das. Da ich kein Windowskenner bin kann ich Dir da nicht weiterhelfen. Du könntest aber die Frage im Raspberryforum - Unterforum Backup stellen. Dort gibt es raspiBackup Nutzer die Windows kennen und nutzen ;-)

    Cu framp
    Zitieren
    #440 Maddin 2023-07-27 15:53
    Hallo zusammen,
    ich habe eine DD Sicherung meiner SSD am Raspi erstellt. Nun würde ich gerne mal zum Test das ganze System an einem Windows Client wiederherstellen. Leider zeigt es mir ja das Laufwerk am Win32 DiskImager nicht an (Weil der vermutlich eine SD Karte benötigt)

    Hat jemand einen Tip wie ich das auf eine komplett frische SSD Restoren kann?
    Zitieren
    #439 framp 2022-12-25 18:10
    Moin Matze,

    so ganz verstehe ich nicht warum Du auf eine SD Karte restoren willst. Du schreibst doch dass Du SSD only faehrst.

    D.h. ich wuerde an Deiner Stelle eine SD Karte mit einem RaspbianOS erstellen und dort raspiBackup installieren. Dann verbindest Du Deine SSD auf der Du restoren willst mit Deiner Raspberry, verbindest Deine USB HDD und restorst das Backup von der HDD auf Deine SSD. Zum Testen willst Du sicherlich nicht Deine aktive SSD nutzen. Da kannst Du eine beliebige HDD oder auch einen USB Stick nehmen - sofern die Datenmenge Deines Backups daraufpasst.

    Cu framp
    Zitieren
    #438 Matze 2022-12-25 12:13
    Hallo. Ich wollte mal an einen Restore-Test wagen. Ich habe aber das Vorgehen nicht ganz verstanden. Mein System läuft auf einer externen SSD. Es ist keine SD Karte eingelegt. Das Backup liegt auf auf einer externen USB HDD. Das Vorgehen:
    Ich ziehe die SSD ab und boote von SD Karte. Das ist die, die ich zum Umzug auf die SSD genutzt habe. Hier müsste ich dann RaspiBackup installieren. Kann ich nun auf diese SD Karte den Restore machen? Oder geht der Restore nur auf eine zusätzlich angeschlossenen SD Karte mittels Kartenleser?

    Danke
    Zitieren
    #437 framp 2022-12-14 12:40
    Moin Peter,

    zitiere lupe:

    Die Abfrage mit sudo blkid -o list -w /dev/null gibt immer noch (not mounted) aus und trotzdem funktioniert es nicht.


    das ist ja das verzwickte: Waehrend des Restores wird von raspiBackup neu partitioniert und usbmount mountet sofort die Partition :-(

    Cu framp
    Zitieren
    #436 lupe 2022-12-14 12:23
    Hallo framp

    Vielen Dank für die prompte Antwort. Was der Eintrag ENABLE=0 in der usbmount.conf bewirkt hat sich mir nicht erschlossen. Jedenfalls erscheint die Meldung "Restore ist nicht möglich wenn 'usbmount' installiert ist. Die Abfrage mit sudo blkid -o list -w /dev/null gibt immer noch (not mounted) aus und trotzdem funktioniert es nicht.
    Nach Deinstallation von usbmount läuft jetzt alles fehlerfrei.
    Als nächstes kommt noch der Test ob die so restorte sd-Karte den PiHole auch startet.
    Vielen Dank für das tolle Programm.
    Beste Grüsse aus der Schweiz.
    Peter
    Zitieren
    #435 framp 2022-12-13 16:42
    Moin,

    usbmount funkt leider beim Restore dazwischen und darf nicht aktiv sein. Den musst Du erst deaktivieren. Ob er sich so wie Du im folgenden Kommentar beschrieben hast deaktiviert weiss ich nicht. Ich wuerde ihn im Zweifel deinstallieren.

    Wenn Du -U -S nutzt wird immer aktualisiert auch wenn Du die letzte Version schon hast. Das muss ich mal aendern dass man dann eine Meldung bekommt wenn schon die aktuelle Version lokal vorliegt.

    Cu framp
    Zitieren
    #434 lupe 2022-12-13 16:31
    Hallo framp
    Teil 1

    Das Backup meines PiHoles und meines SmartPi auf mein Synology NAS hat prima funktioniert. Seit zwei Tagen versuche ich nun erfolglos ein Restor auf eine SD-Karte die in einem USB-Reader.
    Nachfolgen die Abschlussmeldung:
    root@RPiHole:/home/pi# sudo raspiBackup.sh -d /dev/sda /Backup/RPiHole/RPiHole-rsync-backup-20221213-145702
    --- RBK0009I: RPiHole: raspiBackup.sh V0.6.8 - 2022-12-06 (81636e6) Di 13 Dez 2022 15:51:02 CET gestartet.
    --- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt.
    ??? RBK0277E: Restore ist nicht möglich wenn 'usbmount' installiert ist.
    --- RBK0033I: Bitte warten bis aufgeräumt wurde.
    ??? RBK0077E: Restore wurde fehlerhaft beendet. Siehe
    Zitieren
    #433 Hami 2022-10-24 18:57
    Alles klar, dann mach ich das wohl im git.

    Danke schon mal, bis dann
    Zitieren
    #432 framp 2022-10-24 17:28
    Du kannst auch gerne das Log irgendwo hochladen und mir hier die URL geben. Im git geht die Konversation allerdings leichter (Du bekommst update notifications und kannst auch das log per dragndrop anhaengen)

    Cu framp
    Zitieren
    #431 Hami 2022-10-24 16:37
    Ja hast recht. Werde mich die tage mal dran setzen und gucken.
    Ja prima, danke dir, dann mach ich noch mal nen Test und lad dir die logdatei hoch. Soll ich dafür auch nen issue erstellen?
    Zitieren
    #430 framp 2022-10-24 15:49
    Ok. Dann muss es eine andere Ursache haben.

    Ich empfehle Dir aber das noch genauer zu untersuchen und zu verstehen. Wenn Du den Ernstfall hast und restoren musst willst Du nicht noch mit so einem intermitierendem Fehler kaempfen.

    Wenn der Fehler wieder aufftritt stelle mir doch mal das Debuglog zur Verfuegung. Vielleicht finde ich was ...

    Cu framp
    Zitieren
    #429 Hami 2022-10-24 15:19
    Also hab jetzt mal nachgesehen, habe kein Paket mit den Namen usbmount installiert, vorsorglich habe ich es deinstalliert bzw versucht, aber auch da kam die Meldung, dass es nicht installiert ist.

    Komischerweise ging es jetzt dann irgendwann, ohne dass ich etwas anders gemacht habe als davor. Auch bei zwei weiteren Tests: erst kommt ein paar mal der Fehler dass gemounted sei (obwohl es nicht ist), nach mehreren versuchen mit "umount umount /dev/sda" (bzw sda1 und sda2) geht es dann immer irgendwann. Versteh ich zwar nicht, aber gut, hauptsache irgendwann klappt es :D
    Zitieren
    #428 framp 2022-10-24 10:34
    Moin hami,

    das klingt mir danach dass bei Dir usbmount aktiv ist. Siehe dazu auch HTTPS://github.com/framps/raspiBackup/issues/515. Den musst Du leider erst deaktivieren fuer den Restore.

    Falls es nicht daran liegt brauche ich ein Debuglog. Bitte erstelle dazu einen Issue im github und haege dort das Debuglog rein (drag and drop). Gerne auch in Deutsch wenn Du willst :-)

    Cu framp
    Zitieren
    #427 Hami 2022-10-24 09:12
    Guten Morgen framp,

    irgendwie komme ich gerade mit einem Test restore nicht klar. Es kommt immer die Meldung "??? RBK0274E: Das Restoregerät /dev/sda hat gemountete Partitionen. Hinweis: Ein Restore auf das aktive System ist nicht mogöich."
    Habe das backup auf dem NAS und will es auf eine hinten angesteckte micro sd widerherstellen. Diese war aber nicht gemounted und habe ich mit "umount /dev/sda1" und "umount /dev/sda" auch noch mal vorsichtshalber gemacht. Auch "sudo blkid -o list -w /dev/null" sagt /dev/sda (not mounted). Habe die sd card sogar noch extra formatiert mit "sudo mkfs.ext4 /dev/sda". (übrigens alles Befehle, die ich mir mal notiert hatte, also nicht dass das hier aussieht, als ob ich groß Ahnung hätte was ich da eingebe :-D )
    Trotzdem sagt "sudo raspiBackup.sh -d /dev/sda /backupnas/raspberrypi/raspberrypi-rsync-backup-20221024-040001/", dass die gemounted ist. Was mache ich denn schon wieder falsch?

    Gruß Hami
    Zitieren
    #426 framp 2022-10-15 12:40
    Moin Peter,

    Du scheinst eine alte Version von raspiBackup zu nutzen. In der aktuellen Version ist das gefixed :-)

    Mit “sudo raspiBackup.sh -U -S“ upgradest Du auf die aktuelle Version ;-)

    Cu framp
    Zitieren
    #425 Peter 2022-10-15 12:24
    Hallo Framp,
    vorab, ich nutze raspiBackup seit ca. 2 Monaten und habe Restoreversuche lediglich auf WIN mit WIN32DiskImager getestet. Nun, beim Restore auf der Raspi bekomme beim Restore einer Sicherung mit DD folgende Fehlermeldung:
    Nach der Zeile der Meldung RBK0050I: Backup wird von ... zurückgespielt
    /usr/local/bin/raspiBackup: Zeile 5250: executeCommandDD: Kommando nicht gefunden.
    Hast Du oder ein anderer kompetenter Kollege eine Idee wo hier das Problem liegt?
    Zitieren
    #424 Micha 2022-08-24 21:55
    zitiere framp:
    Moin Micha,

    in der Release 0.6.7 wurde die Option -m verbessert und dadurch war ein strikter Test des Backupverzeichnisses notwendig (siehe HTTPS://github.com/framps/raspiBackup/releases/tag/v0.6.7). Es gibt auch einen Issue zu dem Thema (Siehe HTTPS://github.com/framps/raspiBackup/issues/530) da der Test zu streng war. Dafuer habe ich einen Hotfix erstellt und in der naechsten Release wird der enthalten sein. D.h. entweder nimmst Du auch den Hotfix aus dem github Issue, Du loeschst/verschiebst alle Dateien und/oder Verzeichnisse im Backupverzeichnis die nicht von raspiBackup erstellt wurden oder Du gehst wieder auf die vorherige Release zurueck (Option -V) und wartest auf das naechste Release.

    Cu framp

    Moin framp,
    vielen Dank für die schnelle Anwort und Hilfestellung. Dann kann ich dank des Hotfixes ja beruhigt alle Rapis umstellen.
    Danke und VIele Grüße
    Micha
    Zitieren
    #423 framp 2022-08-24 11:03
    Moin Micha,

    in der Release 0.6.7 wurde die Option -m verbessert und dadurch war ein strikter Test des Backupverzeichnisses notwendig (siehe HTTPS://github.com/framps/raspiBackup/releases/tag/v0.6.7). Es gibt auch einen Issue zu dem Thema (Siehe HTTPS://github.com/framps/raspiBackup/issues/530) da der Test zu streng war. Dafuer habe ich einen Hotfix erstellt und in der naechsten Release wird der enthalten sein. D.h. entweder nimmst Du auch den Hotfix aus dem github Issue, Du loeschst/verschiebst alle Dateien und/oder Verzeichnisse im Backupverzeichnis die nicht von raspiBackup erstellt wurden oder Du gehst wieder auf die vorherige Release zurueck (Option -V) und wartest auf das naechste Release.

    Cu framp
    Zitieren
    #422 Micha 2022-08-23 21:16
    Hallo,
    ich erhalte nach einem Update von Version 0.6.6.1 auf 0.6.7 , wenn ich einen Backup Lauf mache die folgende Fehlermeldung :RBK0273E

    Kann es sein das die neue Version mit den alten Ordnern nicht klar kommt?. Wenn ich den alten Ordner umbenenne kommt der Fehler nicht und es wird ein neuer Ordner erstellt
    Vielen Dank und Viele Grüße
    Micha
    Zitieren
    #421 framp 2022-06-06 15:07
    Moin jeli0001

    die Meldung RBK0274E und der dazugehoerige Check ist in 0.6.7 neu und soll verhindern dass jemand aus Versehen einen Restore auf ein gemountetes Geraet vornimmt. Ein Nutzer hat dadurch seine Backupplatte aus Versehen ueberschrieben.

    "Wenn ich dann allerdings die SD-Karte unmounte, dann findet raspiBackup kein Zielmedium für den Restore. "

    Das ist merkwuerdig. Welche Fehlermeldung bekommst Du? Die SD Karte auf die restored wird darf auch nicht gemounted sein denn sie wird neu partitioniert und formatiert.

    Wie sieht denn die Ausgabe von "sudo mount" aus wenn die SD Karte gemounted ist und wie sieht die Ausgabe von "sudo blkid" bei nicht gemounteter SD Karte aus?

    Cu framp
    Zitieren
    #420 jeli0001 2022-06-06 14:13
    Beim Restore auf einer Ubuntu-Maschine mit raspiBackup 0.6.7 bekomme ich bei dem Kommando

    sudo raspiBackup --unsupportedEnvironment -d /dev/sdc /home/nfs/zerow/zerow-rsync-backup-20220605-161037/

    die folgende Fehlermeldung:

    ??? RBK0274E: Restore device /dev/sdc has mounted partitions. Note: Restore to the active system is not possible.

    Wenn ich dann allerdings die SD-Karte unmounte, dann findet raspiBackup kein Zielmedium für den Restore. Der Restore funktioniert also weder bei gemounteter SD-Karte, noch bei ungemounteter SD-Karte.

    Mit der Vorgängerversion 0.6.6 funktioniert der Restore auf eine gemountete SD-Karte bei gleichem Kommando (einziger Unterschied: Flag --unsupportedEnvironment nicht gesetzt, da diese offenbar erst in 0.6.7 hinzugekommen ist) einwandfrei.

    Muss ich da beim Restore einer SD-Karte auf einem Linux System unter Version 0.6.7 ein anderes Kommando verwenden?
    Zitieren
    #419 framp 2022-05-28 07:52
    Moin Neuling10,

    Du musst das Backupverzeichnis über seinen Mountpoint angeben und nicht den direkten Pfad auf die Syno benutzen ;-)

    Cu framp
    Zitieren
    #418 Neuling10 2022-05-27 22:58
    Hallo,

    ich habe ein rsync-Backup auf einer Synology erstellt. Nun möchte ich mittels einem separatem Raspi auf eine neue SD Card das Backup schreiben. Auf diesem Raspi läuft ein Standard Rasbian, Desktop Version. Raspibackup wurde installiert. Der nfs-Ordner auf der Synology wurde gemountet. Schreib- und Lesezugriff mittels Killroy-Datei erfolgreich getestet. Die zu beschreibende SD-Card ist mit einem USB-SD Card Adapter angeschlossen, auf sda.

    Folgenden Restore-Befehl nutze ich: sudo raspiBackup.sh -d /dev/sda /192.168.xxx.xx:/volume1/Backup_Raspi/raspieins/raspieins-rsync-backup-20220526-210330/

    Leider erhalte ich nur die Meldung, dass der Ordner nicht gefunden wird (Fehlercode 108 lt. Logfile). Muss ich den Restore-Befehl irgendwie anpassen, wenn mein Backup auf einer Synology im Netzwerk liegt)?
    Zitieren
    #417 framp 2022-04-06 23:17
    Moin Rene,

    lies bitte die FAQ: Dort steht u.A. dass github meine Praeferenz ist.

    Cu framp
    Zitieren
    #416 René 2022-04-06 23:16
    zitiere framp:

    Mit
    sudo fdisk -l /dev/mmcblk0 | grep "Disk /dev"

    root@linux:~# sudo fdisk -l /dev/mmcblk0 | grep "Disk /dev"
    Disk /dev/mmcblk0: 58.94 GiB, 63281561600 bytes, 123596800 sectors

    Aber die Backupquelle ist doch knappe 30GB
    Zitieren
    #415 René 2022-04-06 23:11
    Gibt es eigentlich ein Forum oder Discord oder irgendwas für den Support? Oder soll ich tatsächlich die Kommentarfunktion hier nutzen? :-?
    Zitat:
    !!! RBK0018W: Ziel /dev/sda mit 29.81 GiB ist größer als die Backupquelle mit 29.27 GiB. Die root Partition wird entsprechend vergrößert um den ganzen Platz zu benutzen.
    !!! RBK0065W: Gerät /dev/sda wird repartitioniert und die gesamten Daten werden gelöscht.
    --- RBK0067I: Momentane Partitionen auf /dev/sda:
    Number Start End Size Type File system Flags
    1 4.19MB 32011MB 32007MB primary fat32 lba
    Zitieren