Synchronisationsrestore eines normalen Backups in der nächsten raspiBackup Release unterstützt

Auf github fragte jemand was genau zu tun ist um raspiBackupAndClone zu nutzen. Daraufhin habe ich die, zugegebenermassen etwas spärliche Dokumentation updated, und mich in diesem Kontext gefragt, warum eigentlich die Synchronisationsrestorefunktionalität nur verfügbar ist wenn der partitionsorientierte Modus genutzt wird.

Hintergrund: Oftmals hat man irgendwie sein System durch Änderungen vergeigelt und es bootet nicht mehr oder macht andere Probleme. D.h. in diesem Falle ist ein Restore eine Backups erforderlich.

Wer rsync nutzt sowie den partitionsorientierten Backupmodus ist dann fein raus: Einfach die Option -00beim Restore nutzen und es werden nur die Änderungen zum letzten Backup restored. Das geht üblicherweise fix. Wer den Backuptyp dd oder tar nutzt bei dem wird ein Vollrestore durchgeführt und dauert also wesentlich länger.

Bislang wird die Option -00 nur für den partitionsorientierten Backup unterstützt. Keine Ahnung warum nicht auch im normalen Modus ... wohl weil ich damals meinen Fokus auf dem partitionsorientierten Backup hatte. Diese Option macht absolut Sinn auch im normalen Modus.

Das Feature war auch recht schnell eingebaut. Es wird mit dem nächsten Release verfügbar sein. Wer das aber schon vorher nutzen möchte, kann sich mit

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

den Fix downloaden und nutzen.

Vermutlich wird es niemand nutzen solange es nicht offiziell verfügbar ist, denn die Wahrscheinlichkeit für einen Restore ist gering.

Anyhow - vielleicht will ja auch jemand mal testen wie damit ein Restore schneller möglich ist.

Bei mir geht ein Restore eines Trixie lite Image von 4 Minuten auf 30 Sekunden zurück. Allerdings habe ich da kaum Dinge geändert.

Die Änderungen sind überschaubar klein und der Regressiontest lief erfolgreich durch. Deshalb habe die Funktionalität in master merged und auch den Stand published. D.h. wer sich den letzten Stand der Release 0.7.2 holt, hat diese Funktionalität sofort.

Quote from Franjo G

Hast du an raspiBackup noch irgendetwas anderes geändert?

Nicht bewusst. Wenn Du mir die git commit shas der beiden raspiBackupVersionen gibst kann ich den Code mal direkt vergleichen.

Quote from Franjo G

Aber daür hat der Restore nur 42 sek. gedauert.

Wie lange dauert es ohne -00?

Quote from Franjo G

Da wird die Taste "j" aber mächtig strapaziert.

Findest Du es zu nervig? Ich will nur sicherstellen dass jemand weiss was passieren wird bevor das System aus Versehen ev. zerstört wird.

Wenn Du mutig bist kannst Du auch die Option -Y nutzen. Vorher aber noch in der Konfig eintragen welches Device mit der Option erlaubt ist

# Use with care !
DEFAULT_YES_NO_RESTORE_DEVICE="loop"

EDIT: Ist die Option -Y, nicht -y

Quote from Franjo G

--- RBK0010I: @HOSTNAME@: raspiBackup.sh V0.7.2 - 2026-04-24 (d05682e) Sa 25. Apr 00:29:19 CEST 2026 beendet mit Returncode 0

In der Meldung steht der Commit in Klammern (d05682e).

Perfekt Ich sehe nach.

Vielen Dank. Habe auch schon einen Unterschied gefunden. Nur muss ich noch verstehen warum deshalb keine eMail geschickt wird

Der Codeunterschied bewirkt

1) dass die Option -00 auch im normalen Modus akzeptiert wird

2) dass eMails nur geschrieben werden wenn das Script im Background läuft (hatte ich noch mit aufgenommen für das raspiBackupAndClone Script, damit auch beim Restore eine eMail geschickt wird). Das hatte ich vergessen

Bislang wurden auch im Foreground eMails geschickt. Das ist jetzt nicht mehr denn eigentlich macht es keinen Sinn, denn man sieht ja die Meldungen auf dem Bildschirm. Somit ist der Grund gefunden warum Du keine eMail mehr bekommst.

In dem Kontext fällt mir aber gerade ein, dass somit auch mit der Option -F, die man ja nutzen kann, um die eMailConfig zu prüfen, nicht mehr funktioniert. Das muss ich noch ändern.

EDIT: Mit -F wird jetzt immer eine eMail gesendet mit der aktuellen neuen Version

Quote from Franjo G

ca. 15 Minuten

Wenn das kein Argument für rsync und die Option -00 ist

Vielen Dank für Deinen Test und Fehlermeldung hier - der dann aber keiner war sondern bedingt durch den Update. Aber lieber so als andersherum. Zumal ich dadurch auch noch die Lücke mit der Option -F gefunden habe.

Hast Du den letzten Stand von raspiBackup 5426b15 ?

Lt github habe ich vor 28 Minuten eine Änderung commited mit dem o.g. sha .

Wenn Du raspiBackup --version aufrufst hast demnach nicht den o.g sha. sudo raspiBackup -U -S aktualisiert Deinen Stand.