Lsyncd (Live Syncing Daemon) synchronizes local directories with remote targets
Go to file
2010-08-03 14:16:12 +00:00
doc no-startup flag introduced, whyever someone wants this, I'm generally for more configureability 2010-07-27 13:00:32 +00:00
tests adapted tests 2010-05-22 16:24:16 +00:00
AUTHORS updated AUTHORS to all who submitted packages (that went into the source) 2008-12-14 01:39:08 +00:00
autogen.sh for older boxes this can be useful to pick the right automake binary. 2008-11-05 18:56:24 +00:00
ChangeLog changelog 2010-07-11 18:55:30 +00:00
config.guess imported version 1.0 2008-08-06 13:04:01 +00:00
config.sub imported version 1.0 2008-08-06 13:04:01 +00:00
configure.in v1.34 2010-07-11 18:56:49 +00:00
COPYING imported version 1.0 2008-08-06 13:04:01 +00:00
inotify-nosys.h imported version 1.0 2008-08-06 13:04:01 +00:00
INSTALL imported version 1.0 2008-08-06 13:04:01 +00:00
install-sh imported version 1.0 2008-08-06 13:04:01 +00:00
lsyncd.c experimental, removed tosync stack 2010-08-03 14:16:12 +00:00
lsyncd.conf.xml prepare 1.26 bugfix release 2009-01-05 13:45:12 +00:00
ltmain.sh imported version 1.0 2008-08-06 13:04:01 +00:00
Makefile.am spelling patch and manpage location 2010-07-11 18:47:37 +00:00
mkinstalldirs imported version 1.0 2008-08-06 13:04:01 +00:00
NEWS news 2010-06-05 06:38:37 +00:00
README GlusterFS 2010-05-20 21:31:46 +00:00
TODO news 2010-06-05 06:38:37 +00:00

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.drbd.org/) 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. GlusterFS does exactly this and more (see http://www.gluster.org).
	 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