Lsyncd (Live Syncing Daemon) synchronizes local directories with remote targets
Go to file
2016-12-22 13:55:59 +01:00
cmake made compatible with lua5.3 2016-11-24 15:44:08 +01:00
doc/manpage cleanups 2016-12-13 14:53:01 +01:00
examples Updated lbash.lua and lrsync.lau to remove the equals (=) from the settings directive. 2016-08-31 10:46:38 -05:00
m4 Try harder to find matching Lua program/library pairs 2012-10-02 15:58:52 +02:00
tests Splitted Delay combination log from logging about it. 2016-12-21 16:29:29 +01:00
.gitignore adding install targets and reenabling the manpage stuff 2014-04-29 16:38:25 +02:00
bin2carray.lua fix script integration 2011-05-04 13:18:37 +00:00
ChangeLog Fixed Delay changes potentially not reflect on Event layer. Fixed test exitcode 2016-12-21 13:11:55 +01:00
CMakeLists.txt cleanups 2016-12-13 14:53:01 +01:00
config.h.in Replacing autotools with CMake 2014-04-29 16:11:27 +02:00
COPYING Fix documentation spelling bits, and a few links 2013-05-04 13:11:09 +10:00
default-direct.lua adding -p to cp for default.direct. Put a log message before daemonizing to test logging. Fix a crash for default.direct 2016-12-02 16:24:07 +01:00
default-rsync.lua cleanups 2016-12-14 08:45:33 +01:00
default-rsyncssh.lua cleanups 2016-12-14 08:45:33 +01:00
default.lua cleanups 2016-12-13 14:41:35 +01:00
distclean.sh adding a distclean script 2016-12-13 14:56:23 +01:00
fsevents.c lock pidfile, remove pidfile on INT or TERM 2013-07-30 12:20:23 +02:00
inotify.c made compatible with lua5.3 2016-11-24 15:44:08 +01:00
INSTALL Correct typo 2015-11-26 10:04:52 +00:00
lsyncd.c cleanups 2016-12-05 15:11:00 +01:00
lsyncd.h made compatible with lua5.3 2016-11-24 15:44:08 +01:00
lsyncd.lua Actually stack when toDelete,stack 2016-12-22 13:55:59 +01:00
README.md moving the manual 2016-06-08 09:10:13 +02:00

Lsyncd -- Live Syncing (Mirror) Daemon

Description

Lsyncd watches a local directory trees event monitor interface (inotify or fsevents). It aggregates and combines events for a few seconds and then spawns one (or more) process(es) to synchronize the changes. By default this is rsync. Lsyncd is thus a light-weight live mirror solution that is comparatively easy to install not requiring new filesystems or block devices and does not hamper local filesystem performance.

Rsync+ssh is an advanced action configuration that uses a SSH to act file and directory moves directly on the target instead of re-transmitting the move destination over the wire.

Fine-grained customization can be achieved through the config file. Custom action configs can even be written from scratch in cascading layers ranging from shell scripts to code written in the Lua language. This way simple, powerful and flexible configurations can be acheived. See the manual for details.

License: GPLv2 or any later GPL version.

When to use

Lsyncd is designed to synchronize a local directory tree with low profile of expected changes to a remote mirror. Lsyncd is especially useful to sync data from a secure area to a not-so-secure area.

Other synchronization tools

DRBD operates on block device level. This makes it useful for synchronizing systems that are under heavy load. Lsyncd on the other hand does not require you to change block devices and/or mount points, allows you to change uid/gid of the transferred files, separates the receiver through the one-way nature of rsync. DRBD is likely the better option if you are syncing databases.

GlusterFS and BindFS use a FUSE-Filesystem to interject kernel/userspace filesystem events.

Lsyncd usage examples

lsyncd -rsync /home remotehost.org::share/

This watches and rsyncs the local directory /home with all sub-directories and transfers them to 'remotehost' using the rsync-share 'share'.

lsyncd -rsyncssh /home remotehost.org backup-home/

This will also rsync/watch '/home', but it uses a ssh connection to make moves local on the remotehost instead of re-transmitting the moved file over the wire.

Some more complicated examples, tips and tricks you can find in the manual.

Disclaimer

Besides the usual disclaimer in the license, we want to specifically emphasize that the authors, and any organizations the authors are associated with, can not be held responsible for data-loss caused by possible malfunctions of Lsyncd.