Raspberry Pi Datenträger extern sichern

Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!
    Quote from Mic2022

    Kannst du mir hier helfen, woran das liegt?

    Klar doch :) Leichter geht es aber wenn Du das Debuglog hier zeigst und nicht einen Screenshot ;)

    Quote from Mic2022

    Der USB-Stick hat 128 GB und ist mit exFAT formatiert.

    exFAT unterstuetzt keine Hardlinks. Die brauchst Du fuer rsync Backup. D.h. entweder formatierst Du den Stick mit ext4 oder Du nimmst den tar Backup.

    Quote from Mic2022

    Wie komme ich in das raspiBackup Setup,

    Einfach sudo raspiBackupInstallUI aufrufen.

    Quote from Mic2022

    Ich kann den mittels sudo mkdir /backup erstellten Ordner im Raspbain Dateimanager nicht finden? Wo befindet er sich?

    Du solltest ihn mit ls -la /  sehen.

    Quote from Mic2022

    Wie kann man den Backup-Ordner dauerhaft mounten? Eintrag in etc/fstab oder gibt es eine bessere Lösung?

    Es gibt autoFS aber das bringt raspiBackup durcheinander. D.h. Du musst /backup in der /etc/fstab definieren. Falls es nur gemounted werden soll wenn ein Backup erstellt wird kannst Du die --dynamicMount Option nutzen (siehe u.A. hier und hier).

    :no_sad: Kein Backup - kein Mitleid :no_sad:
     :) Nutze lieber raspiBackup bevor Du in die Luft gehst :)

    ... und auch keine Dateirechte gespeichert.

    Wenn Du mit rsync sichern willst, musst Du /dev/sdb1 mit EXT4 formatieren.


    Servus !



    Aha, zu spät

    RTFM = Read The Factory Manual, oder so

    Like 1

    Hallo framp,


    ich hatte es befürchtet, dass es am exFAT liegt. Etwas widerwillig ließ sich der USB-Stick nun auf ext4 formatieren und damit kann das raspiBackup gestartet werden. Soweit erst einmal gut. Allerdings zeigt es mir im Log einige Fehler an und bleibt immer ewig an der Zeile IO error encountered -- skipping file deletion hängen. Danach wird es dann Fehlerhaft...



    Danke und Grüße,

    Mic.

    Verdacht bestätigt: Es lag an den beiden System-Diensten für rclone. Wenn ich diese disable, läuft das Backup durch.


    Wie kann man das umgehen? Ist das das Script bzgl. Systemd, von dem du gesprochen hast? Wenn ja, wie bindet man es richtig ein?

    Nächster Schritt ist nun, das System wieder auf die neue SSD (130 GB) zu bekommen und es da zum Laufen zu bekommen. Was gibt es dafür zu beachten? Hast du auch eine einfache Anleitung ("Befehlsabfolge") für mich dafür? :)

    Danke und Grüße,
    Mic.

    Quote from Mic2022

    Nächster Schritt ist nun, das System wieder auf die neue SSD (130 GB) zu bekommen und es da zum Laufen zu bekommen. Was gibt es dafür zu beachten? Hast du auch eine einfache Anleitung ("Befehlsabfolge") für mich dafür?

    Zu bespielende SSD anschließen,

    Code
    sudo raspiBackup -d /dev/'zu bespielende SSD (sda,sdb..)' /backup/raspberrypi/raspberrypi-rsync-backup-20230903-144933

    Hallo Franjo G ,


    danke für deinen Hinweis. Das war auch meine Idee. Leider bekomme ich eine Fehlermeldung:



    Die Daten sind aber m.M.n. vollständig vorhanden.


    Was mache ich falsch?

    Viele Grüße,
    Mic.

    Quote from Mic2022

    pi@raspberrypi:~ $ sudo raspiBackup.sh -d /dev/sda /remote/raspifix/disks/backup/rsync/raspberrypi/raspberrypi-rsync-backup-20230903-144933/

    Warum /remote/raspifix/disks ??


    So wie ich das sehe, ist dein Backup-Stick doch nach /backup gemountet.

    Code
    pi@raspberrypi:~ $ sudo mount /dev/sdb1 /backup

    Year! Gute Nachrichten. Ich habe es geschafft, mein System von der m.2 2 TB SSD auf die neue m.2 120 GB SSD zu übertragen und es bootet und läuft auch. Super! Danke euch.

    Ich musste bei der Wiederherstellung den Pfad der Backup-Daten etwas modifizieren und meinen neue 120 GB SSD als USB-Speicher unmounten. Dann ging es.


    Angepasster Pfad: /backup/raspberrypi/raspberrypi-rsync-backup-20230903-144933/

    Unmout der SSD: umoung /dev/sda1


    Der komplette Log sieht dann so aus:


    Auf dem neu "geclonten" System habe ich dann meine beiden System-Dienste für rclone wieder gestartet und das läuft nun auch wieder. Da wäre nun noch die Frage, wie man dies umgehen kann, damit ich die automatischen Backups nutzen kann (wenn mein neuer m.2 zu USB Adapter da ist).


    Vielleicht könnte framp nochmal drüber schauen, ob alles so gelaufen ist, wie es deiner Meinung nach laufen soll.


    Echt klasse Tool. Danke euch!


    Grüße,

    Mic.

    Quote from Mic2022

    Angepasster Pfad: /backup/raspberrypi/raspberrypi-rsync-backup-20230903-144933/

    Das hatte ich ja oben schon geschrieben.

    Auch hier zu sehen.


    Quote from Mic2022

    Unmout der SSD:

    Ja, der Zieldatenträger darf nicht gemountet sein.

    Quote from Mic2022

    pi@raspberrypi:~ $ systemctl --user stop rclone@GoogleDrive

    pi@raspberrypi:~ $ systemctl --user stop rclone@OneDrive

    Müssen die Dienste als "user"gestoppt werden? Oder geht das auch mit sudo systemctl stop ....

    Hallo Franjo G ,


    ja, ich hatte deinen Post erst danach gelesen.


    Wenn ich die System-Dienste ohne "user" stoppen möchte, fordert er mich zu einem Login auf.


    Mache ich es als sudo kann er den Dienst offensichtlich nicht finden:

    pi@raspberrypi:~ $ sudo systemctl stop rclone@OneDrive

    Failed to stop rclone@OneDrive.service: Unit rclone@OneDrive.service not loaded.


    Vielleicht kann das Skript, was framp für systemd erstellt hat hier helfen...?


    Grüße,
    Mic.

    Quote from Mic2022

    Failed to stop rclone@OneDrive.service: Unit rclone@OneDrive.service not loaded.

    Und mit sudo systemctl --user stop.....


    das problem ist, dass raspiBackup als user root gestartet wird.

    Quote from Mic2022

    Vielleicht kann das Skript, was framp für systemd erstellt hat hier helfen...?

    Sorry. Nein :no_sad: . Du musst rausfinden wie Du rclone als User und nicht als root starten und stoppen kannst und musst dann die entsprechenden Befehle in

    Code
    # commands to execute before services are stopped separated by &&
