You sound like you don't believe.
Oh ye of little faith...
A quicky Googling reveals this page, which has a couple of archived posts of mine from the LVS mailing list from 2001 (LVS was one of the original Linux clustering setups - essentially laying the groundwork for what is today called, "cloud computing" - but I was doing it long before most people caught on to the idea - and getting paid for it):
http://www.ntua.gr/lvsp/Joseph.Mack/HOWTO/LVS-HOWTO.services.single-port.html
"Don Hinshaw dwh (at) openrecording (dot) com 19 Jul 2001
You can use rsync, rsync over ssh or scp.
You can also use partition syncing with a network/distributed filesystem such as Coda or OpenAFS or drbd (drbd is still too experimental for me). Such a setup creates partitions which are mirrored in real-time. I.e., changes to one reflect on them all.
We use a common NFS share on a RAID array. In our particular setup, users connect to a "staging" server and make changes to the content on the RAID. As soon as they do this, the real-servers are immediately serving the changed content. The staging server will accept FTP uploads from authenticated users, but none of the real-servers will accept any FTP uploads. No content is kept locally on the real-servers so they never need be synced, except for config changes like adding a new vhost to Apache."
"Don Hinshaw dwh (at) openrecording (dot) com
I do this. I use Qmail as it stores the email in Maildir format, which uses one file per message as opposed to mbox which keeps all messages in a single file. On a cluster this is an advantage since one server may have a file locked for writing while another is trying to write. Since they are locking two different files it eases the problems with NFS file locking.
Courier also supports Maildir format as I believe does Postfix.
I use Qmail+(many patches) for SMTP, Vpopmail for a single UID mail sandbox (shell accounts my ***, not on this rig), and Courier-Imap. Vpopmail is configured to store userinfo in MySQL and Courier-Imap auths out of Vpopmail's tables."
"Don Hinshaw dwh (at) openrecording (dot) com>
I have one client where we do this. At this moment ( I just checked) their database is 279 megs. An rsync from one box to another across a local 100mbit connections takes 7-10 seconds if we run it at 15 minute intervals. If we run it at 5 minute intervals it takes <3 seconds. If we run it too often, we get an error of "unexpected EOF in read_timeout".
I don't know what causes that error, and they are very happy with the current situation, so I haven't spent any time to find out why. I assume it has something to do with write caching or filesystem syncing, but that's just a wild guess with nothing to back it up. For all I know, it could be ssh related.
We also do an rsync of their http content and httpd logs, which total approximately 30 gigs. We run this sync hourly, and it takes about 20 minutes."
Feel free to ask your IT guys if I know my ********.