Raspberry pi3 als backup server via rsync

  • Bei einem Linux PC, einem Linux Pi und einer EXT4 HD-Sicherung (zu Aufrechterhaltung der Dateirechte) wäre Samba, das auch nur im Userspace läuft, keine gute Idee. Dann eher noch NFS, das ja im Linux Kernel integriert ist.

    Dat musse mir bidde ma erklärn. :conf:

    Seit wann läuft denn Samba im Userspace? Bei mir laufen auf dem Server beide Dienste (smbd/nmbd) unter root. Und wieso gehen die Dateirechte verloren? Wenn ich das weiterhin richtig verstanden habe, ist das hier eine reine LAN-Anwendung, eine Datei-Kopiererei allein innerhalb des LANs. Wieso sollte denn da Samba weniger sicher sein als SSH? Oder anders gefragt, wieso ist denn innerhalb eines LANs überhaupt ein Secure-Shell-Protokoll angesagt..?.... ich halte das nicht nur für völlig unnötig, sondern sogar für kontraproduktiv, weil zum eh schon langsamen NIC noch der SSH-Overhead beim rsync hinzukommt. Und wenn er die Backup-Platte nicht allgemein im LAN zugänglich machen will.... wo ist denn da das Problem..?... das ist doch eine Kernfunktion von Samba.

    Und was NFS angeht... ich würde das hier nicht empfehlen.... noch weniger, wenn sich im LAN vielleicht auch noch Windows-Clients tummeln. Und am allerwenigsten, wenn nicht klar ist, wie man UID und GID zwischen Client und Server synchron hält. Das bisschen Performance-Gewinn ist für die meisten User sowieso nicht erkennbar. Außerdem lässt sich Samba definitiv leichter in Betrieb nehmen.

    Rsync hat 3 Betriebsmodi. local, remote-shell und rsync daemon, jeweils push, oder pull. Das braucht keinen eigener Samba-User dazwischen, der noch alle Dateirechte verbiegt und auf 2 Linuxsytemen den Durchsatz bremst.

    Ja, kann man machen, ich bin von so einer Lösung erst mal nicht überzeugt.... aber ich lerne gerne dazu und schau mir das mal an

    2 Mal editiert, zuletzt von WinterUnit16246 (2. Februar 2018 um 15:46)

  • Kleiner Nachtrag.... zwei mal 2.1 GB Datei kopiert, um zu sehen, wie SAMBA die Performance ausbremst....

    SSH hat 255 Sekunden benötigt: (4:15)

    Samba hats in 202 Sekunden geschafft (3:22)

    Für die Passphrase bei SSH kann man grosszügigerweise noch 3-4 Sekunden abziehen...

    Einmal editiert, zuletzt von WinterUnit16246 (2. Februar 2018 um 16:42)

  • Thomas L.

    Prinzipiell spricht nichts gegen Samba. Der einzige Grund vermutlich ist der, das ich von rsync via ssh kaum Ahnung habe und mir alles mühsam zusammenklauben und erarbeiten muss und von Samba noch weniger als überhaupt keine Ahnung habe. Das heisst ich breche mir hier, trotz der super Hilfe schon einen ab. Wie soll ich das dann mit Samba wuppen?
    MfG,

    Suwo

  • Dat musse mir bidde ma erklärn.

    Bitte gerne: http://www.linfo.org/kernel_space.html

    Mit dem vom TO gewähltem rsync braucht er kein weiteres Protokoll, weder smb/nmb, noch nfs.

    Zwischen Linux/Unix Maschinen ist rsync ausreichend.

    Mit welcher der 6 möglichen Varianten rsync in Netz gestartet wird, ist Geschmacksache und hängt vom Bedarf des TO ab, einen rsync daemon 24/7/365 laufen zu lassen. Für den Abgleich des Home Verzeichnisses halte ich den Zugang über remote shell ausreichend und zweckmässig.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Da steht doch gar nix von Samba drin... das ist doch nur völlig allgemeines Geschwurbel.

    BTW, ich habe wirklich nix gegen rsync...im Gegenteil, rsync ist imho ein tolles Werkzeug, ich nutze das ja auch. Aber diese Aussage ist schlichtweg falsch:

    Mit dem vom TO gewähltem rsync braucht er kein weiteres Protokoll, weder smb/nmb, noch nfs. Zwischen Linux/Unix Maschinen ist rsync ausreichend.

    Wieso denkst Du denn, das SSH nicht ebenso ein Kommunikationsprotokoll ist, wie NFS oder Samba? SSH läuft üblicherweise auf Port 22, Samba auf 139 und NFS anscheinend auf 111 und mapped unpriviligierte Ports dazu... und alles läuft via TCP ab. Nur bei SSH kommt noch der "teure" SSH-Handshake und die Verschlüsselung hinzu, was Samba und NFS nicht haben. Aber alle 3 sende Pakete via TCP-Protokoll. Ich halte ein SSH->rsync innerhalb des LANs jedenfalls für die schlechteste Alternative. Funktionieren wird das.... keine Frage...

  • Wie soll ich das dann mit Samba wuppen?

    Das ist nicht wirklich kompliziert: https://jankarres.de/2013/11/raspbe…r-installieren/ Ich würde das nur nicht mit dem User "pi" machen, sondern dafür entweder Deinen User nehmen, oder einen eigenen erstellen.

    Die in dem o.g. Beispiel genannte Freigabe "TestFreigabe" kann man dann einfach auf einem Client mouten. Wie das geht, wurde gerade eben noch umfassend im Thread Remote-Mounts besprochen.

  • Hallo.

    Noch ein neues Thema (samba) wäre mir zu viel, daher würde ich gerne mit rsync weitermachen. Also fstab läuft. Ich habe ein Schlüsselpaar für das Backup erstellt und passend in die ~/.ssh/config eingetragen. Den host habe ich back genannt. Also ssh back klappt und verbindet mich mit dem raspberry. Jetzt fehlt mir das script. Ich habe auf meinem PC einen Ordner Test erstellt. Jetzt will ich von meinem PC ~/Schreibtisch den Ordner zum pi nach /media/Linux_Backup kopieren. Mein script:

    Bash
    #!/bin/bash
    # Testkopie von Desktop Verzeichnis zum pi pi@192.168.0.35
    rsync -aux -e "ssh -i back"  /home/wolle/Schreibtisch/Test /media/Linux_Backup/
    #

    Klappt nicht. Wenn ich das Script aus dem Terminal starte, kommt folgendes:

    rsync: mkdir "/media/Linux_Backup" failed: Permission denied (13)

    rsync error: error in file IO (code 11) at main.c(674) [Receiver=3.1.1]

    Habe nach Permissiondenied (13) gesucht, bin aber daraus nicht schlau geworden.

    https://www.elektronik-kompendium.de/sites/raspberry-pi/2102191.htm

  • @ mkdir "/media/Linux_Backup" failed: Permission denied

    heist wohl, dass in /media/ (root root drwxrwxr-x) der User pi keine Datei (=Verzeichnis) erstellen darf/kann

    Mach mal aus dem bisherigen Ziel (/media/Linux_Backup/) vorerst einmal /home/pi/Linux_Backup, in /home/pi darf pi schreiben.

    Und dann langsam an das gewünschte Endprodukt anpassen.

    Hast Du eigentlich < man rsync > gelesen ?


    Servus !

    RTFM = Read The Factory Manual, oder so

    • Offizieller Beitrag

    Also fstab läuft.

    Das kann ich so nicht akzeptieren. Das ist die selbe Aussage wie "geht nicht" ohne eine Fehlermeldung zu zeigen. :no_sad: Das ist keine Hilfe für die Nachwelt.

    Zeige wenigstens die Zwischenlösung, bzw. Deinen Eintrag in der fstab, bevor Du mit dem nächsten Schritt weiter machst!

  • Klappt nicht. Wenn ich das Script aus dem Terminal starte, kommt folgendes:

    Du brauchst das solange nicht mit dem rsync probieren, solange Du nicht bestätigst hast, dass grundsätzlich der SSH-Zugriff mit dem Keysfile funktioniert.... also im übertragenen Sinne muss eine solche Anmeldung funktionieren:

    Code
    ssh thomas@100.100.10.2 -p 22

    Du musst natürlich hier Deine Daten eintragen, den Port-Parameter nur, wenn Du einen anderen Port als 22 verwendest... 22 ist der default-Port und muss nicht angegeben werden.Der Schlüssel (Keyfiles) müssen auf beiden Rechner eingetragen und auch vorhanden sein. sein. Auf dem Pi in der sshd_conf, auf dem Client in der ssh_config. In welches Dirs hast Du die Schlüssel kopiert?

    Poste mal vom Raspi die Ausgabe von:

    Code
    egrep -i "keys|authentication" /etc/ssh/sshd_config

    Auf dem Server muss danach der Daemon einmal neu gestartet werden.

    Code
    systemctl stop ssh.service
    systemctl start ssh.service

    Solange also eine normale SSH-Anmeldung nicht funktioniert, wird auch kein rsync funktionieren.

    2 Mal editiert, zuletzt von WinterUnit16246 (2. Februar 2018 um 23:42)

  • rsync -aux -e "ssh -i back" /home/wolle/Schreibtisch/Test /media/Linux_Backup/

    Um auf ein lokal eingebundenes Dateisystem mittels rsync zu kopieren, brauchst du kein ssh. rsync benutzt ssh nur wenn über das Netzwerk kopiert wird, dann lautet das Ziel aber auch "... user@host:/pfad/"

    Wenn du nichts zu sagen hast, sag einfach nichts.

  • Um auf ein lokal eingebundenes Dateisystem mittels rsync zu kopieren, brauchst du kein ssh. rsync benutzt ssh nur wenn über das Netzwerk kopiert wird, dann lautet das Ziel aber auch "... user@host:/pfad/"

    Da hast Du durchaus Recht. Und der TO will sein bisheriges lokales rsync (auf dem Linux PC) so erweotern, dass als Kopierziel eine am Pi angeschlossene USB HD dient *UND* kein Passwort beim Aufbau einer SSH Verbindung zum Pi abgefragt wird.

    Solange rsync ohne -e (=execute) "ssh ..." Ausgangsverzeichnit Remote@Zielverzeichnis nicht funktioniertm wird es auch mit -e nicht funktionieren.

    Solange ssh mit der Key Authentifizierung nicht alleine funktioniert, wird es auch innerhalb von rsync nicht funjtionieren.

    Dazu kommt noch vermutlich ein Rechteptoblem am Pi-USB HD Mountpoint.


    Zuerst sollte < ssh -i back > alleine erfolgreich funktionieren.

    Dann rsync -anvp /home/wolle/Schreibtisch/ pi@192.168.x.x:/Mountverzeichnis/USB-HD

    Und dann können beide funktionierenden Befehle in eine Zeile für crontab zusammengeführt werdenm mit -e


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Hallo.

    Ich weiß, es ist mühsam mit mir, danke für die Geduld. Also meine fstab bindet die Partitionen ein.

    fstab:

    Code
    PARTUUID=0025fe5e-01 /media/pi/Linux_Backup ext4        defaults        0
    PARTUUID=0025fe5e-02 /media/pi/Windows  ntfs-3g utf8,uid=pi,gid=pi,noatime      0

    Genau dort finde ich die Partitionen. In #27 schrieb ich, dass ich ein Schlüsselpaar und die Datei ./ssh/config erstellt habe. Mein key hat die Bezeichnung backup bzw. backup.pub Der host in der config Datei heisst back. Gebe ich ssh back ein werde ich wie gewünscht mit dem pi verbunden. Das klappt also. Jetzt zu rsync. Zum Testen habe ich auf dem Desktop (Schreibtisch einen Ordner Test mit Datei test1 Unterordner mit Datei test1 erstellt. rsync klappt. Option n habe ich weggelassen , um das auch real zu sehen. Super, bis hierher vielen Dank.

    Ist es sinnvoll alles in ein script zu schreiben und das dann per cronjob zu starten?

    Etwa so:

    Ist das so i.O. Oder wie trenne ich die SSh-Verbindung nach der Sicherung wieder?

  • Hallo suwo !

    Wenn ssh klappt und rsync klappt, dann kannst Du beide in eine Zeile (für cron) verbinden.

    rsync -a -e "ssh back" /home/user/Schreibtisch/Test pi@xxx.xxx.x.x:/media/pi/Linux_Backup

    Ob eine Datensicherung "funktioniert" kann man nur am restore, also an der Rücksicherung auf das Ursprungssystem beurteilen. Für das testweise Rücksichern kannst Du im /home/user auch temporär ein /home/user/rsynctest anlegen und dahinein die Rücksicherung vornehmem. Dabei sollten die rückgesicherten Dateien, bis zur (Uhrzeit) ident sein, links und mounts wieder richtig funktionieren. Selbst freimde uids zB. uid 1999, oder uid 0) sollten wieder so erscheinen. Sonst ist noch ein Finetuning notwendig, wenn die bisherigen rsync Optionen (-rlptgoD) nicht ausreichen.


    Servus !

    RTFM = Read The Factory Manual, oder so

    2 Mal editiert, zuletzt von RTFM (3. Februar 2018 um 19:06)

  • Hallo.

    Danke für den Tipp. Kann ich aber erst morgen testen. Jetzt noch die Verständnisfrage: ssh back verbindet mich mit dem pi. pi@raspberry. Diese Verbindung trenne ich mit "exit". Starte ich rsync und ssh back per cronjob ist die Verbindung hergestellt. Aber muss nach Beendigung des Backup die Verbindung nicht wieder getrennt werden, denn der raspberry läuft ja rund um die Uhr.

    Suwo

  • Zitat

    Wenn ssh klappt und rsync klappt, dann kannst Du beide in eine Zeile (für cron) verbinden.

    rsync -a -e "ssh back" /home/user/Schreibtisch/Test pi@xxx.xxx.x.x:/media/pi/Linux_Backup

    Nein, kann er (so) nicht und braucht er auch nicht.

    man ssh und man rsync lesen.

    rsync -au -e "ssh -i /Pfad/zum/Key" /Quellpfad user@host:/zielpfad

    Da wird vorher manuell keine ssh-Verbindung aufgebaut, das regelt rsync selbst.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    2 Mal editiert, zuletzt von llutz (4. Februar 2018 um 14:50)

  • Hallo zusammen.

    Super es klappt mit

    Code
    rsync -au -e "ssh -i /Pfad/zum/Key" /Quellpfad user@host:/zielpfad

    so wie ich mir das vorgestellt habe. Vielen Dank für die Unterstützung und Hinweise.

    Suwo

Jetzt mitmachen!

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