Unix Backup and Recovery

Security

Historically, backups and security have had almost completely opposite goals. Things such as .rhosts files were absolutely necessary to gain any type of backup automation, and yet they are a well-known security problem. Fortunately, most modern backup products have worked around these problems.

Sockets or rsh?

There are very few products left that communicate via rsh. rsh has been identified as a security hole, and many sites have disabled it. The products that still use rsh usually do not require the ability to rsh as root; instead, they set up a special user ID that is used only for that purpose. That way, a .rhosts entry needs to be set up only for that user.

Most products now communicate via Berkeley sockets. This means that they need to have some client-side software running with which they can communicate; the process running on the client is called a “daemon.”

Encryption?

More and more people are asking for encryption. Encryption can be accomplished in one of three ways. Some software packages encrypt the commands that they send back and forth, so that a rogue server cannot imitate them and perform unauthorized actions, such as request a restore of data it is not entitled to. Another method is to encrypt backup data in transit but then decrypt it as it is being written to a backup volume. This allows backups over an insecure network but does not require an encryption key to read the volume (think of it as a “backup tunnel”). Then, of course, there are software ...