Eigentlich woll­te ich in die­sem Blogbeitrag beschrei­ben, wie ich das Erstellen einer Sicherheitskopie mei­nes Obsidian Vault, wel­ches ich bis­her hän­disch via Forklift ange­sto­ßen habe, mit der Hilfe von rsync und dem launchd-Framework auf mei­nem Mac auto­ma­ti­sie­re. Mit Forklift erstell­te ich eine inkre­men­tel­le Sicherheitskopie, also wur­den nur neue oder modi­fi­zier­te Dateien über­tra­gen. Ausserdem wur­den auch alle Dateien in der Sicherheitskopie gelöscht, die auch im Quellordner gelöscht wur­den. Dies soll­te nun auto­ma­tisch alle Stunde statt­fin­den.

Nachdem ich die ent­spre­chen­den Skripte und Befehle erstellt und beschrie­ben hat­te, fiel mir jedoch auf, dass das zeit­ge­steu­er­te und auto­ma­ti­sche Erstellen einer Sicherheitskopie eigent­lich kei­ne gute Idee ist, da ein ver­se­hent­li­ches Löschen einer Datei oder des Inhalts des Ordners dann auch beim nächs­ten Sicherungslauf auf der Synology nach­voll­zo­gen wird.

Daher habe ich den Blogartikel etwas modi­fi­ziert und beschrei­be nun, wie ich statt Forklift zu nut­zen, bei dem eini­ge Schritte aus­zu­füh­ren sind, das Ganze in einen Apple-Kurzbefehl ein­bin­de, den ich ein­fach in der Menüleiste auf­ru­fen kann.

Es ist aber ein wei­te­rer Artikel geplant, in dem ich, auch mit dem Befehl rsync dann ein wirk­li­ches auto­ma­ti­sches Backup erstel­le. Die Vorbereitungen wer­den aber gleich sein, nur der rsync-Aufruf muss dann etwas ange­passt wer­den. Was ich aber ger­ne vor einer ver­öf­fent­lich etwas tes­ten möch­te.

Vorgehensweise

• ssh und rsync müs­sen auf dem Mac instal­liert sein.
• Auf der Synology muss der Remote-Zugriff mit SSH akti­viert sein.
• Die SSH-Konfigurationsdatei muss ent­spre­chend ange­passt und der Schlüssel im Mac-Schlüsselbund hin­ter­legt wer­den.
• Das ent­spre­chen­de rsync-Kommando wird in einen Kurzbefehl gepackt

Schritt 1: SSH auf der Synology aktivieren

Zunächst soll­te sicher­ge­stellt wer­den, dass auf dem Mac ssh und rsync instal­liert sind. Dazu wird auf dem Mac ein Terminal Fester gestar­tet und fol­gen­de Befehle ein­ge­ben:

ssh -v localhost

und

rsync -V 

Beide Befehle soll­ten eigent­lich instal­liert sein. Falls nicht kön­nen sie mit home­brew nach­in­stal­liert wer­den.

Auf der Synology wird in der Systemsteuerung unter „Terminal & SNMP” der SSH-Dienst akti­viert:

Ausserdem muss noch die rsync-Option in den Datendiensten ange­schal­tet wer­den. Dies hat­te ich in einer ers­ten Version des Artikels noch ver­neint, kor­ri­gie­re mich aber hier­mit. Damit ist der Teil, der auf der Synology statt­fin­det, erle­digt. Als Test kann das Terminal auf­ge­ru­fen wer­den, um sich mit SSH mit der Synology zu ver­bin­den:

leif@mac:$ ssh 192.168.1.80
The authenticity of host '192.168.1.80 (192.168.1.80)' can't be established.
ED25519 key fingerprint is SHA256:Ob4Waq/MTrWU9wEvL/jENlP1/uMPk5/ibPYhJ6i9c94.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
yes
Warning: Permanently added '192.168.1.80' (ED25519) to the list of known hosts.
leif@192.168.1.80's password: 

