From time to time you will need to transfer files between computers. You will probably, for example, publish release tar archives, or transfer log files for debugging to another computer. There are a variety of ways of doing this, and you may need to choose the one to use depending on circumstances.
rsync
is good when you have already transferred one version of a file or directory tree, and need to transfer updates. It is quite remarkably efficient at that. It requires to be installed on the other end.sftp
andscp
, which are provided byssh
, are good for transfers across untrusted networks (i.e., any network except your own, and even that may be suspect).nc
(netcat) can be a good thing, on a trusted network, for transferring data as quickly as possible, since it is doesn't do any encryption. Despite this, it doesn't require transferring a password in cleartext.nc
can be combined withtar
orcpio
to transfer more than one file at a time.
You probably want to avoid, if at all possible, the following:
ftp
is completely unencrypted (including sending your password in cleartext), and often difficult to get through firewalls.rcp
, which is likescp
, but is completely insecure. Luckily, it is rarely even installed, except as an alias forscp
.
Example
Let's assume we are in a directory that we want to transfer to another
computer, other.example.com
, as the directory /tmp/foo
on the
remote computer. Here are a few ways to do the transfer:
Rsync and scp are equally simple:
rsync -r . other.example.com:/tmp/foo/.
scp -r . other.example.com:/tmp/foo/.
With Rsync, you may want to consider more options as well, such as
--delete
, to make sure any extra files on the target end get
deleted. If you do that, then also test it with --dry-run
.
Netcat requires a bit more setup. On the remote end, you'd run it like this:
nc -l -p 12765 | tar -xf -
On the local (sending) end, you run it like this:
tar -cf . | nc localhost 12765
Note that there are at least two versions of nc
out there, with
incompatible command line syntaxes. This example uses the syntax from
the version in the Debian netcat-openbsd
package.
You can send from the remote end to the local end as well, and you can choose which end connects and which end listens, depending on the situation. For example, if your remote end has a firewall that prevents it from listening, you'd listen on your local end instead.
(But, remember, only do this if your network is trusted. Otherwise someone can get the file instead.)