3
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: 21.03.2025 um 23:03 Uhr
3 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