DEFAULT_BEFORE_STOPSERVICES=""
# commands to execute when services were started again separated by &&
DEFAULT_AFTER_STARTSERVICES=""

    manuell in der raspiBackup Configdatei einfuegen. Danach kannst Du aber die Services nicht mehr mit dem Installer konfigurieren.

    :no_sad: Kein Backup - kein Mitleid :no_sad:
     :) Nutze lieber raspiBackup bevor Du in die Luft gehst :)

    Hallo Franjo G,


    das funktioniert leider nicht:

    Code
    pi@raspberrypi:~ $ sudo systemctl --user stop rclone@OneDrive
Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)


    Hallo framp,


    das heißt, dein systemd Skript, von dem du sprachst, kann hier nicht helfen?


    Wo finde ich das Config-File mit den o.g. Code-Zeilen?


    Grüße,

    Mic.

    Hallo,


    kein Ding. :) Dein raspiBackup hat mir mein Leben schon enorm viel leichter gemacht, indem ich damit mein System von einer SSD auf eine andere klonen konnte. Für die zwei Services für rclone gibt es bestimmt auch noch eine Lösung. Dabei handelt es sich dabei doch aber auch im Systemd Services. Die Datei liegt ja als /home/pi/.config/systemd/user/rclone@.service ab. Scheinbar muss der Service damit aber als User ("pi") gestartet und gestoppt werden. Daher die Frage: Könnte man nicht ein Skript erstellen, welches den Service als User "pi" stoppt und startet und dieses dann in die raspiBackup.conf einbinden? Oder wieso muss es unbedingt als User "root" ausgeführt werden?


    Ja... raspiBackup Config-File... Wer lesen kann ist klar im Vorteil. :auslachen: Danke für den Hinweis. Da ist sie ja schon:
    /usr/local/etc/raspiBackup.conf


    Danke und Grüße,

    Mic.

    Quote from Mic2022

    Oder wieso muss es unbedingt als User "root" ausgeführt werden?

    raspiBackup braucht root Rechte zur Verwaltung der Backups und um alle Dateien des Systems sichern zu koennen ;)


    Du koenntest vermutlich raspiBackup auch in einem Wrapperscript erst einmal als normaler Nutzer starten und rclone mit systemctl stoppen und dann per sudo raspiBackup aufrufen und anschliessend als normaler Nutzer starten. Das bedeutet aber dass Du raspiBackup individualisiert nutzt und selbst Hand anlegen musst um das alles zu programmieren. Wenn Du Dich mit Linux und bash auskennst sollte das kein grosses Problem sein. Aber erwarte keinen Support von mir. Da musst Du dann alleine durch.


    Ich wuerde an Deiner Stelle versuchen rauszubekommen wie Du auch als root rclone stoppen kannst. Das ist sicherlich moeglich - nur musst Du rausfinden wie ;) Oder Du nutzt rclone nicht per Systemd Service sondern einfach per rclone Befehl. Dann muss kein Systemd Service existieren der gestoppt werden muss.

    :no_sad: Kein Backup - kein Mitleid :no_sad:
     :) Nutze lieber raspiBackup bevor Du in die Luft gehst :)
    • New

    systemctl --user Dienste für einen anderen User starten / stoppen funktioniert nur wenn man XDG_RUNTIME_DIR übergeben kann.


    Beispiel für den User "pi":


    Code
    sudo -u pi XDG_RUNTIME_DIR="/run/user/$(id -u pi)" systemctl --user stop xyz.service
