mathias2784/it-know-how
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
aeffb66466bc2187e94b79f46fef203830ab7efe
it-know-how/Linux/Synchronisation & Backup.md
T

11 KiB
Raw Blame History

Alles klar – ich gebe dir eine ausführliche Übersicht über Dateisynchronisation und Backups unter Linux, gegliedert nach typischen Anwendungsfällen (1-way Backup, 2-way Sync, Spezialfälle). Dazu zeige ich dir jeweils interessante Funktionen, geeignete Tools und Code-Beispiele, die du direkt ausprobieren kannst.

🔧 Dateisynchronisation und Backup unter Linux

1. Grundsätzliche Anwendungsfälle

  1. Backup (1-way Synchronisation)

    • Ziel: Sicherung von Daten von Quelle → Ziel.

    • Änderungen im Quellordner werden ins Ziel kopiert.

    • Änderungen im Ziel haben keine Wirkung zurück.

    • Typisch für:

      • Regelmäßige Datensicherungen (lokal oder auf Server/NAS)

      • Snapshots und inkrementelle Backups

  2. Zwei-Wege-Synchronisation (2-way)

    • Ziel: Quell- und Zielordner sind identisch.

    • Änderungen in beiden Richtungen werden abgeglichen.

    • Typisch für:

      • Zusammenarbeit zwischen Geräten

      • Synchronisation von Arbeitsordnern mit Netzwerkfreigaben oder Cloud

  3. Weitere Anwendungsbeispiele

    • Offsite-Backup (z. B. automatisches Backup auf einen entfernten Server via SSH)

    • Versionierte Backups (Aufbewahrung älterer Stände)

    • On-the-fly Synchronisation (z. B. Watcher, der beim Speichern sofort sync’ed)

    • Mobile Synchronisation (z. B. Laptop ↔ NAS, USB-Stick ↔ Rechner)

2. Tools für 1-way Backups

a) rsync (Klassiker)

Das meistgenutzte Werkzeug, effizient und flexibel.

Einfaches Backup:

rsync -avh /home/user/Dokumente/ /media/backup/Dokumente/

  • -a = Archivmodus (erhält Rechte, Zeiten, Links)

  • -v = verbose

  • -h = menschenlesbare Größen

Mit Löschen (Spiegelung):

rsync -avh --delete /home/user/Dokumente/ /media/backup/Dokumente/

→ Dateien, die in Quelle gelöscht wurden, werden auch im Ziel gelöscht.

Über SSH (z. B. auf NAS oder Server):

rsync -avz /home/user/Dokumente/ user@server:/backup/Dokumente/
  • -z = Kompression

Interessante Funktionen:

  • --exclude "*.tmp" → bestimmte Dateien ignorieren

  • --progress → Fortschrittsanzeige

  • --link-dest → inkrementelle Backups mit Hardlinks (ähnlich Time Machine)

b) borgbackup (für versionierte, komprimierte, verschlüsselte Backups)

Ideal für langfristige Backups mit Versionierung.

borg init --encryption=repokey /media/backup/repo
borg create --progress /media/backup/repo::2025-09-26 /home/user/Dokumente

Später kannst du ältere Versionen wiederherstellen.

3. Tools für 2-way Synchronisation

a) unison

Ein Klassiker für bidirektionale Synchronisation.

Einfacher Start:

unison /home/user/Dokumente ssh://user@server//home/user/Dokumente

  • Erkennt Änderungen auf beiden Seiten

  • Fragt bei Konflikten nach

  • Arbeitet ähnlich wie rsync, aber beidseitig

Dauerhafte Konfiguration:
In ~/.unison/default.prf:

root = /home/user/Dokumente
root = ssh://user@server//home/user/Dokumente
auto = true
batch = true

Dann reicht:

unison

b) Syncthing (komfortabel mit Weboberfläche)

  • Peer-to-Peer Synchronisation (Ende-zu-Ende verschlüsselt)

  • Cross-Platform (Linux, Windows, Android, macOS)

  • Ideal für nahtlose Syncs ohne manuellen Eingriff

