Team LiB
Previous Section Next Section

Other File Transfer Solutions

There are many other ways to get files from Machine A to Machine B over networks. You can use NFS drive mounting on a trusted network, synchronization tools like rsync, and even tar streams tunneled through secure SSH connections. In this section, we describe solutions to two common file transfer jobs.

Network-Based tar Backups

This command tars all the /home users on your system. Unlike the regular use of tar, however, the output is not sent to a file. Rather, it's sent as a compressed stream over SSH to a file on a remote machine on your network:

   # tar cpzv /home | ssh -q root@all.yourbase.com "cat >
   /root/home-hackup.tgz"

Your local drive could be at 99 percent of full capacity, and this tar archiving method would still work, since the output never goes to the local disk at all, but is piped directly out over the network to Machine B (all.yourbase.com).

Keeping Multiple Servers in Sync

If you run multiple servers on a network, you probably use common copies of your master files. Administrators running web farms or load-balanced web clusters often use a program like rsync to keep the common files under control, You can use rsync over an encrypted SSH session to enhance the security of this common operation. In fact, if you've set up key-based authentication, the entire process can be automated. Use the following commands:

   rsync -e ssh -avuz /var/www/html/* webserver1.mydomain.com:/var/www/html/
   rsync -e ssh -avuz /var/www/html/* webserver2.mydomain.com:/var/www/html/
   rsync -e ssh -avuz /var/www/html/* webserver3.mydomain.com:/var/www/html/

Define a cron job that runs each of these commands nightly. It will send all changed files from your main machine to the multiple servers on the network. The first time you run this, all the files are pushed and will take a while; each time afterward, it only pushes files that have been changed. You can even configure a second instance and reverse the source and target directories to run it bidirectionally so that changes made on remote servers will be pulled back to the master machine.

Note 

If you rely on rsync, it's imperative that all server clocks are in sync. Do this by running rdate against a good time reference. Most big organizations have their own timeserver, but a common system crontab (run crontab -- e to edit yours) for syncing the time at 1:13 every morning would be:

   1 13 * * * rdate -s time.nist.gov

Team LiB
Previous Section Next Section