Aktualisieren und nicht Spiegeln

JAARS und das Freefilesync kenne ich nicht, aber rsync mit dem Schalter -a macht genau das was FFS "Aktualisieren" nennt. Mit dem weiteren Schalter --delete löscht rsync im Ziel files die auch in der Quelle gelöscht wurden. JAARS ist ein script(?). Schau einfach mal rein welche Schalter es bei rsync setzt.

Wwa1 vom User Tommes

File

jarss (just another rsync shell script)

Bei jarss handelt es sich um ein CLI-basiertes Shell-Skript, das rsync verwendet, um Daten zwischen lokalen Pfaden oder Pfaden, auf die über das Netzwerk mit SSH-Public-Key-Authentifizierung zugegriffen werden kann, zu übertragen. Neben einer synchronen Datensicherung mit optionalem Löschschutz unterstützt jarss auch eine versionierte, inkrementelle Datensicherung.

Tommes

April 26, 2026 at 11:47 AM

Ich verwende jaars nicht, sondern verwende nur meine eigenen, selbst geschrieben Scripte. Da weiß ich was die machen und wie die funktionieren. 👍

Es sollte ein Hinweis sein ("kenn ich nicht"). Ansonsten hat Tommes alles auf gihub und ja, es funktioniert auch.

Muss ich halt in Zukunft genauer formulieren. Natürlich habe ich von jaars hier schon gelesen, aber ich verwende es nicht und kenne es daher nicht. Und da ich eigene Scripte verwende sehe ich auch keinen Bedarf für mich.

Quote from Wwa1

Ich […] verwende nur meine eigenen, selbst geschrieben Scripte. Da weiß ich was die machen und wie die funktionieren.

Genau aus diesem Grund habe ich jarss geschrieben, auch wenn ich mich nicht ausschließlich darauf fixiere. Ich nutze parallel dazu auch Sync & Backup.

deltapapa jarss bietet keine Echtzeitsynchronisation, sondern eine synchrone oder eine versionierte, inkrementelle Datensicherung. Beide Funktionsweisen werden auf meiner GitHub Seite beschrieben.

Es gibt natürlich "1000 Möglichkeiten", aber eine einfache Lösung ist, alle Ausgaben in ein File umzulenken, irgendwo am Scriptanfang einfügen:

# Alle Ausgaben und Fehlermeldungen in Logfiles umlenken
LOGFILE="/home/username/mein-script.log"
exec >> "$LOGFILE" 2>&1

Quote from deltapapa

Eigentlich macht rsync von Haus aus ja genau das, was ich brauche.

Ich weiß zwar nicht, warum du versuchst das Rad neu zu erfinden, anstatt einfach jarss zu benutzen, denn jarss macht am Ende auch nur rsync. Aber gut, wenn das dein Weg ist.

Bei jarss wird die Logausgabe sowohl in eine Datei geschrieben, zusätzlich dazu aber auch direkt auf der Kommandozeile ausgegeben. Daher läuft das alles über den tee Befehl

echo "Log-Info" | tee -a "${logfile}"

Das nur als Beispiel. Wenn man auf der Kommandozeile den Schalter --info=progress2 beim Skriptaufruf mit angibt, erhält man einen Statusbalken, wo rsync steht.

Aber okay! Scheinbar ist jarss nichts für dich, daher wünsche ich dir viel Erfolg beim selber Skripten.

Dann dürfte dich mein neuestes Skript „Öffentlichen RSA-Schlüssel generieren und senden“ sicherlich auch nicht mehr interessieren, was ich u.a. wegen Benutzern wie dir geschrieben habe.

Sei‘s drum

Quote from deltapapa

Ich hoffe ich konnte das irgendwie erklären.

Da bin ich mir grad nicht sicher. Vermutlich kann man, wenn man an den richtigen Schrauben dreht, jarss so anpassen bzw. umschreiben, das es deinen Wünschen und Vorstellungen entspricht. Es ist aber eigentlich nicht mein Ziel, jarss für alles und jeden so anzupassen, um den Bedürfnissen anderer gerecht zu werden.

Es hindert dich aber niemand daran, es selbst zu versuchen. Oder natürlich, wie du grade im Begriff zu tun, selbst ein Skript zu schreiben. Scheinbar funktioniert es ja bereits und du feilst jetzt an den Feinheiten.

Wenn ich ganz viel Lust und Zeit habe, kann ich mir dein Skript gerne man anschauen und um eine Log-Funktion erweitern. Sowas kann bei mir entweder schnell gehen oder auch nie passieren … von daher erwarte mal nicht zu viel von mir. Wobei… bei den paar Zeilen sollte das recht einfach und schnell umzusetzen sein.

Quick and dirty...

Ausgabe erfolgt sowohl auf der Kommandozeile als auch im Logfile.

#!/bin/bash

# Definition von Quelle (lokal) und Ziel (remote)
SOURCE_DIR="/volume2/temp/"
REMOTE_USER="deltapapa"
REMOTE_HOST="192.168.10.100"
REMOTE_DEST_DIR="/volume1/backup_temp/"

# Funktion: Aktueller Zeitstempel
timestamp() {
    date +"%Y-%m-%d %H:%M:%S"
}

# Erstelle ein Logfile und speicher es dort, wo das rsync-Skript liegt. 
absolute_path=$(dirname -- $(readlink -fn -- "$0"))
logfile="${absolute_path}/Logfile.log"
[ -f "${logfile}" ] && rm -f "${logfile}"
[ ! -f "${logfile}" ] && install -m 777 /dev/null "${logfile}"

echo "$(timestamp) - Starte Remote-Synchronisierung" | tee -a "${logfile}"

# Rsync-Befehl über SSH
# -e ssh: Gibt SSH als Remote-Shell an
# -z: Komprimiert die Daten während der Übertragung (nützlich für Netzwerkübertragungen)
# -a: Archivmodus (rekursiv, erhält Berechtigungen, Zeitstempel, Eigentümer etc.)
# -v: Ausführliche Ausgabe (zeigt, was passiert)
# --delete: Löscht Dateien im Ziel, die in der Quelle nicht mehr existieren (Spiegelung)
# --dry-run: (Optional) Simuliert den Vorgang nur, ohne tatsächlich Daten zu kopieren/löschen
rsync -ah --stats -e ssh "$SOURCE_DIR" "$REMOTE_USER@$REMOTE_HOST:$REMOTE_DEST_DIR" > >(tee -a "${logfile}") 2>&1
echo "$(timestamp) - Remote-Synchronisierung abgeschlossen." | tee -a "${logfile}"

Uiui, das mit dem Mailversenden ist größer als alles andere 😉 😁

Ist aber aber auch klar, da gibt es eine Menge an Parametern zu berüchsichtigen. Es hatte mich nur etwas verwundert, wie viele das sind. Ich hab ja auch so was ähnliches geschrieben, aber das läuft dann nur Firmen intern und da braucht man viele der Parameter gar nicht, weil da klar ist, wer das, unter welchem Namen veröffentlicht.

Alles gut, Danke für Deine Mühe 👍😁