Installation:

sudo apt install syncthing
syncthing

→ Startet Weboberfläche auf http://127.0.0.1:8384

4. Automatisierung

a) Cron-Jobs für regelmäßige Backups

Beispiel: Täglich um 3 Uhr ein rsync-Backup:

0 3 * * * rsync -avh --delete /home/user/Dokumente/ /media/backup/Dokumente/

(crontab -e)

b) systemd Timer (moderner als Cron)

Service-Unit (/etc/systemd/system/backup.service):

[Unit]
Description=Backup Dokumente

[Service]
ExecStart=/usr/bin/rsync -avh --delete /home/user/Dokumente/ /media/backup/Dokumente/

Timer (/etc/systemd/system/backup.timer):

[Unit]
Description=Backup Timer

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Aktivieren:

sudo systemctl enable --now backup.timer

5. Zusammenfassung der interessantesten Funktionen

  • rsync → universell, effizient, für Backups und Spiegelungen

  • borgbackup → versioniert, verschlüsselt, platzsparend

  • unison → 2-way Sync mit Konfliktlösung

  • syncthing → benutzerfreundlich, kontinuierliche Synchronisation

👉 Tipp:
Wenn du nur Backups brauchst → rsync oder borg.
Wenn du aktive Ordner synchron halten willst → unison oder syncthing.

Soll ich dir zum Einstieg ein komplettes Setup-Skript für ein automatisches tägliches Backup mit rsync schreiben, das du direkt verwenden kannst? Sehr gute Fragen 👍 — ich gehe das mit dir systematisch durch.

🔄 Unison: Verhalten, Hintergrundbetrieb & Performance

1. Läuft Unison permanent im Hintergrund?

Unison an sich ist kein permanenter Daemon wie etwa Syncthing.
Es funktioniert normalerweise so:

  • Du startest Unison → es vergleicht Quelle und Ziel → synchronisiert → beendet sich.

  • Du kannst es per Cron, systemd-Timer oder manuell regelmäßig ausführen.

  • Es gibt aber einen "Unison-GUI/Repeat-Modus", bei dem es in einer Schleife läuft und z. B. alle 10 Sekunden die Verzeichnisse prüft.

Beispiel für wiederholte Synchronisation:

unison default -repeat watch

  • -repeat watch = Unison nutzt OS-Funktionalitäten (inotify auf Linux), um Änderungen sofort zu erkennen.

  • -repeat 10 = alternativ: Polling alle 10 Sekunden.

Damit verhält sich Unison fast wie Syncthing, aber ist weniger komfortabel, weil es keinen richtigen Daemon hat.

2. Start bei Systemstart

Damit Unison automatisch startet, kannst du es mit systemd einrichten.

Beispiel: systemd Service-Datei

~/.config/systemd/user/unison.service

[Unit]
Description=Unison sync service
After=network.target

[Service]
ExecStart=/usr/bin/unison default -repeat watch
Restart=always
RestartSec=5

[Install]
WantedBy=default.target

Dann aktivieren:

systemctl --user enable --now unison.service

→ Jetzt läuft Unison beim Login des Users automatisch und überwacht die definierten Profile.

3. Performance Impact

Die Performance hängt von der Betriebsart ab:

  • Einmalige Ausführung (Standard)

    • Minimaler Impact, nur während der Synchronisation.

    • Nutzt Hashing/Datei-Checksummen, um Änderungen effizient zu erkennen.

    • Bei großen Verzeichnissen ist der erste Lauf teuer (voller Indexaufbau), danach werden nur Änderungen geprüft.

  • Dauerbetrieb mit -repeat watch

    • Nutzt inotify → kaum CPU-Last, da nur Änderungen getriggert werden.

    • Speicherbedarf: wenige Dutzend MB RAM.

    • CPU-Last: fast 0, außer wenn aktiv synchronisiert wird.

  • Dauerbetrieb mit -repeat 10 (Polling)

    • Alle 10 Sekunden kompletter Scan → deutlich mehr I/O bei vielen Dateien.

    • Sollte nur verwendet werden, wenn inotify nicht funktioniert (z. B. bei Netzwerk-Dateisystemen).