sudo -u pi XDG_RUNTIME_DIR="/run/user/$(id -u pi)" systemctl --user start xyz.service
    • New

    Hallo framp,


    lass mich kurz eine Millisekunde nachdenken, ob ich dein gut funktionierendes raspiBackup umbauen möchte? … Nein! Never touch a running system. Ich hatte nur gedacht, dass Linux eine Möglichkeit mitbringt als User root auch einen Befehl im Namen eines „normalen“ Users auszuführen.


    Das Lustig ist ja, dass ich auf meinem alten System (mit RasPi OS Buster) ein Skript hatte, was beim Booten die beiden Cloud-Speicher über rclone mountet. Dann hat man mir hier im Forum gesagt, dass das vollkommen uncool ist und dass man das heutzutage als Service macht. Also habe ich mir einen Service dafür gebastelt. *lacht*


    Die Frage für mich ist aber auch, ob das Ersetzen des Service durch das alte Skript das Problem wirklich löst. raspiBackup meckert ja nicht den laufenden Service an, sondern den fehlenden Zugriff auf die beiden Ordner, in die die Cloud-Speicher gemountet sind. Stoppe ich den Service, werden diese ja un-mountet, verlieren ihre „Sonderrechte“ und daher gibt es keine Probleme mehr. Mounte ich per Skript gäbe es ja auch Rechteeinschränkungen der beiden Ordner.


    Also wäre das temporäre Stoppen und wieder Starten des Service (als User root) bestimmt doch die beste Lösung. Ich frage mich, ob die angezeigte Fehlermeldung  Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)  hier nicht einen Hinweis geben kann (den ich nur nicht richtig interpretiere).


    Vielen Dank und Grüße,

    Mic.