Hardware Reference
In-Depth Information
N
Subversion stores its own work files inside the current directory, meaning they will each be littered with
.svn
folders. This is only a mild nuisance for end users but can cause bigger problems when they appear in system
configuration folders such as
/etc
.
Note
To make a direct copy of one set of files from one directory to another, you can probably use
cp
at the end of
each day. However, this will wastefully copy files that haven't changed, and so
rsync
was born.
rsync
is a very old
copy and backup program but is still a venerable workhorse. I make backups of my code directory, for example, with
this single line:
rsync -a code
steev@remote-backup-host.com
:~/backup/daily
I recover them (for testing
8
) with this:
rsync -a
steev@remote-backup-host.com
:~/backup/daily code
The options here perform a recursive update, while maintaining all symlinks, permissions, and user settings and
is the most typical in home situations. The manual pages detail other possibilities.
rsync
does have two problems, however. The first is that it's available primarily for Unix-oriented platforms.
Versions are available for Windows (such as DeltaCopy and the version with Cygwin), but they take a little while to set
up and can be tricky.
The second issue is that it requires a password to be interactively given in order to log in to the remote site.
This is a nuisance and prevents any kind of automatic backup. For a remote site to allow a user to connect without a
password, they must first establish an alternative form of trust—in this case, the exchange of public keys. To copy from
machine A to machine B, B must have a copy of A's public key. To copy from machine B to machine A, A must have a
copy of B's public key. In our case, machine A is at home with our files, while B is a remote machine for backup.
So, our home machine must generate a key for the user who'll be doing the copying.
ssh-keygen -t rsa
which by default can be found in
~/.ssh/id_rsa.pub
. This is then copied to the remote machine (perhaps using a
password-directed
rsync
) and appended to the list of authorized keys that the remote user will accept:
cat id_rsa.pub >> ~/.ssh/authorized_keys
Once this is done, you should be able to
rsync
without a password:
rsync -a --bwlimit=100
steev@remote-backup-host.com
:~/backup/daily code
Note that this limits the bandwidth (with the
bwlimit
argument) to 100 kilobytes per second so that other
applications can make use of the Internet, since
rsync
and
ssh
are rather greedy when teamed up together.
One potential administration problem that can exist here is for the home user to be refused a connection because
the address from which they're connecting does not match the one used in the key. This can happen when the
hostname is something simply like
linuxbox1
but appears to the remote machine as
netpc-london-isproute-isp.com
or something equally unhelpful. The target machine, by comparison, will usually have a fixed name because it
must be addressable from the outside world. Because the home machine name might change (at the whim of the
ISP), the easiest solution is to reverse all the instructions given here! That is, use the remote server to connect
to
the
!LLBACKUPSAREUSELESSUNLESSTHEYČ€RETESTEDREMEMBER
Search WWH ::
Custom Search