On 7 Jan 2010, at 11:52, Chris G wrote:
On Thu, Jan 07, 2010 at 11:33:04AM +0000, James Taylor wrote:
On 7 Jan 2010, at 11:25, Chris G wrote:
On Tue, Jan 05, 2010 at 08:39:58PM +0000, steve-ALUG@hst.me.uk wrote:
Chris G wrote:
I'm after backup rather than synchronisation so Unison doesn't really offer what I want. What I'm actually doing is to rsync files to the backup system
Sorry - don't mean to be thick here, but surely your first step is to ensure that your main machine and the backup machine are synchronised, which is (AFAIK) what both Unison and rsync do. If you're not synchronising the two machines, then surely you'd be using copy (cp) not rsync?
I'm not synchronising, no changes on the backup machine will ever get back to the client machine.
Perhaps this is just a language/communication issue.
Synchronising is, to my mind, bi-directional.
I'll say again, I think this is a communication/language issue. Synchronisation is the act of making synchronous - and synchronous only means "the same", that is *after* the process both sides are the same, no matter what method it used to get there:
Whether this means:
a) changes on one are passed to the other *and* vice-a-versa, OR b) if the changes are only passed from one to the other*,
is dependant upon context, and not a fixed rule. Quite often, synchronise only means one way** - consider synchronising to time servers, dns slaves, and other contexts like "manage.py syncdb" in django, both of which are one way copies, so I would be very wary of thinking that when people, programs and documentation say synchronise that this always means bi-directional.
Best Regards
James
* For completeness, just passing the changes isn't enough for a one way synch - any changes on the target would get lost in a true synch. ** One way synchronisation is trivial compared to two way - look at the difficulties many SCM apps have with merges for an example.