Regelmäßig Ordner von Pi5 auf Synology Diskstation kopieren

[Stationary]

Ich habe jetzt den Pi5 mit 500 GB SSD im Argon Neo5-Gehäuse ohne microSD-Karte unter RaspiOS laufen. Dort fallen in einem Nutzerordner von Zeit zu Zeit Daten an, die ich automatisiert in einen Ordner auf der Diskstation kopieren lassen möchte. Hierzu soll einfach der ganze Nutzerordner von der Pi-SSD in einen Ordner auf der DS geschrieben werden, beispielsweise einmal wöchentlich.
Was wäre da Eurer Einschätzung nach die beste Vorgehensweise? Mit fstab einen Ordner der DS in den Pi5 mounten und dann einen cronjob cp laufen lassen? Kann der automatisch bestehende Daten überschreiben?

 

[Tommes]

Hi!

Ich würde das wohl mit einer SSH Public Key Authentifizierung und rsync erledigen. Dabei hast du die Wahl, ob du die Daten von deinem RasPi entweder von deiner Synology NAS mittels Pull-Backup abholen lässt, oder ob du die Daten von deinem RasPi per Push-Backup auf deine Synology NAS schiebst.

Tommes

 

[Barungar]

Ich rate auch zu rsync... das ist unter *nix das Tool der Wahl für solche Aktionen. Da braucht es auch keinen Mount, wie @Tommes schon geschrieben hat, und das ganze kannst Du locker-flockig über SSH machen.

Hier ist ein Beispiel-Kommando, wie ich es z.B. verwende:

rsync -e "ssh -l root" -vtrz --log-file=/var/log/rsync/rsync_$(date +"%Y-%m-%d").log /dir/sub_dir/sub_sub_dir/ <Host-FQDN>::<rsync_target>/ >/dev/null 2>>/var/log/rsync/rsync.err

 

[Tommes]

Weil ich in deinem (@Barungar) rsync Befehl „root“ lese…

Man kann sich zwar per SSH Public Key Authentifizierung als root auf ein Remote Synology NAS aufschalten, jedoch ist dies unter Verwendung von rsync over SSH nicht möglich. Daher würde ich in diesem Fall ein Pull-Backup, ausgelöst von der Synology NAS vorziehen, möchte man die Besitzrechte der Quelldatei im Ziel erhalten wollen.

Vermutlich verwendest du daher auch den rsync Deamon, welcher meines Wissens keine SSH root Berechtigungen erfordert, sondern unverschlüsselt über den Port 873 überträgt. Leider habe ich diesbezüglich nur oberflächliche Erfahrungen im Zusammenhang mit einem Synology NAS gemacht und kann daher keine konkreten Aussagen dazu treffen. Ich meine mich nur daran erinnern zu können, das der Konfigurationsaufwand etwas aufwendiger ist.

 

[Barungar]

Nein, das läuft nicht über rsync daemon (Port 873) sondern über SSH-Port 22, und ja es ist ein SSH-RSA Key für den root-User hinterlegt auf dem Ziel-System. Das "-e" aktiviert eine Funktion namens "USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION" (aus den Man-Pages). Auf dem Zielsystem läuft also kein lauschender rsync-Daemon, es wird durch den sshd ein rsync gespawned.

Ich muss einschränkend erwähnen, dass ich nicht weiß, ob das mit einer Synology geht. Ich habe keine. Aber grundsätzlich läuft auf den NAS-Geräten doch in der Regel ein Linux, und man kann auch auf der Console agieren.

 

[Tommes]

<Host-FQDN>::<rsync_target>

Dann ist da aber ein Doppelpunkt zu viel in deinem Befehl. Dieser ruft nämlich den rsync-Daemon auf und nicht den SSH-Daemon.

Ich muss einschränkend erwähnen, dass ich nicht weiß, ob das mit einer Synology geht. Ich habe keine. Aber grundsätzlich läuft auf den NAS-Geräten doch in der Regel ein Linux, und man kann auch auf der Console agieren.

