raspiBackup Release 0.7

    Die naechste Release wird gerade von mir intensiv getestet. Ist leider eine undankbare Aufgabe da zwar die primaeren Backup- und Restorefunktion automatisiert getestet wird aber diverse spezielle Dinge leider manuell getestet werden muessen :nosmile:

    Bug Fixes wird es keine geben. Nur neue Features und Enhancements.

    Primaer sind folgende neue Features interessant:

    1) Mit der neuen Option -00 wird bei einem partitionsorientierten rsync Backup keine Formatierung der restorten Partitionen vorgenommen sondern der Backup mit dem aktuellen Stand gesynced. D.h. man kann so sehr schnell Aenderungen eines existierenden Systems zurueckrollen wenn mal bei einer Aenderung was schief gelaufen ist. Bislang muss man alle Partitionen vollstaendig aus dem rsync Backup restoren.

    2) Bei einem partitionsorientierte Backup koennen selektiv einzelne Partitionen restored werden. D.h. wenn man weitere Partitionen zusaetzlich zu den ersten beiden Partitionen auf dem System hat kann man nur die ersten beiden Partitionen restoren und nicht mehr alle Partitionen. Franjo G Danke fuer diesen indirekten Featurequest :thumbsup1:

    3) Alle Backups enthalten in ihrem Verzeichnisnamen auch die OSVersion. Somit koennen Backups bzgl des RaspianOS Releases unterschieden werden. Nuetzlich wenn man Systeme ueber die Zeit von einem OS auf ein Neues umstellt. Dieses Feature hat simonz in raspiBackup per PR eingebracht. Vielen Dank dafuer :danke_ATDE:

    4) Bei Pushover kann man nun ein Device angeben sowie zusaetzliche weitere Pushover API Optionen definieren. Das ist nuetzlich fuer User die Pushover nicht nur fuer raspiBackup sondern auch andere Dinge nutzen. Damit bekommen nicht alle in Pushover registrierten Geraete die Meldungen von raspiBackup sondern nur ein Device.

    5) F2FS wird unterstuetzt

    6) Ein neues Backup wird erst einmal nicht im Backupverzeichnis erstellt sondern in einem tmp Verzeichnis. Wenn aus irgendwelchen Gruenden der Backup abbricht bleibt dann keine Leiche im Backupverzeichnis stehen.

    7) Bislang musste das Restoredevice mindestens genausogross sein wie das Original beim partitionsorientierten Backup. Jetzt wird die letzte Partition entsprechend verkleinert oder vergroessert und sofern die originale letzte Partition nicht allen Space nutzt kann somit jetzt ein partitionsorientierter Backup auch auf kleinere Devices restored werden. Das ist bislang nur beim Restore eines normalen Backupmode moeglich.

    Eigentlich will ich die neue Release noch vor Weihnachten publishen aber das wird wohl nicht klappen. Ich hoffe wenigstens die Beta bis dahin rauszubringen und irgendwann in 1Q dann die finale Release.

    Details zu den Issues finden sich hier

    Eben teste ich ob der Update auf das neue Release 0.6.10 funktioniert inklusive des Merges der neuen Optionen im Configfile und muss dabei feststellen dass das leider durch einen kleinen Bug nicht funktioniert :nosmile: Der aktuelle Versionvergleichcode kann keine Zahlen > 9 korrekt vergleichen und somit wird die Release 0.6.10 nicht als neuer als Release 0.6.9.1 erkannt :blush:

    Ich koennte jetzt eine Release 0.6.9.2 rausbringen die den Fix enthaelt. Dann kann man damit auf die neue 0.6.10 updaten. Das ist allerdings ziemlich umstaendlich. Deshalb habe ich mich entschlossen dass die naechste Release 0.7.0 heissen wird statt 0.6.10. Dann klappt der Upgrade auch mit dem Bug.

    Genaugenommen macht es auch Sinn denn es finden sich doch recht viele Neuerungen im naechsten Release.

    Nun ja - urspruenglich waren nicht so viele Neuerungen geplant. Aber da das alte Release 0.6.9 schon ziemlich abgehangen ist sind in der Zwischenzeit doch viele neue DInge reingerutscht :lol:

    Die letzte Release 0.6.9 wurde am 19. November 2023 published. Ist also schon eine Weile her. Was sich doch so ueber die Zeit dann doch so ansammelt ...

    Eben habe ich die raspiBackup 0.7.0 Beta published. Die Neuerungen sind hier zusammengefasst.

    Primaer wurde der Restore des partitionsorientierten Modus erweitert und der Backupverzeichnisname beinhaltet nun auch die OSRelease im Namen. Vielen Dank an simonz der letzteres Feature implementiert hat :danke_ATDE:

    Fuer Fragen, Kommentare oder Problemmeldungen bitte diesen Thread nutzen.

    So, 1. Test erfolgreich.

    • Backup erstellen kein Problem.

    • DEFAULT_PARTITIONBASED_BACKUP="1"
      DEFAULT_PARTITIONS_TO_BACKUP="1 2 3"
      3 Partitionen /boot / und /home
      Backup wird erstellt
      pi5-lite@debian12-rsync-backup-20241126-015520
      Die Infos bzgl. der alten Backups sind gut.

      Getestet habe ich einen Restore von nur /boot
      sudo raspiBackup -T "1" -d /dev/nvme0n1 /backup/pi5-lite/pi5-lite@debian12-rsync-backup-20241126-015520
      Test erfolgreich. Die Bootpartition wurde formatiert und restored.
      System bootet.

      Restore von nur /
      sudo raspiBackup -T "2" -d /dev/nvme0n1 /backup/pi5-lite/pi5-lite@debian12-rsync-backup-20241126-015520
      erfolgreich.

      Restore von /boot und /
      sudo raspiBackup -T "1 2" -d /dev/nvme0n1 /backup/pi5-lite/pi5-lite@debian12-rsync-backup-20241126-015520
      erfolgreich.

      Folgende Meldung ist etwas ungünstig bzw. nicht gut formuliert.
      !!! RBK0303W: Partition nvme0n13 Das sollte nvme0n1p3 heißen.
      Ebenso das "wurde nicht" Was wurde sie nicht?


      Ich habe gerade gesehen. dass beim Restore der Standard auf "1 2" eingestellt ist. Das ist gut so.

    • # >>>>> NEW OPTION added in config version "0.1.8" <<<<<
      DEFAULT_PARTITIONS_TO_RESTORE="1 2"

    Edited 10 times, last by Franjo G (November 26, 2024 at 4:18 AM).

    Vielen Dank fuer Deine Tests und Feedback :thumbsup1:

    da fehlte tatsaechlich ein Wort in der deutschen Meldung :blush: Ich teste in Englisch und deshalb ist es mir nicht aufgefallen. Dein anderes Finding fiel mir auch nicht auf da ich immer auf /dev/sda restored habe. Ist schon gut wenn eine Beta von anderen Nutzern genutzt wird.

    Es ist jetzt beides gefixed. Die neue Version kannst Du mit

    curl -s https://raw.githubusercontent.com/framps/raspiBackup/master/scripts/raspiBackupDownloadFromGit.sh | bash -s -- beta raspiBackup.sh

    ins aktuelle Verzeichnis runterladen und entweder von dort aufrufen oder Du kopierst es dann in /usr/local/bin.

    Die neue Option -00 fuer den Restore hast Du gesehen? Ich denke die ist auch fuer Dich nuetzlich :wink1:

    Es hat mich gestoert dass der Update der Beta doch etwas umstaendlich ist und wollte den Code dazu einfuegen . Dabei habe ich dann gesehen dass sudo raspiBackup -U -S auch funktioniert um eine Beta upzudaten. Die letzte Beta ist schon sehr lange her so dass mir das nicht mehr so praesent war :neutral:

    Jetzt habe ich aber ein anderes Problem.

    Ich habe einen Restore mir -00 durchgeführt.

    sudo ./raspiBackup.sh -00 -d /dev/nvme0n1 /backup/pi5-lite/pi5-lite@debian12-rsync-backup-20241126-034856

    Alles ok.

    Dann habe ich noch einmal versucht, nur die Bootpartition zu restoren. Fehlgeschlagen

    sudo ./raspiBackup.sh -T "1" -d /dev/nvme0n1 /backup/pi5-lite/pi5-lite@debian12-rsync-backup-20241126-
    034856

    Mit der Option -00 funktioniert es.
    sudo ./raspiBackup.sh -T "1" -00 -d /dev/nvme0n1 /backup/pi5-lite/pi5-lite@debian12-rsync-backup-20241126-
    034856

    raspiBackup.logr

    //EDIT

    beendet mit Returncode 112.

    Muss ich jetzt die Feuerwehr anrufen? :D

    Edited 6 times, last by Franjo G (November 26, 2024 at 2:46 PM).

    Seit dem heutigen Beta update funktioniert kein Restore mehr ohne die Option -00
    Immer die Fehlermeldung mit sed und der Datei /tmp/2339.sfdisk

    Da hast Du echt einen Bug gefunden :blush: Du durchlaeufst den Codepfad wo Source- und Targetdevicesize gleichgross ist und dort fehlt das Kopieren der sfdisk Datei :mad_GREEN:

    Ich habe das eben gefixed. Also wird sudo raspiBackup -U -S den Fehler beheben.

    Das waren aber doch die gleichen Datenträger wie heute.

    Egal, Jetzt funktioniert es. :thumbup:

    Quote from Franjo G

    Das waren aber doch die gleichen Datenträger wie heute.

    Im Log finde ich

    Code
    20241126-141032 DBG 6302:                  --- sourceSDSize: 512110190592 - targetSDSize: 512110190592

    Kann es sein dass eine SSD manchmal unterschiedliche Size zurueckliefert? Finde ich merkwuerdig. Ich braeuchte das alte Restorelog wo es geklappt hat um das zu verifizieren. Die hast Du aber vermutlich nicht mehr.

    Quote from framp

    Die hast Du aber vermutlich nicht mehr.

    Nein, die habe ich nicht mehr.

    Aber die Terminalausgabe von letzter Nacht.

    Da muss wohl ein minimaler Unterschied bestanden haben.
    Kann es sein, dass dadurch die Größen angepasst wurden?

    Das Backup, bei dem ich heute den Restore getestet habe ist nach dem von gestern gemacht worden. Dort wurden noch Größenunterschiede angemerkt.

    Backup/Restore von gestern (morgens früh)
    pi5-lite@debian12-rsync-backup-20241126-015520 (Größenunterschiede angemerkt)

    Backup/Restore von heute
    pi5-lite@debian12-rsync-backup-20241126-034856 (keine Größenunterschiede mehr.)



    sudo raspiBackup -T "1 2" -d /dev/nvme0n1 /backup/pi5-lite/pi5-lite@debian12-rsync-backup-20241126-015520
    --- RBK0009I: testpi: raspiBackup.sh V0.7.0-beta - 2024-11-25 (65a0e5f) Tue 26 Nov 03:25:35 CET 2024 gestartet.
    !!! RBK0165W: =========> HINWEIS <=========
    !!! RBK0165W: Dieses ist eine Betaversion welche nicht in Produktion benutzt werden sollte.
    !!! RBK0165W: =========> HINWEIS <=========
    --- RBK0031I: Prüfe ob eine neue Version von raspiBackup.sh verfügbar ist.
    --- RBK0067I: Momentane Partitionen auf /dev/nvme0n1:
    NAME SIZE FSTYPE FSVER LABEL UUID PARTUUID
    nvme0n1 476.9G
    ├─nvme0n1p1 512M vfat FAT32 bootfs 435A-F252 9415459e-01
    ├─nvme0n1p2 62.5G ext4 1.0 nvme0n1p2 bde4a96e-0509-4a07-9ff7-89efa3653859 9415459e-02
    └─nvme0n1p3 413.9G ext4 1.0 nvme0n1p3 0af5928b-8d51-4751-8cce-6c56963f4dde 9415459e-03
    !!! RBK0305W: Partitionen "1 2" werden auf /dev/nvme0n1 zurüchgespielt.
    --- RBK0038I: Bist Du sicher? j/N
    j
    !!! RBK0052W: Partitionen werden auf /dev/nvme0n1 erstellt.
    --- RBK0038I: Bist Du sicher? j/N
    j
    --- RBK0323I: Ziel /dev/nvme0n1 mit 476.93 GiB ist größer als die Backupquelle mit 476.93 GiB. Die letzte Partition wird entsprechend vergrößert um den ganzen Platz zu benutzen.
    --- RBK0300I: Letzte Partition wird von 413.93 GiB auf 413.93 GiB angepasst.
    --- RBK0098I: Formatiere Partition /dev/nvme0n1p1 mit fat32.
    --- RBK0095I: Backup wird auf Partition /dev/nvme0n1p1 zurückgespielt.
    --- RBK0098I: Formatiere Partition /dev/nvme0n1p2 mit ext4.
    --- RBK0095I: Backup wird auf Partition /dev/nvme0n1p2 zurückgespielt.
    !!! RBK0303W: Partition /dev/nvme0n13 wurde nicht.
    --- RBK0319I: Neue UUIDs werden generiert.
    --- RBK0295I: /boot/firmware/cmdline.txt und /etc/fstab werden synchronisiert.
    --- RBK0033I: Bitte warten bis aufgeräumt wurde.
    --- RBK0076I: Restore erfolgreich beendet.
    --- RBK0010I: pi5-lite: raspiBackup.sh V0.7.0-beta - 2024-11-25 (65a0e5f) Tue 26 Nov 03:28:07 CET 2024 beendet mit Returncode 0.
    --- RBK0026I: Debug Logdatei wurde in /home/tester/raspiBackup.logr gesichert.

    Quote from Franjo G

    Da muss wohl ein minimaler Unterschied bestanden haben.
    Kann es sein, dass dadurch die Größen angepasst wurden?

    Wenn die Groesse von BackupSrc und RestoreTgt unterschiedlich ist wird partitioniert und die letzte Partition vergroessert oder verkleinert wenn weder -0 noch -00 genutzt wird. Bei -0 und -00 wird die existierende Partitionierung beibehalten und somit die Groesse des RestoreTgt beibehalten. Der Unterschied zwischen -0 und -00 ist nur dass bei -00 die restorten Partitionen nicht formatiert werden (Nur bei rsync Backup ist -00 moeglich).

    Wie sich der Effekt bei Dir ergeben hat ist mir nicht ganz klar :conf: Wie ist denn die Ausgabe von

    sudo fdisk -l /dev/<device> | grep -i -E "^disk.+bytes"

    bei beiden Geraeten?

    Bei beiden Geräten???

    Hier einmal meine Vorgehensweise.

    Code
    NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 223,6G  0 disk