Kurz:

  • Lokale Ordner: -repeat watch → sehr effizient

  • Netzwerk-Mounts (NFS, SMB): oft kein inotify → Polling nötig, etwas schwerer

4. Fazit

  • Unison ist keine Always-on-Synchronisation wie Syncthing, aber mit -repeat watch + systemd lässt es sich quasi gleichwertig nutzen.

  • Performance-Impact ist sehr gering, solange du watch nutzt.

  • Für regelmäßige Backups → Cron oder systemd Timer reicht.

  • Für nahezu Echtzeit-Sync → -repeat watch + systemd Service ist die beste Lösung.

1. Voraussetzung: Config-Datei

Ja, korrekt ✅
Der Aufruf

unison default -repeat watch

setzt voraus, dass du eine Konfigurationsdatei ~/.unison/default.prf hast.
Dort definierst du z. B.:

root = /home/user/Dokumente
root = ssh://user@server//home/user/Dokumente

auto = true
batch = true

  • auto = true → versucht, Konflikte automatisch zu lösen (kein Nachfragen bei eindeutigen Fällen).

  • batch = true → führt ohne Interaktion aus.

    • Falls Konflikte auftreten, entscheidet er nach den Regeln oder verweigert Sync.

    • Ohne batch würdest du wieder Fragen im Terminal sehen.

👉 Empfehlung: Für systemd immer auto = true und batch = true setzen, sonst blockiert der Prozess.

2. Rückfragen vermeiden (Default-Verhalten)

Wie du beobachtet hast, fragt Unison bei unison [quelle] [ziel] ohne Konfig bei Konflikten („Welche Version behalten?“).

  • Mit Konfig + batch + auto → keine Rückfragen.

  • Du kannst zusätzlich Regeln setzen, z. B.:

prefer = newer       # Immer die neuere Version behalten
prefer = /home/user  # Lokale Version gewinnt

Das ist wichtig für den systemd-Einsatz, weil ein Dienst nicht sinnvoll auf Eingaben warten kann.

3. Logging

a) Standardmäßig

Unison schreibt keine dauerhaften Logs von sich aus.
Die Ausgaben gehen in stdout/stderr → wenn du es manuell startest, siehst du es im Terminal.

b) Mit systemd

systemd fängt alles auf → mit

journalctl --user -u unison.service

siehst du die Logs.
Wenn dir das reicht, brauchst du nichts extra.

c) Eigene Logdateien

Du kannst in der .prf-Datei angeben:

log = /var/log/unison/unison.log

oder direkt beim Start per ExecStart:

ExecStart=/usr/bin/unison default -repeat watch -logfile /var/log/unison/unison.log

d) Alte Logs automatisch löschen

Unison selbst rotiert keine Logs, aber systemd oder logrotate kann das übernehmen.
Beispiel logrotate-Konfig (/etc/logrotate.d/unison):

/var/log/unison/unison.log {
    daily
    rotate 30
    compress
    missingok
    notifempty
    create 640 user user
}

→ Hält 30 Tage Logs, dann werden sie komprimiert/gelöscht.

Wenn du lieber pro Sitzung in /tmp loggen willst:

ExecStart=/usr/bin/unison default -repeat watch -logfile /tmp/unison-%u.log

und ein Cronjob/systemd-Timer löscht alte Dateien:

find /tmp -name 'unison-*.log' -mtime +30 -delete

4. Fazit

  • Ja, Config-Datei nötig → dort Batch/Auto einstellen.

  • Default-Verhalten einstellen mit prefer-Regeln, sonst blockieren Konflikte.

  • Logs: systemd-Journal reicht oft, alternativ eigene Logdatei + logrotate.

👉 Soll ich dir eine komplette Beispielkonfig default.prf + passende systemd-Service-Datei basteln, die direkt „Headless-Sync im Hintergrund“ macht inkl. Log-Rotation?

Reference in New Issue View Git Blame Copy Permalink