[plug] Constant rsync'ing...

[James Devenish]

In message <200303171426.55956.T.Phillips at murdoch.edu.au>
on Mon, Mar 17, 2003 at 02:26:55PM +0800, Trevor Phillips wrote:
> Sorry. Linux/i386/ext3 - although the FS format is negotiable.

Ah, okay then, I suppose the other list replies would be helpful to you,
then.

> I'd prefer a 
> solution that works per-directory, rather than per-partition, but I'll still 
> consider a per-partition solution if it's worth it.

(Just to keep pushing the Unison barrow:) Unison, being userland
software, is not attached to partitions: it works at the level of
already-mounted filesystems. You can tell it to use any 'roots'
("base directories") and ignore/include any files/directories.

> I considered Unison, and keep meaning to try it out in this role. Would it 
> really be any faster than rsync's "building file list" phase, though?

(I've not used rsync much. Never seemed to fit the bill for me, so I
don't know how it performs.) Unison only 'builds' its file list once and
then stores this 'last known good' state. Subsequent runs are fast.

> One of the complications is this isn't just 2 machines - it's a cluster of 3, 
> and so the changes need to be replicated from one primary server to 2 other 
> machines.

Unison handles that fine, though it only does pairs at a time (I think).
Fortunately, doing pairs is fast. In fact, I use it is situations were
*any* replica could change (i.e. the replicas can act as peers rather
than master-slave, if desired). A RAID solution, in contast, would
surely be a master-slave type arrangement.

On the other hand, a distributed filesystem would presumably fit your
circumstances. I encourage Unison because it works across architectures
and operating systems and is known to be 'safe' (in my experience).