└─sda1        8:1    0 223,6G  0 part /backup1
nvme0n1     259:0    0 476,9G  0 disk
├─nvme0n1p1 259:1    0   512M  0 part /boot/firmware
├─nvme0n1p2 259:2    0  62,5G  0 part /
└─nvme0n1p3 259:3    0 413,9G  0 part /home
    • Backup erstellt auf meinem Pi5 von der nvme0n1 (3Partitionen) auf sda1
    • Den Pi heruntergefahren
    • Einen weiteren Datenträger (sdb) mit Raspi OS und raspiBackup angesteckt und von dem gebootet.
    Code
    NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 223.6G  0 disk
└─sda1        8:1    0 223.6G  0 part /backup
sdb           8:16   0 111.8G  0 disk
├─sdb1        8:17   0   512M  0 part /boot/firmware
└─sdb2        8:18   0 111.3G  0 part /
nvme0n1     259:0    0 476.9G  0 disk
├─nvme0n1p1 259:1    0   512M  0 part
├─nvme0n1p2 259:2    0  62.5G  0 part
└─nvme0n1p3 259:3    0 413.9G  0 part
    • Das Backup zurückgespielt auf die originale nvme (von sda1 auf nvme0n1) Nur Partitionen 1 und 2
      Dabei wurde ein Größenunterschied festgestellt und die 3.Partition erweitert. (Restore lief einwandfrei durch)
    Code
    --- RBK0323I: Ziel /dev/nvme0n1 mit 476.93 GiB ist größer als die Backupquelle mit 476.93 GiB. Die letzte Partition wird entsprechend vergrößert um den ganzen Platz zu benutzen.
--- RBK0300I: Letzte Partition wird von 413.93 GiB auf 413.93 GiB angepasst.
    • Da das Backup auf den ursprünglichen Datenträger zurückgespielt wurde kann ja eigentlich kein Größenunterschied entstehen???
    • Dann ein erneutes Backup erstellt und mit dem neuen Backup erneut einen Restore versucht. (Vorgehensweise identisch)
      Dieser Restoreversuch schlug fehl, da kein Größenunterschied bestand.
      Das war der Bug den du gefixed hast.

    Edited 3 times, last by Franjo G (November 27, 2024 at 12:31 AM).

Participate now!

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

Register Yourself Login