Hey,
csync2’s main focus is a one-to-many synchronization of files, not a two-way synchronization. It is well-suited for deploying a (large) number of files from one location to multiple other locations. But it falls short woefully for a bidirectional synchronization (kepping the same set of files identical when you’ve got changes on both sides).
I’ve used csync2 in a bidirectional synchronization with several custom scripts in the past, but you still had to take care of conflicts (if the same file has been modified on both ends between two synchronization points) by human intervention. Human intervention means the use of the csync2 command-line application on the servers to resolve the conflicts, which only an administrator can do. It just doesn’t scale for such a task.
csync2 is a tool that works at what I’ve called “application layer” earlier. It shares these problems with certain other solutions on that layer (e.g. unison), that’s why I haven’t mentioned it earlier. Other applications on that layer (e.g. OwnCloud, AeroFS) make the human intervention easier by providing both copies of the same file and integrating conflict-resolution tools into their desktop client applications. That way normal users can resolve the conflicts and not just tech-savvy admins.
Edit 1: You’ve said it works fine for home directories. That’s actually one of the use cases where you can get good mileage out of csync2 because the set of files that are modified on each end are usually disjunct: user A logged on to machine B will only write to /home/a whereas user C on machine D will only write to /home/d at the same time. There won’t be any conflicts. But this just isn’t the same as a shared document folder used by different people on different machines at the same time.
Don’t get me wrong, I like csync2, it does what it’s been designed to do very well. But it’s not the right tool for this job. Don’t use a screwdriver to drive in a nail etc.
Edit 2: After re-reading the original poster tools like rsync, unison or csync2 might be a good solution for what was asked for: a read-only replica of the files that’s only activated once the source server fails. If this is the case (if it’s guaranteed that there will be no modifications on the mirror site) then those tools can be used to build mirrors with multi-minute update granularity.
Kind regards,
mosu