Lsyncd combines the advantages of inotify with the functionality of Rsync. This means lsyncd holds a remote copy of a directory permanently to the state that corresponds to the local directory.
Technically lsyncd begins at the start with a full Rsync run, but sets simultaneously on all the monitored directories and subdirectories inotify watches. All changes to the data reports through Kernel to lsyncd. This collects these messages and then initiates at short intervals for the changed files and re-run Rsync.
This approach is superior to a double periodic start of Rsync. On the one side lsyncd generates much less load (IO and CPU) on the system and on the other hand the possible update intervals are significantly shorter.
Ok, until here you have the options of lsyncd significantly simplified. In fact, you can down to the smallest detail scripts that perform operations lsyncd when it gets an inotify message.
Why should you use it?
Maybe wherever you have been using Rsync? Here are some scenarios:
Cheap failover solution: The situation I find looks very nice. One can use LSYNC and MySQL replication to make pretty much all known CMS, e-commerce carts or blog systems fail safe. So put synce / var / www and the databases on a second server in one remote host location, the TTL in the DNS will fairly low. If the main web server dies you can put DNS IP to standby node and ready.
Of course, this is not a great switchover, it can even raise data loss situation, but in many cases this is still more than adequate. In turn, such a setup is quick to set up, but very complex and completely independent. Cost effective by default, utterly unbeatable.
But do not forget Monitoring
If you are going to use lsyncd anyhow, then one thing I would like to say specifically, it is quite robust solution against network disturbances, but also not completely crash-proof. So you need to keep monitoring a small script against the lsyncd log file, which recognizes a hang or crash and send alert accordingly. Simple but cost effective.