Ohne Konfigruationsanpassungen in der /etc/ssh/ssh_config können über SSH keine Scripte bzw. Befehle per SSH als root ausgeführt werden. Ich kann mich zwar per ssh root@my-diskstation direkt als root aufschalten, wenn ich unter /root die entsprechenden Public Keys eingerichtet habe, aber das war‘s dann auch. Ich würde aber auch davon abraten, in der /etc/ssh/ssh_config rumzufummeln.

 

[Barungar]

Dann ist da aber ein Doppelpunkt zu viel in deinem Befehl. Dieser ruft nämlich den rsync-Daemon auf und nicht den SSH-Daemon.

Nein, es sind zwei Doppelpunkte! Weil ein rsync_target aufgerufen wird und es wird kein rsync-Daemon benutzt. Weil die Option "-e" aktiv ist. Es wird durch eine SSH-Verbindung, ohne einen auf Port 873 lauschenden und laufenden rsync-Daemon gesichert.

Ich kann mich nicht mehr erinnern, dass ich an der sshd_config abgesehen von der SSH-RSA-Key Authentifizierung irgendetwas bezüglich Remote-Skriptausführung an der geändert hätte. Das ist glaube ich gar nicht notwendig.

Es geht aber auch beides, wie Du sagst rein über SSH... Mann kann auch mit nur einem Doppelpunkt arbeiten, dann ist es aber kein rsync-target das man nutzt, sondern "nur" ein Host mit Verzeichnisangabe. Die erweiterten Möglichkeiten, die ein rsync-Target bietet, kann man aber dann nicht nutzen. Wobei fraglich ist, ob die wirklich gebraucht werden.

rsync -e "ssh -l root" -vtrz --log-file=/var/log/rsync/rsync_$(date +"%Y-%m-%d").log /dir/sub_dir/ <host-FQDN>:/dir/sub_dir/ >/dev/null 2>>/var/log/rsync/rsync.err

vtrz bedeutet übrigens (v)erbose, (t)imes, (r)ecursive und z=compress. Also etwas mehr ins Log schreiben, die Zeitstempel von der Quelle am Ziel übernehmen, rekursiv auch Unterverzeichnisse mitzunehmen und mit Kompression übertragen. In einer reinen LAN-Umgebung kann man auf "z" vermutlich auch verzichten. Ich habe diese rsyncs häufig zwischen Internet-Hosts gemacht.

 

[Tommes]

Nein, es sind zwei Doppelpunkte! Weil ein rsync_target aufgerufen wird [...] Mann kann auch mit nur einem Doppelpunkt arbeiten, dann ist es aber kein rsync-target das man nutzt, sondern "nur" ein Host mit Verzeichnisangabe.

Das verstehe ich nicht? Was soll denn der Unterschied zwischen einem rsyn_target und einer Verzeichnisangabe sein? Die beiden Doppelpunkte besagen imho nur, ob der rsync-Daemon aufgerufen wird oder nicht. Du baust somit eine verschlüsselte SSH-Verbindung auf um dann über den rsync-Daemon unverschlüsselte Daten, verschlüsselt zu übertragen. Kann man sicherlich machen und steht so als Option auch in der rsync Manpage, aber eigentlich ist diese Art der Übertragung nur in Ausnahmefällen nötig.

Dazu nachfolgend ein paar Auszüge aus der rsync Manpage zum Thema "zwei Doppelpunkte"

General

[...]

There are two different ways for rsync to contact a remote system: using a remote-shell program as the transport (such as ssh or rsh) or contacting an rsyncdaemon directly via TCP. The remote-shell transport is used whenever the source or destination path contains a single colon : separator after a hostspecification. Contacting an rsync daemon directly happens when the source or destination path contains a double colon :: separator after a hostspecification, OR when an rsync:// URL is specified (see also the lqUSING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTIONrq section for an exception tothis latter rule).

... und weiter unten im Text ....

Using Rsync-daemon Features Via a Remote-shell Connection

It is sometimes useful to use various features of an rsync daemon (such as named modules) without actually allowing any new socket connections into a system (other than what is already required to allow remote-shell access). Rsync supports connecting to a host using a remote shell and then spawning a single-use lqdaemonrq server that expects to read its config file in the home dir of the remote user. This can be useful if you want to encrypt a daemon-style transfer's data, but since the daemon is started up fresh by the remote user, you may not be able to use features such as chroot or change the uid used by the daemon. (For another way to encrypt a daemon transfer, consider using ssh to tunnel a local port to a remote machine and configure a normal rsync daemon on that remote host to only allow connections from lqlocalhostrq.)

