raspiBackup - Sichere Deine Raspberry regelmäßig im laufenden Betrieb

Immer wieder lese ich mal dass Leute eine SD Karte oder auch eine USB Platte clonen wollen. Das geht mit raspiBackup - allerdings ueber den Umweg dass erst ein Backup erstellt werden muss der dann auf dem neuen Medium restored werden muss.

Ich koennte eine Option --clone in raspiBackup einbauen mit der man ohne den Umweg eines Backups einen Clone erstellen kann. Genaugenommen ist das dann auch ein Backup - aber eben nur einer. Deshalb ist die Frage ob diese Funktion in einem Backuptool Sinn macht. Auch ist die Frage ob es dafuer signifikanten Bedarf gibt denn ich baue in raspiBackup nur Features bei der es auch eine groessere Nutzungfrequenz gibt. Ansonsten ist es meine verschwendete Zeit

rpi-clone ist z.B. ein nettes OpenSourceTool was man fuer Cloneoperationen bereits gut nutzen kann.

Eben habe ich einen bloeden Bug in raspiBackup gefixed: Der Restore eines tgz Backups endet mit RC 2 vom tar und RC117 von raspiBackup.

Der Bug wurde in Release 0.6.7 am 3.10.2022 eingebaut. Wer also einen 0.6.7 Release mit neuerem Commit Date hat (mit raspiBackup.sh --version checken) oder die Release 0.6.8 nutzt muss raspiBackup mit sudo raspiBackup.sh -U -S updaten sofern der Backuptyp compressed tar genutzt wird. Ansonsten ist kein Restore moeglich. Im Kontext des debuggens dieses Issues habe ich auch eine Anleitung erstellt wie man manuell ein tgz Backup restoren kann.

Sorry for the inconvenience

Quote from jar

warum macht man sowas?

Du tust ja so als haettest Du noch nie einen Bug geschossen

Dank github konnte ich sehr genau nachvollziehen wann ich die Zeile verbugged habe. Zeigt sich mal wieder das SW Development ohne Librarysystem zwar moeglich ist - eine Wartung aber ist schlichtweg unmoeglich.

Quote from Andreas

nach meiner Erfahrung wird eine Software umso unwartbarer, je länger und unübersichtlicher der Code gestrickt ist

Ich sehe nicht dass raspiBackup unwartbar ist. Es hat zwar schon knapp 10 Jahre auf dem Buckel - aber ist in der Zeit auch sehr in seiner Funktionalitaet gewachsen.

Quote from Andreas

Bei meinen Projekten seit 2013 habe ich mir angewöhnt, bereits in der Designphase (Pflichtenheft, Technisches Design) alle untergeordneten Aufgaben in Modulen (mit integrierten automatischen Modultests) auszulagern. Diese Dinger kann ich zu einer sehr frühen Phase der Entwicklung testen (lassen), dokumentieren (lassen). Wenn ich trotzdem in diesen funktionalen Modulen herumfuhrwerken sollte, erkennt die Umgebung, ob der Modultest noch gültig ist - oder wiederholt durchzuführen und zu dokumentieren ist.

Beruecksichtige bitte dass raspiBackup urspruenglich ein winziges Tool fuer mich war um meine Raspberries zu sichern und ich irgendwann dachte es wuerde auch ein hilfreiches Tool fuer die Community sein. Frage nicht was ich an Aufwand spendiert habe um alle moeglichen Environment- , Configuration- oder Eingabefehler abzufangen. Das war als nur ich es nutze nicht notwendig da ich weiss was ich tue.

Quote from Andreas

Es gibt kaum was Nervenderes, als Fehler im eigenen Code zu finden, der mal funktioniert hat.

Dafuer gibt es einen Regressiontest der alle moeglichen Backup/Restore Konfigurationen testet. Leider ist dieser Bug nicht entdeckt worden da der Fehler in einem spezieller Codepfad vorlag.

Quote from Andreas

Abschließend mein allerbester Tipp: Früher träumte ich, wie ich programmiere, um das Problem des Tages zu lösen. Das führte zu einem entspannten sehr frühen Feierabend, einem intensiven Traum - und am nächsten Morgen 30-minütiges Akkord-auf-die-Tastatur-eindreschen, bis es dann funktionierte. In der gleichen Form am Vortag, hätte ich stundenlang voller Frustration vor dem Räscheknecht verbracht.

Klar - bei groesseren Dingen macht es immer Sinn mal ueber die Sache zu schlafen. Habe ich oft @office genug praktiziert. In diesem Falle war es ein kleiner Fix fuer einen Issue (5 Zeilen geaendert) und der Bug ist auch recht schnell visuell im Code zu finden. Ich weiss nun nicht mehr was damals gerade bei mir passierte. Aber saemtliche Aktionen finden in meiner Freizeit statt und da gibt es immer wieder Interrupts von der besseren Haelfte oder anderen Quellen und dann kommt sowas eben vor.

Ich hatte mal angefangen raspiBackup in go neu zu schreiben (Siehe hier) aber der Aufwand fuer mich ist hoch und bringt mir nichts denn fuer mich erfuellt raspiBackup meine Anforderungen. Ich wuerde sagen 80% der Features von raspiBackup kamen von Nutzern rein. Das ist gut so - dadurch ist raspiBackup in so vielen Environments einsetzbar und ich habe auch gerne die Featurerequests implementiert. Das alles noch mit Unittests abzudecken waere schoen gewesen - ist aber in bash wirklich kein Spass.

Kurzum: raspiBackup ist eben ein kostenloses Feierabendprojekt und kein professionelles Projekt fuer das ein Kunde bezahlen muss.

Es gab einen raspiBackup Nutzer dem hat tar auf die Finger gehauen weil sich irgendwas geaendert hat waehrend des Backups Er fragte wie er rausfinden kann was sich geaendert hat. tar Ist da in seiner Meldung sehr unspezifisch. Ich weiss nicht mehr warum aber mir fiel dann ploetzlich eine Loesung ein die gut funktioniert: Einfach waehrend des Backups in einem weiteren Fenster folgenden Befehl eingeben:

inotifywait -m -e delete -e create -e move -e modify -e attrib <Verzeichnis wo sich was geaendert hat>

U.U. muss noch die Option -r zugefuegt werden um auch alle Unterverzeichnisse zu beobachten.

Dieses habe ich auch in den FAQs aufgenommen

Danke. Habe es oben korrigiert. Kommt manchmal vor dass beim Selektieren eines Textes fuer copy/paste der erste Buchstabe nicht selektiert wird

Quote from TrueTec

??? RBK0149E: Datei" blabla usw" existiert nicht.

Die Datei blabla existiert bestimmt nicht in Deinem Backupverzeichnis

Ich brauche schon die genaue Fehlermeldung Besser noch das Debuglog. Das ist anonymisiert und das kannst Du hier per drag'n drop hochladen da hyle das freundlicherweise enabled hat.

Weitere Details zu raspiBackupDialog

Du stopst doch nur Anwendungen. Dann wird das wlan weiter funktionen.