Using terminal commands to modify system configs, execute external binary files, add files, or install unauthorized third-party apps may lead to system damages or unexpected behavior, or cause data loss. Make sure you are aware of the consequences of each command and proceed at your own risk.
Warning: Data should only be stored in shared folders. Data stored elsewhere may be deleted when the system is updated/restarted.

leif@Synology:$

Damit wird bei der ers­ten Verbindung mit dem Server via SSH ein Schlüssel als Fingerabdruck des Servers auf dem Computer hin­ter­legt, der unter ~/.ssh/known_hosts gespei­chert wird.

Schritt 2: SSH Konfiguration auf dem Mac

Damit eine SSH-Verbindung ohne Passworteingabe funk­tio­niert, sind eini­ge Schritte not­wen­dig. Das meis­te dazu habe ich mir „klas­sisch” durch Videos und ande­re Informationsquellen ange­eig­net. Sehr lehr­reich fand ich ein Video von Martin Leyrer, das ich nur emp­feh­len kann: Besser leben mit SSH — media.ccc.de. Die Vortragsvideos von Martin Leyrer kann ich gene­rell emp­feh­len.

Als ers­tes muss auf dem Mac ein SSH-Schlüssel-Paar erstellt wer­den. Dabei soll­te für jeden Server immer ein eige­nes Schlüssel-Paar erstellt wer­den:

ssh-keygen -a 420 -f ~/.ssh/synology-tutorial.ed25519 -C "My Synology Tutorial key"

Dieser Befehl erstellt einen pri­va­ten und einen öffent­li­chen Schlüssel mit dem ed25519-Verschlüsselungsalgorithmus. Die Option -a macht das Ganze etwas siche­rer, da eine wei­te­re Funktion ver­wen­det wird. Die Option -f defi­niert den Speicherort und den Namen, typi­scher­wei­se im Verzeichnis ~/.ssh (die Tilde steht für das Home-Verzeichnis). Die Option -C gibt dem Key einen Namen, womit spä­ter auf dem Server der Schlüssel iden­ti­fi­ziert wer­den kann. Bei der Generierung wird auch nach einer Passphrase gefragt. Hier soll­te ein siche­res Passwort ver­ge­ben wer­den, aber nicht ver­ges­sen, es sich zu mer­ken.

Wenn kein Fehler auf­tritt, wird eine Bestätigung ange­zeigt, die etwa so aus­sieht:

Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase): PASSWORD_EINGABE
Enter same passphrase again: PASSWORD_EINGABE
Your identification has been saved in /Users/leif/.ssh/synology-tutorial.ed25519
Your public key has been saved in /Users/leif/.ssh/synology-tutorial.ed25519.pub
The key fingerprint is:
SHA256:XXXXXXXxxxxxxxrXXXXXXXXXXXXXXXXXXXXXXXX My Synology Tutorial key
The key's randomart image is:
+--[ED25519 256]--+
|       .+hjjjs+..|
|         Bolls...|
|        jdjdj  +*|
|             *kd*|
|        a  s.  ..|
|       sss .aa . |
|        sasad   .|
|        .oso s . |
|         .=ss .  |
+----[SHA256]-----+

Das Verzeichnis ~/.ssh auf dem Mac soll­te dann etwa so aus­se­hen:

ls -la ~/.ssh
drwx------   5 leif  staff  160 17 Mai 17:44 .
drwxr-x---+ 18 leif  staff  576 17 Mai 17:32 ..
-rw-------   1 leif  staff  268 17 Mai 17:19 known_hosts
-rw-------   1 leif  staff  464 17 Mai 17:39 synology-tutorial.ed25519
-rw-r--r--   1 leif  staff  106 17 Mai 17:39 synology-tutorial.ed25519.pub

Es wur­de also ein pri­va­ter Schlüssel synology-tutorial.ed25519 und ein öffent­li­cher Schlüssel synology-tutorial.ed25519.pub erstellt. Der pri­va­te Schlüssel ist natür­lich auf dem Rechner zu behal­ten, wäh­rend der öffent­li­che Schlüssel nun auf die Synology kopiert wird:

ssh-copy-id -i ~/.ssh/synology-tutorial.ed25519.pub 192.168.1.80

Wobei die 192.168.1.80 die loka­le IP-Adresse mei­ner Synology ist. Hier könn­te auch der Servername ste­hen, falls im loka­len Netz die Namen vom DNS-Server auf­ge­löst wer­den. Da bei mir den Geräte fes­te IP-Adressen zuge­ord­net sind, neh­me ich an die­ser Stelle die IP-Adresse. Bei dem Aufruf benö­ti­ge ich kei­nen Benutzer-Namen, da ich auf bei­den System den glei­chen Namen nut­ze. Ansonsten müss­te der Benutzer-Name vom Server der IP-Adresse vor­an­ge­stellt wer­den.

Nachdem nun der öffent­li­che Schlüssel über­tra­gen wur­de, kann getes­tet wer­den, ob man sich mit dem Schlüssel anmel­den kann:

ssh -i ~/.ssh/synology-tutorial.ed25519 192.168.1.80

Da beim Generieren des Schlüssels ein Passwort ver­ge­ben wur­de, wird nun nach die­sem gefragt. Achtung; damit ist nicht das Benutzer-Passwort auf dem Server gemeint. Somit ist natür­lich nicht so viel gewon­nen, denn es wur­de so nur das eine Passwort durch ein ande­res ersetzt.

Um die Passwortabfrage zu ver­mei­den, wird eine klei­ne Datei im Verzeichnis ~/.ssh mit dem Namen config und dem fol­gen­dem Inhalt erstellt:

Host synology hugo
    HostName 192.168.1.80
    UseKeychain yes
    AddKeysToAgent yes
    User leif
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/synology-tutorial.ed25519

Mit die­ser Konfiguration kann eine SSH-Session auf mei­ner Synology ent­we­der mit den Befehlen ssh synology oder ssh hugo gestar­tet wer­den. Beim dem Parameter HostName habe ich die bei mir fest­ver­ge­be­ne IP-Adresse ange­ge­ben. Die Parameter UseKeychain und AddKeysToAgent stel­len zusam­men mit dem Mac-spe­zi­fi­schen Befehl:

ssh-add --apple-use-keychain ~/.ssh/synology-tutorial.ed25519

sicher, dass die Passphrase nicht mehr ein­ge­ge­ben wer­den muss, da sie nun sicher in der Schlüsselbundverwaltung gespei­chert ist.

Beim Nachvollziehen mei­ner Anleitung auf einem frisch in einer vir­tu­el­len Maschine instal­lier­ten macOS hat­te ich ein Problem mit den Rechten beim Aufruf des obi­gen Befehls, das bei der ers­ten Installation auf mei­nem Mac nicht auf­ge­tre­ten war:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/leif/.ssh/synology-tutorial.ed25519.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

Nach etwas Suche im Web fand ich als Problemlösung fol­gen­de Rechte-Einstellungen:

chmod 700 ~/.ssh

sowie