From the user's perspective, a daemon transfer via a remote-shell connection uses nearly the same command-line syntax as a normal rsync-daemon transfer, with the only exception being that you must explicitly set the remote shell program on the command-line with the --rsh=COMMAND option. (Setting the RSYNC_RSH in the environment will not turn on this functionality.) For example:

rsync -av --rsh=ssh host::module /dest

If you need to specify a different remote-shell user, keep in mind that the user@ prefix in front of the host is specifying the rsync-user value (for a module that requires user-based authentication). This means that you must give the '-l user' option to ssh when specifying the remote-shell, as in this example that uses the short version of the --rsh option:

rsync -av -e "ssh -l ssh-user" rsync-user@host::module /dest

The lqssh-userrq will be used at the ssh level; the lqrsync-userrq will be used to log-in to the lqmodulerq.

Themawechsel:

Ich kann mich nicht mehr erinnern, dass ich an der sshd_config abgesehen von der SSH-RSA-Key Authentifizierung irgendetwas bezüglich Remote-Skriptausführung an der geändert hätte. Das ist glaube ich gar nicht notwendig.

Wie gesagt. Du kannst dich zwar per Public Key Authentifizierung an einer Synology NAS als root aufschalten, ein aufschalten per Script oder durch Ausführung einer Befehlskette wie z.B. bei rsync geht das nicht. Das ginge nur , wenn man Änderungen in der sshd_config vornehmen würde, wovon ich jedoch abrate.

