Broadly speaking, network backups can be performed in one of two ways: The computer that's to be backed up can initiate the backup using another system's tape drive, or the system with the tape drive can initiate the backup of another computer. I refer to the former as a client-initiated backup and the latter as a server-initiated backup. Each option has its advantages and disadvantages. This chapter discusses examples of both types of backup.
| || |
It's common to refer to the computer with the backup medium as the backup server, and the computer that's being backed up as the backup client. This terminology is in line with the usual meanings of server and client in some cases, but not in others. In the case of server-initiated backups, for instance, the backup client must normally run some type of server software that the backup server uses as a client. Although this terminology is in some sense incorrect, referring to the systems in this way greatly simplifies discussions, particularly when comparing the two types of network backups.
In a client-initiated backup, the backup server runs some type of server software that allows the client to access the backup hardware. The server software may be a program that's used for other purposes in addition to backup, such as rshd or Samba, or it may be a dedicated backup package. In either event, the fact that the client initiates the process has certain important consequences:
Scheduling issues ” If a backup should be performed regularly, you must use cron or some other scheduling tool on the backup client to initiate the backup. You must also have some mechanism to ensure that backups from different clients don't interfere with one another.
User control ” Client-initiated backups are sometimes convenient for backing up workstations, because the workstations' users can control when the backups occur and even what files to back up. A user might decide to back up just after completing a project or before going on vacation, for instance.
Security ” The backup clients don't need to run any server software, and so can be made quite secure. Likewise, in the case of Linux or UNIX clients, the backup process can run as root , thus providing full access to all files. The backup server, on the other hand, needs to run a server program that's accessible to all the backup clients. This is best handled by setting aside a dedicated backup server.
These characteristics make client-initiated backups a reasonable choice for operation on many small networks. Scheduling conflicts can often be resolved in a reasonable way on such networks. One important drawback is that if the backup process is placed in the hands of individual users, they may forget to do it on a regular basis. You can automate the process by using cron jobs or the like, but this requires careful planning to reduce the risk of conflicts.
Server-initiated backups use a network client program on the backup server to open a connection to a network server program on the backup client. The backup server can then read the files from the backup client and store the files on tape. Compared to a client-initiated backup, this approach has several important characteristics:
Scheduling issues ” Because the backups are controlled centrally , you can more easily prevent conflicts and even schedule back-to-back backups to more effectively use otherwise idle network time, such as late at night.
User control ” The users of individual workstations have no control over when their backups occur. If they need a backup at a particular time, they must schedule it with the backup server or use some other means, such as backing up important files to a Zip disk.
Security ” All the backup clients must run some type of server program. This is most commonly a file-sharing protocol like NFS or SMB/CIFS, but in some cases a protocol like FTP might do, as well. In the case of Linux clients, the file-sharing server must provide full read access to all files to the backup server, which is a potential security risk ”if a miscreant can masquerade as the backup server, the miscreant can acquire sensitive files such as /etc/shadow . The backup server, however, is less vulnerable to attack, since it needs to run only client software in order to do its duties .
The scheduling issues make server-initiated backups desirable for large networks, but the security issues may be a major concern in some cases. You can mitigate these concerns by using firewalls and other access control mechanisms to limit who may access the backup clients' filesystems. Also, dedicated backup packages like AMANDA may use techniques like setting the SUID bit on key executables to permit most of the backup processes to run as ordinary users while still allowing the package as a whole to do its job.
| || |
Network backups pose additional security concerns for both server-initiated and client-initiated backups. If the protocol used requires a password, that password might be compromised if it's sent in an unencrypted form; likewise for data transferred in the course of the backup. Even if all data are encrypted during transfer, the security of the backup tapes can be important; if somebody steals a backup tape, or even "borrows" it for a few minutes, sensitive data such as /etc/shadow can be read from the tape, even if the file's permissions on the source computer wouldn't ordinarily allow it to be read by outsiders.