6
Verzeichnissynchronisierung mit lsyncd unter Ubuntu
Inhaltsverzeichnis
Hier und da möchte man als Entwickler ein Verzeichnis mehrfach und gleichzeitig synchronisieren, z.B. wenn eine neue Datei in das Verzeichnis geschrieben wurde. Und das natürlich in (fast) Echtzeit ohne große Verzögerung. In der Webentwicklung kommt das oft vor.
Hier meine ressourcenschonende Lösung für eine mehrfache Synchronisation z.B. von Verzeichnis /srv/www/original/src auf web1 und gleichzeitig auf web2:
/srv/www/original/src
sync auf -> /srv/www/web1/src/
sync auf -> /srv/www/web2/src/Ich benutze für die Synchronisierung das Tool lsyncd (Live Syncing Daemon). Das gibt es für fast jede Linux Distribution und macOS.
Was ist lsyncd?
Lsyncd (Live Syncing Daemon) ist ein leistungsstarkes Tool zur Echtzeit-Synchronisierung von Verzeichnissen auf Linux- und macOS-Systemen. Anders als herkömmliche Synchronisierungstools wie rsync, überwacht lsyncd kontinuierlich Änderungen in deinen Verzeichnissen und synchronisiert diese nahezu in Echtzeit. Es nutzt das inotify-Subsystem des Linux-Kernels, um Dateisystemereignisse zu erkennen und die Synchronisierung nur bei tatsächlichen Änderungen auszulösen, was es besonders ressourcenschonend macht.
Installation
sudo apt install lsyncd # Debian/Ubuntu
systemctl enable lsyncdInstallation testen:
lsyncd --versionBeispielausgabe:
Version: 2.2.3Konfiguration
Da es nach der Installation keine Beispielkonfiguration in "/etc" gibt, müssen wir zuerst herausfinden, wie sie unter Ubuntu heißt. Diese Information findet man in "/etc/init.d/lsyncd".
cat /etc/init.d/lsyncd | grep CONFIG=Beispielausgabe:
CONFIG=/etc/lsyncd/lsyncd.conf.luaUnter Ubuntu lautet die Konfigurationsfile: /etc/lsyncd/lsyncd.conf.lua (bei Fedora: /etc/lsyncd.conf). Nun erstellen wir die Konfigurationsdatei neu:
vi /etc/lsyncd/lsyncd.conf.luaIm folgenden Beispiel werden die Verzeichnisse: css/ und js/ ausgeschlossen, da diese automatisch erzeugt werden.
settings {
logfile = "/var/log/lsyncd.log",
statusFile = "/var/log/lsyncd-status.log"
}
-- Verzeichnisse synchronisieren
sync {
default.direct,
source = "/srv/www/original/src/",
target = "/srv/www/web1/src/",
delay = 1,
exclude = {"css/*", "js/*"}
}
sync {
default.direct,
source = "/srv/www/original/src/",
target = "/srv/www/web2/src/",
delay = 1,
exclude = {"css/*", "js/*"}
}Erstmalige Synchronisierung
Um zu vermeiden, dass bei der ersten Synchronisation alles mit "lsyncd" synchronisiert wird, starten wir eine erste Synchronisation mit "rsync", um die Verzeichnisse zu füllen. Das geht schneller.
mkdir /srv/www/web1/src/
rsync -av --delete --exclude="css/" --exclude="js/" /srv/www/original/src/ /srv/www/web1/src/
mkdir /srv/www/web2/src/
rsync -av --delete --exclude="css/" --exclude="js/" /srv/www/original/src/ /srv/www/web2/src/ Mit der neuen Konfiguration starten:
sudo systemctl restart lsyncdStatus:
sudo systemctl status lsyncdBeispielausgabe:
● lsyncd.service - LSB: lsyncd daemon init script
Loaded: loaded (/etc/init.d/lsyncd; generated)
Active: active (running) since Tue 2025-03-18 12:44:25 CET; 3h 22min ago
Docs: man:systemd-sysv-generator(8)
Process: 246897 ExecStart=/etc/init.d/lsyncd start (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 115371)
Memory: 512.0M
CPU: 3.791s
CGroup: /system.slice/lsyncd.service
└─246905 /usr/bin/lsyncd -pidfile /var/run/lsyncd.pid /etc/lsyncd/lsyncd.conf.lua
Mär 18 12:44:25 ares systemd[1]: Starting LSB: lsyncd daemon init script...
Mär 18 12:44:25 ares lsyncd[246897]: * Starting synchronization daemon lsyncd
Mär 18 12:44:25 ares lsyncd[246904]: 12:44:25 Normal: --- Startup, daemonizing ---
Mär 18 12:44:25 ares lsyncd[246897]: ...done.
Mär 18 12:44:25 ares systemd[1]: Started LSB: lsyncd daemon init script.Überwachung und Status
Logfile überprüfen:
tail -f /var/log/lsyncd.logStatus:
tail -f /var/log/lsyncd-status.logFazit
Lsyncd bietet eine hervorragende Performance für die Synchronisation von Verzeichnissen in nahezu Echtzeit. Durch die ereignisbasierte Überwachung werden Änderungen sofort erkannt und mit minimaler Verzögerung synchronisiert, was es ideal für Entwicklungsumgebungen und Produktionsserver macht. Die Ressourcennutzung bleibt dabei minimal, da nur bei tatsächlichen Änderungen eine Synchronisierung stattfindet. Die Synchronisierung funktioniert nicht nur lokal, sondern kann auch zwischen Servern eingerichtet werden. Für Webentwickler, die mit mehreren Servern oder Verzeichnissen arbeiten, ist lsyncd ein unverzichtbares Werkzeug, das dir viel manuelle Arbeit erspart und für konsistente Daten über mehrere Systeme hinweg sorgt.
Bei Fragen oder Ergänzungen einfach hier einen Kommentar schreiben.
Gruß
Frank
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672028
Url: https://administrator.de/tutorial/verzeichnissynchronisierung-mit-lsyncd-unter-ubuntu-672028.html
Ausgedruckt am: 17.04.2025 um 18:04 Uhr
6 Kommentare
Neuester Kommentar
Moin,
Vorsicht: Das ist auch ein sehr schnelle Methode Fehler bzw fehlerhafte Dateien auf mehrere Server zu verteilen.
lks
Vorsicht: Das ist auch ein sehr schnelle Methode Fehler bzw fehlerhafte Dateien auf mehrere Server zu verteilen.
lks
Muss ich mir mal ansehen.
Nutzen Debian für immutable Backup. Da die Backup Software (Misch-Masch) es nicht hergibt. Liege da bei großen Dateien so bei 4-6 Gigabit. Zumindest wenn man mal auf die Grafik schaut.
Nutze PowerShell 7 unter Debian + rsync zum Kopieren. Durch parallel Task verarbeitet es 4 Aufträge parallel. Mehr macht wegen der Lese-Geschwindigkeit keinen Sinn.
Überlege gerade ob ich lsyncd da sinnvoll einsetzen kann.
Nutzen Debian für immutable Backup. Da die Backup Software (Misch-Masch) es nicht hergibt. Liege da bei großen Dateien so bei 4-6 Gigabit. Zumindest wenn man mal auf die Grafik schaut.
Nutze PowerShell 7 unter Debian + rsync zum Kopieren. Durch parallel Task verarbeitet es 4 Aufträge parallel. Mehr macht wegen der Lese-Geschwindigkeit keinen Sinn.
Überlege gerade ob ich lsyncd da sinnvoll einsetzen kann.
Hi
Dies ist natürlich nicht als Backup-Lösung gedacht. Entwickler brauchen das oft, z.B. wenn sie mehrere Programmierungen oder Konfigurationen mit den gleichen Daten testen wollen. Oder wenn man z.B. eine Test- und eine Stage-Umgebung hat und in beiden die gleichen Images vorhanden sein sollen.
Gruß
Frank
Vorsicht: Das ist auch ein sehr schnelle Methode Fehler bzw fehlerhafte Dateien auf mehrere Server zu verteilen.
Dies ist natürlich nicht als Backup-Lösung gedacht. Entwickler brauchen das oft, z.B. wenn sie mehrere Programmierungen oder Konfigurationen mit den gleichen Daten testen wollen. Oder wenn man z.B. eine Test- und eine Stage-Umgebung hat und in beiden die gleichen Images vorhanden sein sollen.
Gruß
Frank
Zitat von @Frank:
Hi
Dies ist natürlich nicht als Backup-Lösung gedacht. Entwickler brauchen das oft, z.B. wenn sie mehrere Programmierungen oder Konfigurationen mit den gleichen Daten testen wollen. Oder wenn man z.B. eine Test- und eine Stage-Umgebung hat und in beiden die gleichen Images vorhanden sein sollen.
Hi
Vorsicht: Das ist auch ein sehr schnelle Methode Fehler bzw fehlerhafte Dateien auf mehrere Server zu verteilen.
Dies ist natürlich nicht als Backup-Lösung gedacht. Entwickler brauchen das oft, z.B. wenn sie mehrere Programmierungen oder Konfigurationen mit den gleichen Daten testen wollen. Oder wenn man z.B. eine Test- und eine Stage-Umgebung hat und in beiden die gleichen Images vorhanden sein sollen.
Weiß ich doch, deswegen auch der Smiley. Ich wollte nur die andren darauf hinweisen, dass man mit solchen Tools sich auch das System zerschießen kann, wenn man sie unbedacht einsetzt.
lks
Zitat von @Frank:
Dies ist natürlich nicht als Backup-Lösung gedacht. Entwickler brauchen das oft, z.B. wenn sie mehrere Programmierungen oder Konfigurationen mit den gleichen Daten testen wollen. Oder wenn man z.B. eine Test- und eine Stage-Umgebung hat und in beiden die gleichen Images vorhanden sein sollen.
Dies ist natürlich nicht als Backup-Lösung gedacht. Entwickler brauchen das oft, z.B. wenn sie mehrere Programmierungen oder Konfigurationen mit den gleichen Daten testen wollen. Oder wenn man z.B. eine Test- und eine Stage-Umgebung hat und in beiden die gleichen Images vorhanden sein sollen.
Ja, schon klar. Überraschenderweise haben wir sogar Test- und Stageumgebung. Sind aktuell nur 2 Mann. Mein Kollege entwickelt hauptsächlich.
Nutzt Du das lsyncd nun vermehrt oder nur unter bestimmten Bedingungen? Aktuell hatten wir Diskussion wie man Scripte u.ä. außer git noch verwalten kann. Es gibt ja ganze Frameworks, die automatische Tests drüber laufen lassen und dann erst den Code auf die Menschheit los lassen.
Wie du schon sagtest, fällt das ja bei sowas wie lsyncd komplett weg. Quick and Dirty. Wir sind aber so klein aufgestellt, dass ich es da nicht schlechte finde.
Spotify bietet ja auch so einiges: https://backstage.spotify.com/
Ist nur mehr nicht passend für uns. Die Größe mit 2 Mann, die ich vorhin genannt hab, ist kein Witz. Ich verstehe in bestimmten Umgebungen ja die Notwendigkeit von Backstage und wie es nicht alles heißt.
Nur dann wäre man da mit Einarbeitung und Festlegung schon Tage/ Wochen beschäftigt.
lsyncd ist da natürlich eine ganze andere Liga. Nutzt du es also für bestimmte Bedingen und ihr habt noch Framework im Hintergrund, oder ist das mit dein primäres Werkzeug?
Nutzt du es also für bestimmte Bedingen und ihr habt noch Framework im Hintergrund, oder ist das mit dein primäres Werkzeug?
Ich benutze es in der Entwicklung für den mehrfachen Sync von Webinhalten (Bilder, CSS, etc.) für Test- und Stage-Umgebungen. Auch um die Entwicklung unter verschiedenen Bedingungen oder Interpretern zu testen.
Gruß
Frank