chmod 600 ~/.ssh/*

Nun soll­te schnell eine Session mit dem Aufruf von

 ssh synology

auf­ge­baut wer­den, ohne dass ein Passwort abge­fragt wird. Somit sind alle Vorbereitungen getrof­fen, das ent­spre­chen­de rsync-Kommando zu erstel­len.

Schritt 3: Das rsync-Kommando

Wie ich in der Einleitung schon erwähnt habe, nut­ze ich an die­ser Stelle rsync um eine ein­fa­che Sicherung mei­nes Obsidian Vault zu erstel­len. Mit dem fol­gen­den Befehl wird der loka­le Ordner 1:1 mit dem Ordner auf der Synology abge­gli­chen. Dabei wer­den nur Änderungen über­tra­gen, und Dateien, die im Quellordner gelöscht wur­den, wer­den auch im Zielordner gelöscht. Das hat den Vorteil, gera­de wenn man auch über das Netz, Sicherheitskopien machen möch­te, nicht immer der gan­ze Ordner kopiert wer­den muss.

In mei­nem Kontext war der Aufruf von rsync mit eini­gen Problemen behaf­tet, da der Befehl etwas zickig im Umgang mit Leerzeichen in einem Pfad ist. Auf der Quellseite reich­ten Anführungszeichen, wäh­rend auf der Zielseite zusätz­lich zu den dop­pel­ten Anführungszeichen auch ein­fa­che ver­langt wur­den, wor­auf ich erst nach lan­gem Forschen kam, da die Fehlermeldungen in die­sem Falle nicht ziel­füh­rend waren. Das Ergebnis der Bemühungen sieht für mein Beispiel so aus:

rsync -avz --delete --exclude "@eaDir" --filter "P @eaDir/" -e 'ssh' "/Users/leif/Documents/01 ObsidianNotes/" synology:"'/volume1/homes/leif/98 Backup/Obsidian/ObsidianNotes'"

Die Optionen -avz ste­hen für „archi­ve”, „ver­bo­se” und „com­press”, wobei die a-Option meh­re­re ande­re Optionen zusam­men­fasst, die sicher­stel­len, dass der gesam­te Ordner auch über­tra­gen wird. Die v-Option schal­tet eine erwei­ter­te Protokollierung an. Die z-Option kom­pri­miert die Daten wäh­rend der Übertragung, was viel­leicht im inter­nen Netz nicht so wich­tig ist.

--delete sorgt dafür, dass Dateien, die im Originalverzeichnis gelöscht wur­den, auch auf der Synology gelöscht wer­den. Daher erstellt die­ses Vorgehen kein Backup, son­dern nur eine 1:1 Kopie des Vaults. rsync bie­tet aller­dings auch wei­ter­ge­hen­de Optionen, wie zum Beispiel --backup zusam­men mit --backup-dir, die dann eher ein Backup erstel­len, auf die ich, wie oben ange­kün­digt, in einem wei­te­ren Artikel ein­ge­he.

--exclude "@eaDir" und --filter "P @eaDir/" habe ich ein­ge­führt, da mei­ne Synology alle Dateien inde­xiert und die­se Index-Dateien bei jedem Lauf des Befehls immer wie­der gelöscht wer­den und dann wie­der auf der Synology neu erstellt wer­den. Es gibt schein­bar kei­ne Möglichkeit gibt, ein­zel­ne Ordner von der Erstellung eines Indexes der Universal Search aus­zu­schlie­ßen, daher habe ich die­se Optionen gewählt.

-e 'ssh' spe­zi­fi­ziert, wel­ches „Remote-Shell-Programm“ für die Übertragung ver­wen­det wer­den soll. Alternativen wären unter ande­rem rsh oder telnet, die aber nicht so sicher sind wie ssh.

Als nächs­tes wird der Quellordner ange­ge­ben, wobei ich den gesam­ten Pfad spe­zi­fi­ziert habe. Da mein Quellordner im Pfad auch Leerzeichen hat, muss der Pfad von Anführungszeichen umschlos­sen wer­den:

"/Users/leif/Documents/01 ObsidianNotes/"

Der Zielpfad beginnt mit dem Rechnernamen, wie er in der ssh-con­fig-Datei defi­niert wur­de. Getrennt durch einen Doppelpunkt folgt der Zielordner, der auf­grund von Leerzeichen im Pfad in ein­fa­che und dop­pel­te Anführungszeichen ein­ge­schlos­sen wird:

synology:"'/volume1/homes/leif/98 Backup/Obsidian/ObsidianNotes'"

Der Befehl soll­te zunächst im Terminal getes­tet wer­den. Falls der Befehl im Terminal feh­ler­frei läuft, kann der Kurzbefehl in Angriff genom­men wer­den.

Der Kurzbefehl

Eigentlich dach­te ich, dass es ein­fach genü­gen wür­de, die Kommandozeile:

rsync -avz --delete --exclude "@eaDir" --filter "P @eaDir/" -e 'ssh' "/Users/leif/Documents/01 ObsidianNotes/" synology:"'/volume1/homes/leif/98 Backup/Obsidian/ObsidianNotes'"

In einen Kurzbefehl in die Aktion „Shell-Skript aus­füh­ren” zu kopie­ren und dann ein­fach über die Menüleiste aus­zu­füh­ren.

Das funk­tio­niert auch sehr gut, solan­ge die­ser Kurzbefehl mit dem Ausführen-Button im Automator aus­ge­führt wird. Aber wenn die­ser Kurzbefehl über das Menü auf­ge­ru­fen wird, gibt es eine Fehlermeldung: ‘rsync: open­dir „/Users/leif/Documents/01 ObsidianNotes/.” fai­led: Operation not per­mit­ted‘. Da ich das glei­che Problem mit der Ausführung eines Skripts im launchd-Framework hat­te, kann­te ich schon den Grund und auch die Lösung des Problems. Alle Programme, die einen Festplattenzugriff benö­ti­gen, müs­sen die­se Berechtigung in den Systemeinstellungen unter dem Punkt „Datenschutz und Sicherheit” erhal­ten. Da die Kurzbefehl-Anwendung und das Terminal die­se Berechtigung meist schon bei ers­ten Aufruf vom dem User bekom­men haben, läuft das Skript im Terminal und auch als Kurzbefehl, wenn er in der App gestar­tet wird. Wenn aber der Kurzbefehl über das Menü auf­ge­ru­fen wird, läuft er nicht mehr inner­halb der App und hat damit nicht die Berechtigung, auf die Festplatte zuzu­grei­fen. Leider ist es auch nicht mög­lich rsync die Berechtigung zu geben. Die Lösung, die ich am Ende in dem Beitrag „How to run a LaunchAgent that runs a script…” gefun­den habe, besteht dar­in, eine Programmhülse zu ver­wen­den, in der das Skript aus­ge­führt wird. MacOS ist mitt­ler­wei­le sehr restrik­tiv, was den Festplattenzugriff angeht und erlaubt nur, dass „rich­ti­gen” Programmen die­se Berechtigung gege­ben wer­den kann. Im Prinzip kann die­se Hülle in jeder Programmiersprache pro­gram­miert wer­den, die Programme erstellt. In dem oben genann­ten Artikel wer­den für Nicht-Programmierer Automator, der Script Editor oder ein Tool namens Platypus emp­foh­len.

Ich habe mich für die Automator-App ent­schie­den und dafür das Skript noch um eine Logging-Funktion erwei­tert, damit man even­tu­el­le Fehler nach­voll­zie­hen kann. Als Log-Datei habe ich eine lee­re Datei unter dem Ordner /tmp erstellt:

touch /tmp/vault-sicherung.log

Neben der Ausgabe des rsync-Aufrufs soll­te auch noch das Datum und die Uhrzeit in die Log-Datei schrei­ben geschrie­ben wer­de und so sieht das fer­ti­ge Skript aus:

echo -e "\n\n$(date +"%Y-%m-%d %H:%M:%S")" >> /tmp/vault-sicherung.log
rsync -avz --delete --exclude "@eaDir" --filter "P @eaDir/" -e 'ssh' "/Users/leif/Documents/01 ObsidianNotes/" synology:"'/volume1/homes/leif/98 Backup/Obsidian/ObsidianNotes'" >> /tmp/vault-sicherung.log

Mit echo -e "\n\n$(date +"%Y-%m-%d %H:%M:%S")" >> /tmp/vault-sicherung.log wer­den zunächst zwei lee­re Zeilen und dann der Zeitstempel in dem Format 2024-06-04 18:30:44 geschrie­be­nen und danach das Ergebnis der Ausführung des Kommandos. Das >> steht dabei für das Anhängen des Strings am ende der Log-Datei.

Nachdem nun das Skript fer­tig ist, wird Automator gestar­tet und ein neu­es Dokument erstellt. Dabei ist die Option „Programm” zu wäh­len.

n dem nun auf­ge­hen­den Fenster wird aus der Bibliothek die Aktion “Shell-Skript aus­füh­ren” in das Arbeitsablauffenster gescho­ben und dann das oben erstell­te Skript hin­ein­ko­piert.

Das Ganze wird nun noch­mal getes­tet, wobei man einen Blick auf die Log-Datei wer­fen soll­te. BTW: Bei jedem Test wird natür­lich schon eine Sicherheitskopie auf die Synology geschrie­ben. Falls also kei­ne Änderungen im Quellordner gemacht wur­den, wird auch nichts über­tra­gen. In die Log-Datei wird dann aber trotz­dem ein Eintrag gemacht, der etwa so aus­sieht:

2024-06-04 10:56:07
SERVER ist erreichbar. Starte rsync.
building file list ... done

sent 86782 bytes  received 20 bytes  57868.00 bytes/sec
total size is 193118530  speedup is 2224.82

Wenn alles läuft kann das Automator-Programm gespei­chert wer­den. Ich habe es unter dem Namen „SaveVault” im benut­zer­ei­ge­nen Programme-Ordner, der bei mir unter ~/Applications (im Finder unter leif -> Programme) zu fin­den ist.

Dieses Programm reicht bereits aus, um über einen Launcher wie Spotlight, Alfred.app oder Raycast auf­ge­ru­fen zu wer­den. Auch könn­te das Programm in das Dock gezo­gen wer­den und dort stän­dig im Zugriff sein. Mein Ziel war es jedoch, es mit einem Kurzbefehl in der Menüleiste zu star­ten. Deshalb muss noch die­ser Kurzbefehl erstellt wer­den. Dazu wird ein neu­er Kurzbefehl mit der Aktion „App öff­nen” erstellt. Als App wird dann „SaveVault” aus­ge­wählt:

Falls das Programm „SaveVault” nicht zur Auswahl steht, hilft es, das Programm ein­mal direkt zu star­ten und die Kurzbefehle-App danach neu zu star­ten.

Nun wird noch unter den Kurzbefehl-Optionen die Option “In der Menüleiste anzei­gen” akti­viert, der Kurzbefehl geschlos­sen — fer­tig. Beim ers­ten Aufruf über die Menüleiste muss fol­gen­der Dialog bestä­tigt wer­den, womit das Programm „SaveVault” auto­ma­tisch in die Liste der Programme mit dem Zugriff ein­ge­tra­gen wird:

Nun soll­te ein neu­er Eintrag in der Log-Datei ste­hen…

Falls Änderungen in dem Automator-Programm gemacht wer­den und das dann wie­der gestar­tet wird, erscheint der obi­ge Dialog zur Sicherheit wie­der.

Fazit

Nachdem ich nun die­sen Kurzbefehl habe, kann ich ein­fach per Menüeintrag eine Sicherheitskopie von mei­nem Obsidian Vault machen, wozu vor­her eini­ge manu­el­le Schritte not­wen­dig waren, da Forklift nicht über die Kurzbefehle App gesteu­ert wer­den kann.

Meine bis­he­ri­gen Versuche, ein rsync-Skript zu schrei­ben, waren bis­her durch das Fehlen der rich­ti­gen Optionen im Zusammenhang mit der Synology nicht erfolg­reich.
Dieses Problem, wenn es nicht nur mei­ne eige­ne Unfähigkeit war, konn­te ich nun lösen.

Meine bis­he­ri­gen Shortcuts, mit denen ich Daten auf der Festplatte mani­pu­liert hat­te, lie­fen immer im Kontext von Anwendungen, die die­se Berechtigung hat­ten, so dass ich es vor­her nie bemerkt hat­te. Jetzt habe ich eine Lösung für die­ses Problem.

So, soweit die­ser ers­te Teil, der dann viel­leicht doch eher eine Fingerübung dar­stellt, die Ergänzung, wie man ein rich­ti­ges Backup eines Ordners erstellt, wer­de ich in den nächs­ten Tagen ver­öf­fent­li­chen.

Bis dahin freue ich mich über Korrekturen, Feedback und wei­te­re Ideen in den Kommentaren.