mirror of
https://github.com/octoleo/lsyncd.git
synced 2024-11-16 01:47:08 +00:00
122 lines
4.8 KiB
Plaintext
122 lines
4.8 KiB
Plaintext
|
lsyncd - Live Syncing (Mirror) Daemon
|
||
|
|
||
|
DESCRIPTION:
|
||
|
|
||
|
Lsyncd uses rsync to synchronize local directories with a remote machine
|
||
|
running rsyncd. Lsyncd watches multiple directories trees through inotify.
|
||
|
The first step after adding the watches is to, rsync all directories with
|
||
|
the remote host, and then sync single file buy collecting the inotify events.
|
||
|
|
||
|
So lsyncd is a light-weight live mirror solution that should be easy to
|
||
|
install and use while blending well with your system.
|
||
|
|
||
|
See lsyncd --help for detailed command line options.
|
||
|
|
||
|
WHEN TO USE:
|
||
|
|
||
|
Lsyncd is designed to synchronize a local directory tree with low profile of
|
||
|
expected changes to a remote mirror. On the receivers side rsyncd can be
|
||
|
configured to also change the uid/gid of the file. Lsyncd is especially
|
||
|
useful to sync data from a secure area to a not-so-secure area (e.g. as a
|
||
|
one way connection to allow employees to publish their files to a public
|
||
|
accessible web server).
|
||
|
|
||
|
WHEN NOT TO USE:
|
||
|
|
||
|
* File with active file handles (e.g. database files)
|
||
|
* Directories where many changes occur (like mail or news servers)
|
||
|
|
||
|
In these cases e.g. DRBD (see http://www.linux-ha.org/DRBD) might be better
|
||
|
for you.
|
||
|
|
||
|
COMPARISONS:
|
||
|
|
||
|
Lsyncd vs. DRBD:
|
||
|
|
||
|
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.
|
||
|
|
||
|
However when using lsyncd a file change can possibly result in a full file
|
||
|
transfer (at least for binary files) and is therefore unsuitable for
|
||
|
databases. Also a directory rename will result in transferring the whole
|
||
|
directory.
|
||
|
|
||
|
Lsyncd vs. incron:
|
||
|
|
||
|
Incron does not (yet) support recursive directory watching making it
|
||
|
unsuitable for described needs (http://inotify.aiken.cz/?section=incron&page=about&lang=en).
|
||
|
In fact a different approach would have been to extent incron. However, we
|
||
|
decided to stick to the NIH principle (Not Invented Here) :-), because extending
|
||
|
the C++ solution seemed to tedious.
|
||
|
|
||
|
Lsyncd vs. FUSE:
|
||
|
|
||
|
This is another interesting idea is to write a daemon that provides a
|
||
|
shadow file system through fuse. When accessing a file the data is synced
|
||
|
to local file as well as the remote file. Whit this approach inotify could
|
||
|
be replaced. BindFS (see http://www.cs.helsinki.fi/u/partel/bindfs/)
|
||
|
does this for local mirroring. We discarded this idea because it would
|
||
|
affect performance of normal operations in a negative way.
|
||
|
|
||
|
Lsyncd vs. cron:
|
||
|
|
||
|
If you find a solution using cron to call rsync over the whole directory
|
||
|
tree periodically after every 'X' hours/minutes/seconds more satisfying
|
||
|
than lsyncd, please go for it *sulking*. We don't like it!
|
||
|
|
||
|
LSYNCD USAGE EXAMPLES:
|
||
|
|
||
|
/usr/sbin/lsyncd /var/www/ remotehost::wwwshare/
|
||
|
|
||
|
This watches and rsycn's the local directory /var/www/ with all
|
||
|
subdirectories and transfers them to 'remotehost' using the rsync-share
|
||
|
'wwwshare'.
|
||
|
|
||
|
/usr/sbin/lsyncd --nodaemon --exclude-from /etc/lsycnd/exclude \
|
||
|
/var/www/ remotehost::wwwshare/
|
||
|
|
||
|
This will also rsync/watch '/var/www', but it excludes files and directories
|
||
|
from '/etc/lsycnd/exclude'. Additionally this example lsyncd will not fork,
|
||
|
and log to stdout/stderr instead.
|
||
|
|
||
|
/usr/sbin/lsyncd %userwww remotehost::wwwshare/foobar/
|
||
|
|
||
|
This special target will scan through all directories in /home and syncs all
|
||
|
www subdirectories of the users to wwwshare in the subdirectory foobar.
|
||
|
The user peter having his local data in /home/peter/www/ will have it
|
||
|
rsynced to ::wwwshare/foobar/peter/.
|
||
|
|
||
|
LIMITATIONS:
|
||
|
Be aware that the kernel limits the number of watches. You can see the limit
|
||
|
in
|
||
|
/proc/sys/fs/inotify/max_user_watches
|
||
|
|
||
|
which is usually set to 8192. This means lsyncd cannot watch more than 8192
|
||
|
directories unless you change the kernel setting. Lsyncd itself has no
|
||
|
limits.
|
||
|
|
||
|
Because Axel is lazy the maximum possible size a filename is 8192. If you
|
||
|
need more, change MAX_PATH in lsyncd.c. Or send me patches that introduce
|
||
|
dynamic memory usage.
|
||
|
|
||
|
SOURCE DOCUMENTATION:
|
||
|
|
||
|
The only file of interest is 'lsyncd.c' which includes comments.
|
||
|
Everything else in the tarball is packaging bushwa.
|
||
|
|
||
|
DISCLAIMER:
|
||
|
|
||
|
Besides the usual disclaimer in the license, we want to specifically EMPHASIZE
|
||
|
that NEITHER the authors NOR any organization the authors are associated with
|
||
|
can and will hold responsible for data-loss caused by possible malfunctions
|
||
|
of lsyncd. Especially if you run it with root privileges ;-) (we ourselves
|
||
|
run lsyncd as www-data).
|
||
|
|
||
|
FEEDBACK:
|
||
|
|
||
|
Please send praises and feedback to: axel.kittenberger@univie.ac.at
|