Daher halte ich es für das Beste, wenn ich ein Pull-Backup von einem Synology NAS als root ausführe, um Daten von einem Remote Server abholen zu lassen. Dazu muss natürlich der Public Key der Synology NAS auf dem Remote Server hinterlegt sein. Ich würde das dann z.B. so ausführen (über die Konsole als root oder über den DSM Aufgabenplaner als Benutzerdefiniertes Script, welches ebenfalls als root ausgeführt werden muss.

rsync -ah \
--stats \
--delete \
--backup --backup-dir=@recycle/$(date +"%Y-%m-%d_%Hh-%Mm-%Ss") \
-e "ssh -p [SSHPORT] -i ~/.ssh/[PRIVATEKEY]" [SSHUSER]@$[SSHPULL_FROM]:"[SOURCES]" "[TARGET]/" 2>&1

... das ganze mit ein paar Beispieldaten gefüllt...

rsync -ah \
--stats \
--delete \
--backup --backup-dir=@recycle/$(date +"%Y-%m-%d_%Hh-%Mm-%Ss") \
-e "ssh -p 22 -i ~/.ssh/id_rsa" tommes@172.16.1.20:"/home/tommes" "/volume1/NetBackup/MyRemoteBackup/" 2>&1

Tommes

 

[Tommes]

BTW: Führt man den o.a. Befehl als benutzerdefiniertes Script sowie als root im DSM Aufgabenplaner aus und man hat im Vorfeld unter Einstellungen den Haken bei "Ausgabeergebnisse speichern" gesetzt, kann man sich das Protokoll auch über die Schaltfläche "Aktion" - "Ergebnis anzeigen" ausgeben lassen...

 

[Stationary]

Da habe ich ja was losgetreten, vielen Dank für die Informationen. Da ich ssh bisher immer nur mit Benutzername und Passwort verwende, wenn ich mal schnell was auf dem Terminal machen möchte: woher bekomme ich den Public Key der Diskstation und wo genau muß man den auf dem Pi5 hinterlegen? Ist dies der richtige Weg? https://community.synology.com/enu/forum/1/post/136213 oder genau anders herum?

 

[Barungar]

Man erstellt den SSH-Key auf der shell mit em Befehl ssh-keygen (mehr Infos mit man ssh-keygen).
Der Key wird auf dem System (A) erstellt, dass sich passwortlos einloggen soll. Auf dem System (B), wo der passwortlose Login erfolgen soll, wird der Public Key von System (A) in die Datei /root/.ssh/authorized_keys geschrieben.

Ich würde das Sicherungs-Skript auf dem Pi laufen lassen. Somit wäre die Pi System (A) und die Synology wäre System (B).
Also auf dem Pi ein ssh-keygen machen und dann in das Verzeichnis ~/.ssh/authorized_keys des Users kopieren, unter dem die Sicherung auf der Synology abgelegt weren soll. Das muss im Zweifel auch nicht der root sein!

Neben wir also weiter mal an, auf der Pi würde der User "root" aktiv sein und auf der Synology gäbe es den User "backup". Auf der Synology liegen die Dateien in /files/backup und auf dem Pi liegen sie in /opt/files/store.

1. Pi: ssh-keygen als User "root" ausführen, ohne Paramter wird alles als Standard angenommen.
   Die folgenden Rückfragen einfach alle mit [Enter] beantworten, es sollten drei Stück sein. Zum Ablageort des Keys, zum Passwort und zum Bestätigen des Passworts.
2. Pi+Synology: Den Public Key des Pi-Users "root" nun beim Synology-User "backup" hinterlegen.
   Dazu auf der Pi als root den folgenden Befehl eingeben: scp /root/.ssh/id_ed25519.pub backup@<NAS-FQDN>:/home/back/.ssh/authorized_keys
   Da ich keine Synology habe, hoffe ich, dass die an der Struktur der /home-Verzeichnisse nix ändert und das bei einem (neuen) User auch direkt das /home/<user>/.ssh/-Verzeichnis angelegt wird. Ansonst müsste das noch angelegt werden. Dabei wäre wichtig, dass das Verzeichnis .ssh 700-Rechte hat und auch die Datei authorized_keys 600 hat!
3. Pi: Test des SSH-Logins ohne Passwort einfach ssh backup@<NAS-FQDN> vom Pi aus auf das NAS probieren.
4. Pi: Test Sicherung: rsync -e "ssh -l backup" -vtrz /opt/files/store/ <NAS-FQDN>:/files/backup/
5. Pi: Im cron daemon das rsync einrichten, dabei die Version nutzen, die Logs schreibt.
   z.B.: rsync -e "ssh -l backup" --log-file=/var/log/rsync/rsync_$(date +"%Y-%m-%d").log -vtrz /opt/files/store/ <NAS-FQDN>:/files/backup/ >/dev/null 2>>/var/log/rsync/rsync.err

 

[Tommes]

@Stationary
Um es kurz zu machen. In meiner App Basic Backup habe ich die Einrichtung einer SSH Public Key Authentifizierung Schritt für Schritt in der integrierten Hilfe beschrieben. Du musst am Ende Basic Backup nicht nutzen, kannst das aber sicherlich tun um an dein Ziel zu kommen

Laut der von dir verlinkten Anleitung werden Änderungen in der sshd_config vorgenommen, die meines Wissens nicht nötig sind. Des weiteren werden hier die Schlüssel nicht für root, sondern für ein fiktives rsync-Benutzer Konto erstellt. Auch benötigst du zunächst keine Schlüsselpaare auf dem Remote Server, sondern müsstest nur den Public Key deiner Synology NAS in die .ssh/authorized_keys deines Pi's ablegen.

Vielleicht ist es einfacher, du versuchts es mal mit Basic Backup... und wenn nur zum Testen oder um dir anhand der Hilfe eine SSH-Verbindung einzurichten.

Ich würde das Sicherungs-Skript auf dem Pi laufen lassen. Somit wäre die Pi System (A) und die Synologie wäre System (B).
Also auf dem Pi ein ssh-keygen machen und dann in das Verzeichnis ~/.ssh/authorized_keys des Users kopieren, unter dem die Sicherung auf der Synology abgelegt weren soll. Das muss im Zweifel auch nicht der root sein!

Bei einem Push-Backup auf ein Synology NAS könnte man Probleme mit den Berechtigungen bekommen, da man sich nicht als root aufschalten kann. Daher würde ich in diesem Fall dem rsync vorsichtshalber ein --chmod=ugo=rwX mitgeben.

rsync -ah \
--stats \
--delete \
--backup --backup-dir=@recycle/$(date +"%Y-%m-%d_%Hh-%Mm-%Ss") \
--chmod=ugo=rwX  \
-e "ssh -p [SSHPORT] -i ~/.ssh/[PRIVATEKEY]" "[SOURCES]" [SSHUSER]@[SSHPUSH_TO]:"[TARGET]/" 2>&1

Ich persönlich würde daher ein Pull-Backup von der Synology NAS aus bevorzugen. Auch bleibt das NAS somit geschützt, da die SSH-Verbindung nur in Richtung Pi funktioniert, nicht jedoch umgekehrt. Aber das ist nur meine bescheidene Meinung.

Tommes

 

[Barungar]

Zu Synology kann ich nichts sagen... bei meinem QNAP habe ich es gerade von einer Ubuntu-VM probiert.
Ein rsync PUSH von der Ubuntu-VM auf das QNAP cross-user kein Problem.

Auf der Ubuntu-VM als User "root" den folgenden Befehl ausgeführt.
rsync -e "ssh -l <qnap user>" -vtrzp /root/rsync/ <qnap-FQN>:/share/Public/rsync

War ohne Probleme und alle "Test-Datein" wurden kopiert.

 

[Tommes]

Bei Synology läuft das (leider) etwas anders. Das fängt schon bei den Benutzer-Home-Ordnern an. Ich zitiere mal meine eigene Basic Backup Hilfe:

Hinweis:
Im Allgemeinen befindet sich auf allen Linux Distributionen der Home-Ordner des Systembenutzers root im Verzeichnis /root . Alle anderen Benutzer werden auf einer Synology NAS im Verzeichnis /volume[x]/homes unter Verwendung ihres jeweiligen Benutzernamens gruppiert. Das System leitet aus diesem Verzeichnis für jeden am System angemeldeten Benutzer einen virtuellen Benutzer-Home-Ordner ab, der sich unter /volume1/home befindet und stellt diesen zur Verfügung. Andere Linux Distributionen verwenden hier in der Regel den Ordner /home/[BENUTZERNAME]. Durch die Verwendung von ~/ verweist das System aber immer auf den Benutzer-Home-Ordner des aktuell angemeldeten SSH-Benutzers.

Eine weitere Eigenart von Synology NAS Systemen ist weiterhin (ebenfalls ein Zitat aus meiner Basic Backup Hilfe)...

Handelt es sich bei dem Remote Server um eine Synology NAS ist weithin darauf zu achten, das nur Benutzer aus der Gruppe der Administratoren eine SSH Verbindung aufbauen dürfen Eine SSH-Verbindung als Systembenutzer root kann dagegen nur aufgebaut werden, wenn im DSM das Standard admin Konto aktiviert ist.

(Wobei sich das Aktivieren des Standard admin Konto nur darauf bezieht, wenn man per Script oder Befehlskette eine SSH-Verbindung aufbauen möchte. Das Standard admin Konto sollte man aber tunlichst deaktivert lassen. Aufschalten per SSh als root geht mittels Public Key auch ohne aktiviertes admin Konto)

Auch ist es seit DSM 7 nicht mehr möglich über die GUI Befehle als root auszuführen. Das geht, wenn überhaupt, nur noch über den DSM Aufgabenplaner.

Ich weiß bestimmt nicht alles und mache sicherlich immer noch Fehler, aber ich habe mich mit dem Thema SSH, rsync vs. Synology schon ziemlich lange und intensiv beschäftigt und bin dabei schon über manch Stein gestolpert. Meine App "Basic Backup" ist so gesehen das Resultat aus all meinen Erfahrungen und die sagen halt... mach besser ein Pull-Backup und kein Push-Backup.

Die von mir geposteten rsync Befehle habe ich im übrigen grade von meiner Synology NAS aus auf eine Ubuntu Server 24.04 VM abgesetzt. Gleiches habe ich seinerzeit bereits mit diversen Raspberry Pi- sowie weiteren Synology NAS Systemen durchgetestet. Und falls es dich beruhigt @Barungar die Sache mit dem doppelten Doppelpunkt habe ich auch jahrelang falsch gemacht und musste auch erst darauf aufmerksam gemacht werden. Auch die Sache mit dem anhängen eines --chmod=ugo=rwX an ein Push-Backup ist das Ergebnis langjähriger try and error Versuche mit Synology.

Synology ist halt speziell und daher auch nicht mit QNAP zu vergleichen.

Tommes

 

[Barungar]

@Barungar die Sache mit dem doppelten Doppelpunkt habe ich auch jahrelang falsch gemacht und musste auch erst darauf aufmerksam gemacht werden.

Das hat nichts mit falsch zu tun... es geht beides. Mit einem doppelten-Doppelpunkt wird eben nur angezeigt, dass es kein "Verzeichnis" sondern ein "Rsync-Target" (aka Rsync-Module) ist. Damit hat man erweiterte Möglichkeiten auf dem Host konfigurierend einzugreifen und dem Client zum Beispiel gewisse Sachen nicht zu erlauben oder sonst noch was.

Und es geht beides, ohne dass auf dem Host dauerhaft ein rsync-daemon laufen muss und auf den rsync-Post lauscht.

Es ist halt die Frage, was man braucht... Die "erweiterten (vollen) Funktionen" von rsync oder ein simples Copy. Die Variante mit dem rsync-Target hat z.B. Vorteile, wenn die Bandbreite nicht so gut ist, und bei einem inkrementellen Dateiübertragung die Hashes bzw. Aufsetzpunkte berechnet werden.

Du hast in soweit Recht, dass bei den meisten Szenarien heute, da Bandbreite kein Problem ist, die Verzeichnisse einfach und simpler sind, weil man auf dem Host kein spezielles rsync-Target mehr extra konfigurieren muss. Ich bin aber ein altes Gewohnheitstier und vor 20 Jahren waren Bandbreiten noch was anderes, da war die Nutzung von rsync-Targets noch üblicher.

 

[Tommes]

Es ist halt die Frage, was man braucht...

... keep it simple lautet meine Devise, von daher beschränke ich mich auf den einfachen Doppelpunkt ohne rsync-Daemon. Aber ja... beides geht und ja... es ist auch nicht wirklich falsch... nur aufwendiger.

Wie dem auch sei... wir entfernen uns immer mehr vom eigentlichen Start-Thread und sollten einfach mal @Stationary entscheiden lassen, welchen Weg er gehen möchte.

 

[Tommes]

Aber wo du von Bandbreite sprichst, du damit aber sicherlich auf etwas anderes abzielen wolltest. Ich habe in Basic Backup zuletzt die Möglichkeit eingebaut, ein Tool namens ionice zu verwenden, welches die Bandbreite bzw. die Systemauslastung von rsync steuert. Nice, sag ich dir. Alternativ kann der Benutzer die Bandbreite aber über den rsync-Optionsschalter --bwlimit=[SPEEDLIMIT] selbst einstellen.

So. Schluss jetzt.

 

[blurrrr]

Da habe ich ja was losgetreten

Zu Synology kann ich nichts sagen

Das ist schon recht... speziell... teils werden altbekannte Dinge einfach rausgeworfen und durch neue "eigene" ersetzt. "man" gibt es z.B. einfach mal nicht. Ich hab nu schon länger nix mehr auf der Syno-Shell gemacht (einfach, weil es mir tierisch auf die Nerven geht), aber lustig ist halt echt anders... Keine Ahnung, wie das bei QNAP so läuft, aber Syno-Shell ist eher pfui als hui

Was wäre da Eurer Einschätzung nach die beste Vorgehensweise? Mit fstab einen Ordner der DS in den Pi5 mounten und dann einen cronjob cp laufen lassen?

rsync ist definitiv ein Thema, alternativ gibt es (statt mount+cp) auch noch scp (läuft via SSH und gibt es ebenfalls auf der Syno, kann man auch Daten mit remote holen). Man könnte statt eines Cronjob auch ein gewünschtes Verzeichnis via inotify überwachen lassen und sobald sich da etwas tut, wird ein entsprechender Job angestossen.

Falls Du das Backup von der Quelle auf das NAS schiebst und danach die Berechtigungen nicht stimmen sollten (hast z.B. keinen Zugriff auf die Daten von Deinem Rechner via SMB/CIFS aus), kannst Du auch noch einen weiteren Befehl remote hinterher schieben via SSH, das sieht dann z.B. so aus: ssh <User>@<NAS> "Befehl/e" (mehrere Befehle trennen via ";")

Gibt sicherlich auch noch anderweitige Möglichkeiten (nebst allem o.g.), aber es ist halt wie immer: Machen kann man vieles, ob und was Sinn für Dich macht, musst Du selbst entscheiden. Denke aber, dass der Weg via SSH schon mal nicht verkehrt ist. Kommt allerdings auch darauf an, was genau Du wegsichern willst. Wenn das ganze im Rahmen einer etwas aufwändigeren Sache passiert (z.B. lokal erstmal einen Datenbank-Dump erstellen und/oder Container runterfahren, wie auch immer), dann wäre evtl. in Summe ein kleineres Bash-Script von Vorteil (egal auf welcher Kiste). Die gewünschten Befehle kannst Du ja sowohl lokal, als auch remote via SSH ausführen und mittels SSH-Authentifizierung ohne Passwort lässt sich sowas dann auch gut automatisieren

EDIT: Kleiner Nachtrag: Wenn der Key vom Raspi auf die Syno wandert, kann man sicherlich auch ssh-copy-id nutzen, auf der Syno scheint es sowas natürlich wieder nicht zu geben. Wenn man das ohne den genannten Befehl mache möchte, würde sich z.B. sowas - nach Erzeugung des Keys - anbieten: $ cat /<userverzeichnis>/.ssh/id_rsa.pub | ssh user@host 'cat >> ~/.ssh/authorized_keys'. Ausführen ist der Befehl auf dem Host, der den Key generiert hat. Der kopiert seinen "öffentlichen" Key auf den Remote-Host zu welchem er sich dann verbinden möchte. <user>@<host> gibt dabei an, bei welchem User der Key dann auf dem Remote-System hinterlegt wird. Als Beispiel:

stationary@raspi:~# ssh-keygen
stationary@raspi:~# cat /home/stationary/.ssh/id_rsa.pub | ssh root@diskstation 'cat >> /root/.ssh/authorized_keys

Damit könnte sich der User Stationary auf dem Raspi einfach via "ssh root@diskstation" direkt auf der Syno anmelden. Natürlich kann man das Konstrukt auch einfach umdrehen und sich von der Syno auf den Raspi schalten, oder wie auch immer Du magst

 

[Stationary]

Das Basic Backup klingt natürlich verlockend, erfordert aber DSM 7. Aus bestimmten Gründen läuft die DS noch auf 6.2.4, die App fällt also aus. Ein in den Aufgabenplaner eingepaßtes rsync Script zum Pull vom Raspi ist wohl die beste Lösung.
Ich hatte auch schon mit mounts herumgespielt. Das Syno-Verzeichnis kann ich zwar in den Pi mounten, kann aber nichts darauf schreiben, trotz .smbcredentials, da stimmen also Berechtigungen nicht. Umgekehrt hatte ich versucht, ein Verzeichnis vom Pi in die Synology zu mounten, das hat gar nicht geklappt.
Das Ziel ist einen Paperless-Ordner vom RasPi5 auf dem Paperless-NGX läuft, auf die Diskstation zu sichern (und nein, mein Wunsch ist nicht, Paperless im Docker auf der DS laufen zu lassen, was natürlich auch ginge).

 

[Tommes]

Wenn du mir etwas Zeit gibst, kann ich dir gerne eine kurze Zusammenfassung aus meiner Basic Backup Hilfe zukommen lassen. Ich müsste aber schauen, inwieweit sich diese Anleitung auf DSM 6 übertragen ließe. Aus Mangel an DSM 6 könnte das etwas schwierig werden. Alternativ könntest du unter DSM 6 auch noch die App Ultimate Backup verwenden, wobei ich hier den Support bereits vor Jahren eingestellt habe. Auch wurden in Ultimate Backup viele Dinge noch anders gelöst… weil man da noch root Zugriff über die GUI hatte.