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

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Wenn Du sie Dir ansiehst wirst Du an verschiedenen Stellen @@@ finden. raspiBackup maskiert automatische die meisten sensiblen Informationen im Log. Allerdings besteht keine Garantie dass alles maskiert wurde (Siehe die Uebershrift im Log). D.h. Du kannst jetzt entweder mal manuell druebersehen und eventuelles noch maskieren oder Du zippst die Datei verschluesselt und schickst mit den Schluessel per PN.

    Hi,

    im Anhang die Datei. PW via PM.

    Gruß

  • raspiBackup - Sichere Deine Raspberry regelmäßig im laufenden Betrieb? Schau mal ob du hier fündig wirst!

  • Vielen Dank fuer das Log.

    Darin sehe ich

    sowie

    Zitat

    20210919-061815 DBG 4434: /dev/mmcblk0p2 on /var/folder2ram/var/log type ext4 (rw,noatime,nodiratime)

    20210919-061815 DBG 4434: folder2ram on /var/log type tmpfs (rw,relatime)

    OMV lagert /var/log ins RAM aus und es wird nicht auf die SD Karte geschrieben. Da rsync mit -x gesichert wird werden nur Dateien von der SD Karte gesichert und somit nicht /var/log und auch weitere Verzeichnisse wie /var/spool, /var/tmp usw nicht.

    Ich habe jetzt keine Ahnung wie folder2ram funktioniert. So wie ich RAM Disks verstehe werden die beim Starten angelegt und wenn notwendig von den Applikationen mit Daten gefuellt. Beim Log ist es wohl nicht notwendig Daten zu fuellen. Aber es muessen eben die Verzeichnisse in /var/log angelegt werden. Ich haette jetzt gedacht dass nginx beim Starten das tut - aber offensichltich doch nicht :no_sad:

    ich denke es haette gereicht die beiden fehlenden Verzeichnisse anzulegen und nginx neu zu starten statt nginx zu reinstallieren.

    Kurzum: Es liegt an den RAM Disks die OMV nutzt dass die Verzeichnisse von raspiBackup gnicht esichert werden bzw an nginx dass es die Logdateien nicht beim Starten automatisch erstellt wenn sie nicht existieren.

    Moegliche Loesungsmoeglichkeiten die ich fuer Dich sehe (in absteigender Praeferenz von mir):

    1) Nach dem Restore die beiden Verzeichnisse manuell wieder anlegen mit den richtigen Rechten (einfach im laufenden System nachsehen wie sie sein muessen)

    2) Reinstallation von nginx nach dem restore

    3) Fuer /var/log die RAM Disk nicht nutzen sondern die SD Karte

    :no_sad: ... Kein Backupkein Mitleid ... :no_sad:
    :) Nutze lieber raspiBackup bevor Du in die Luft 💥 gehst wie ein HB Männchen :)

    Einmal editiert, zuletzt von framp (19. September 2021 um 17:09) aus folgendem Grund: Typos

  • Das wars, was ein Akt.

    Es zeigt sich immer wieder dass es eine gute Entscheidung damals war sofort Logging einzubauen als ich mich entschied raspiBackup allgemein verfuegbar zu machen. Ohne das Log haette ich nie die Ursache bzw nur durch ein ewiges Frage-/Antwortspiel rausgefunden. Oder ich haette einfach geantwortet: Not supported environment. Denn eigentlich ist raspiBackup nur fuer eine Raspberry mit normalem RaspiOS unterstuetzt. Aber es gibt viele andere Environments (HW und SW/OS) wo es auch funktioniert. Deshalb versuche ich immer zu helfen. Aber manchmal muss ich wirklich passen. Ist aber i.d.R. bedingt dadurch dass ich die eingesetzte HW nicht habe um das Scenario nachzustellen. Z.B. funktioniert raspiBackup nicht mit einer eNMVe.

  • Es gibt seit ein paar Tagen eine neue Release 0.6.6.1.

    Update einer bestehenden Installation geht mit sudo raspiBackup -U bzw mit dem Installer sudo raspiBackupInstallUI M1 -> M5 -> P1 und P2.

    Neben ein paar neuen Features fuer Telegram sowie Bugfixes gibt es jetzt eine Sprachunterstuetzung fuer Finnish. D.h. raspiBackup hat jetzt eine Infrastruktur um weitere Sprachen zuzufuegen und wer Lust und Zeit hat kann gerne raspiBackup eine weitere Sprache beibringen ;)

  • Update einer bestehenden Installation geht mit sudo raspiBackup -U bzw mit dem Installer sudo raspiBackupInstallUI M1 -> M5 -> P1 und P2.

    Ich habe 2 Rpi mit raspiBackup.

    Update auf 1. RPi:

    sudo raspiBackup -U

    Update wird ausgeführt.

    Update auf 2. RPi:

    sudo raspiBackup -U

    Update wird nicht ausgeführt.

    Fehler:

    Code
    $ sudo raspiBackup -U
    sudo: raspiBackup: Befehl nicht gefunden

    Habe dann in meine Doku geschaut.

    Bei Update habe ich notiert:

    sudo raspiBackup.sh -U

    Update wird nun ausgeführt.

    Was ist beim 2. RPi anders als beim Ersten?

  • Irgendwas passt mit den Links nicht.

    Das Update auf den 1. RPi habe ich so gemacht:

    Update auf 1. RPi:

    sudo raspiBackup -U

    Update wird ausgeführt.

    Seitdem kommen aber immer die Status-Mails so:

    Code
    --- RBK0031I: Prüfe ob eine neue Version von raspiBackup.sh verfügbar ist.
    --- RBK0080I: ;-) Es gibt eine neue Version 0.6.6.1 von raspiBackup zum downloaden. Die momentan benutze Version ist 0.6.6 und es kann mit der Option -U die lokale Version aktualisiert werden.
    --- RBK0114I: Besuche https://www.linux-tips-and-tricks.de/de/versionshistorie/ um die Änderungen in der neuen Version kennenzulernen.

    Jetzt habe ich mal mit 2 Kommados das Update geprüft.

    Einmal mit dem Link und einmal mit der SH-Datei.

    Ergebnis:

    Code
    $ sudo raspiBackup -U
    --- RBK0031I: Prüfe ob eine neue Version von raspiBackup verfügbar ist.
    --- RBK0073I: /usr/local/bin/raspiBackup bereits auf der aktuellen Version 0.6.6.1.
    $ sudo raspiBackup.sh -U
    --- RBK0031I: Prüfe ob eine neue Version von raspiBackup.sh verfügbar ist.
    --- RBK0190I: Es wird raspiBackup.sh von Version 0.6.6 auf Version 0.6.6.1 upgraded.
    --- RBK0038I: Bist Du sicher? j/N

    EDIT:

    Jetzt habe ich

    sudo raspiBackup.sh -U

    durchlaufen lassen.

    Ergebnis:

    Code
    $ sudo raspiBackup -U
    --- RBK0031I: Prüfe ob eine neue Version von raspiBackup verfügbar ist.
    --- RBK0073I: /usr/local/bin/raspiBackup bereits auf der aktuellen Version 0.6.6.1.
    $ sudo raspiBackup.sh -U
    --- RBK0031I: Prüfe ob eine neue Version von raspiBackup.sh verfügbar ist.
    --- RBK0073I: /usr/local/bin/raspiBackup.sh bereits auf der aktuellen Version 0.6.6.1.
  • Merkwuerdig :conf:

    Ich habe mal Dein Szenario nachgestellt indem ich /usr/local/bin/raspiBackup.sh die Version 0.6.6 verpasst habe und den Link /usr/local/bin/raspiBackup erstellt habe. Ich bekommen bei beiden Aufrufen mit -U die Meldung dass eine neue Version vorliegt und ob updated werden soll.

    Kurzum: Sowohl theoretisch als auch praktisch kann ich nicht verstehen wie sich bei Dir raspiBackup und raspiBackup.sh mit -U unterschiedlich verhalten :no_sad:

  • Ich bekommen bei beiden Aufrufen mit -U die Meldung dass eine neue Version vorliegt und ob updated werden soll.

    Ich vermute, dass auch ich bei beiden Update-Aufrufen die Meldung zur neuen Version erhalten hätte.

    Aber sudo raspiBackup -U hatte ich ja schon ausgeführt.

    Das kann ich erst wieder prüfen, wenn es die nächste neue Version gibt.

  • Hallo framp,

    zum Thema Update habe ich auch eine kleine Frage.

    Nachdem mir die Statusmail schon länger das Update anzeigt, habe ich am 17.10 das Update endlich durchgeführt - über raspiBackupInstallUI.

    Zuvor habe ich aber manuell noch ein Backup angestossen (12:17), nach dem Update habe ich wieder manuell ein Backup durchgeführt (12:19).

    Was mich etwas irritiert: die Statusmail des manuellen Backups vor dem Update zeigt mir keinen Smilie im Betreff an, also so, als ob keine neuere Version vorhanden wäre!?

    Das habe ich auf beiden Pis so.

    Ist das so richtig? Ein Bug? In der /etc/cron.d ist auch nur raspiBackup ohne weitere Parameter eingetragen, daher ist mir der Unterschied bei der Betreffzeile nicht so ganz klar. :conf:

    Kannst Du für mich den Erklärbär machen? ;)

    Danke und Gruss

  • Franjo G Darum verstehe ich es auch nicht. Allerdings gibt es einen kleinen Unterschied ob das Script als raspiBackup oder raspiBackup.sh aufgerufen wird: $0 enthaelt den Scriptnamen und der ist natuerlich unterschiedlich. Ich nutze auch $0 im Script. Aber es wird nicht genutzt fuer den Versionscheck.

    meute Was Du geschrieben hast fand sicherlich statt. Daran zweifele ich nicht. Nur kann ich Dein Szenario nicht nachvollziehen. Leider gibt es auch keine Logs so dass ich irgendeine Moeglichkeit habe die Ursache naeher zu untersuchen ;( Wichtig ist dass es jetzt ueber beide Wege funktioniert. Du koenntest vielleicht noch einmal die Ausgabe von ls -la /usr/local/bin/raspi* zeigen denn die einzige Moeglichkeit die ich sehe wie das passieren kann ist dass raspiBackup und raspiBackup.sh nicht mit einem Link verbunden sind.

  • Was mich etwas irritiert: die Statusmail des manuellen Backups vor dem Update zeigt mir keinen Smilie im Betreff an, also so, als ob keine neuere Version vorhanden wäre!?

    Es findet ein Cachen der Versionsinformationen bei raspiBackup statt. Pro Tag wird nur einmal der Cache refreshed. Der Installer prueft direkt ohne Cache. Hast Du vielleicht vorher schon einmal raspiBackup aufgerufen?

  • meute Du koenntest vielleicht noch einmal die Ausgabe von ls -la /usr/local/bin/raspi* zeigen denn die einzige Moeglichkeit die ich sehe wie das passieren kann ist dass raspiBackup und raspiBackup.sh nicht mit einem Link verbunden sind.

    Bitte schön:

    Code
    $ ls -la /usr/local/bin/raspi*
    -rwxr-xr-x 1 root root 307755 Okt 16 12:56 /usr/local/bin/raspiBackup
    -rwxr-xr-x 1 root root 266435 Okt 25  2020 /usr/local/bin/raspiBackup.0.6.5.1.sh
    -rwxr-xr-x 1 root root 271969 Dez 29  2020 /usr/local/bin/raspiBackup.0.6.6.sh
    lrwxrwxrwx 1 root root     38 Okt 25  2020 /usr/local/bin/raspiBackupInstallUI -> /usr/local/bin/raspiBackupInstallUI.sh
    -rwxr-xr-x 1 root root 101809 Dez 29  2020 /usr/local/bin/raspiBackupInstallUI.sh
    -rwxr-xr-x 1 root root 307755 Okt 19 17:48 /usr/local/bin/raspiBackup.sh

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!