"Linux Gazette...making Linux just a little more fun!"

The Answer Guy

By James T. Dennis, tag@lists.linuxgazette.net
Starshine Technical Services, http://www.starshine.org/

Remote Tape Backups

From Bryan Andregg on 10 May 1998

>> On Thu, 19 Jun 1997 13:26:49 -0500, Gary Vinson wrote:
Hello,

We are running Redhat 4.1 (kernel of 2.0.37). We recently added a tape drive where we would like to do remote backups. Everything works fine as long as we are not root, ie, the remote backup using "tar -cvf remotehost:/dev/st0" works fine for non-root. But for root, we get a "Permission denied" error. I understand that hosts.equiv does not control remote access for root but tried adding entry for /root/.rhosts on the "remotehost", where the tape drive resides, without success. How are others handling this problem?

I'm sorry to bring up such and old thread but this answer is still pretty bad and there is a much better solution (or several).

First you can use the following syntax:

tar -cvf operator@remotehost:/dev/st0 ...

... by creating an "operator" psuedo-user with appropriate permissions to the tape device on the remote host, and creating an ~operator/.rhosts with entries like:

myhost.mydomain.org root

For each of the hosts to be allowed to perform backups.

This doesn't expose the remotehost (tape server) to nearly as much risk as the approaches suggested in these responses (although the normal concerns about user r* access and host spoofing apply.

To alleviate that concern we can use the --rsh-command= switch to tar to force it to run over ssh like so:

tar -cvf operator@remotehost:/dev/st0 --rsh-command=/usr/local/bin/ssh ...

'cpio' and 'dump' also support this "user@remote.tapeserver...:/path" syntax --- though I don't see any option regarding the --rsh-command over-ride on those.

In most cases (at least with 'dump') you'll need to ensure that there is a copy of the 'rmt' command on the "operator's" $PATH (on tape server, of course).

Bryan Clarifies...

From Bryan C. Andregg on 11 May 1998

Their question was not how to backup, but how to allow root to do backups.

Bryan C. Andregg

My answer was about how to allow root (on the client) to do backups on a remote machine without exposing that remote machine (the tapehost) to the risks of allowing rsh root access. The point is that you don't have to change securetty or allow remote root access to provide tape service to to your clients.

Getting off of the security issues, there is another important note that's worth pointing out. If you just run these commands as I've described them, you'll probably find that the tape drive doesn't "stream" very well. That is to say that the flow of data to the drive will probably be "bursty" enough that you'll see the drive stopping, rewinding, and restarting frequently (several times per minute.

If you tape drive isn't streaming your backups can take ten times as long as it should --- and it will put even more wear and tear on the drive than that. So you want to avoid this non-streaming wherever possible.

The solution to this problem is to use Lee McLoughlin's buffer program. I'm pretty sure that this is the same Lee McLoughlin that wrote the popular FTP mirror Perl script.

This program reads input from one data stream (often a network socket) reblocks it, and writes it (usually to stdout which would usually be redirected to the tape drive). You'd also use this if your going to compress or encrypt the data as you write it to the tape drive (e.g. using gzip as a filter, or using the 'z' flag on GNU tar).

Here's an example of one of the earlier commands using

tar -czvf - ... | rsh -l operator otherhost "buffer > /dev/st0"

I didn't go into that detail in my other message since it related to the mechanics of the backup process rather than the specific security issues at hand. However, anyone else reading this message might put their tape drive and tapes through unecessary stress and get unsatisfactory performance and results by trying to follow these examples without using a copy of buffer

I've noticed that the S.u.S.E. distribution ships with a copy of buffer and Debian has it in a package for it (which will presumably be included in their "Official CD Sets" as the 2.0 distribution is finalized and "shipped". I'd like to see this included with Red Hat and I'd like to see GNU tar use it, if available, by default when it is called with the 'z' (gzip/compression) flag or with a remote file specification. Likewise for the appropriate options in the GNU cpio and dump packages.

This should not be a bit of hacker lore that must be passed down from one sysadmin to another. It should be documented in the man and info pages for all of the programs that conventionally write to tape drives, particularly if they support syntax to directly do so over network sockets, and through compression and/or encryption packages.

One final note about network and remote tape backups:

Most sysadmins seem to spend entirely too much of their time reinventing the backup wheel. I haven't looked at the slick commercial packages like BRU Taper seem to be mostly user interfaces.

Recently, however, I've been playing with the Advanced Maryland Automatic Network Disk Archiver from the University of Maryland. This seems to be well suited to enterprise data backups. It has not UI to speak of --- you add and configure the appropriate psuedo accounts and groups (providing network access over rsh or ssh), install the client and server components on your machines, in your /etc/services, and /etc/inetd.conf, and you add some cron jobs. It manages its own library of tapes and its own "holding space" on one of the server's filesystems.

Basically you just feed it tapes. One cron entry does an amcheck and mails the operator(s) if the wrong tape is in the drive. That's normally done during the day when you expect an operator to be around to fix the problem. Another entry writes the backups from the holding disk(s) to tapes; which would normally be done in the middle of the night. Amanda supports a variety of tape changers (and has an extensible design so any tape changer mechanism with a decent command-line control program can be used with it).

Many of the users on the Amanda mailing list (see their web site) are using it to maintain archives of hundreds of filesystems --- some of them measure their Amanda capacities in Terabytes!

The biggest problem with Amanda at this point is the lack of documentation for new users. It has plenty of features (the underlying backup processes use standard dump or GNU tar commands so the system is very portable, and some even use it to backup their NT systems).

Another problem is that Amanda is a complex system. I'd suggest that an initial backup of the tape server be created using some traditional Unix/Linux command like cpio or tar, and that the resulting tape be write-protected and permanently stored. (A removable medium, such as a CD-RW, CDR, LS-120, or whatever would also work). The point is that this should have the Amanda installation on it, so you can bootstrap from a tape server failure to do a full recovery.

Amanda deserves much more coverage than this; and perhaps, when I understand it well enough, I'll write an LG article on it. I think that every professional Unix and Linux sysadmin should take a look at it.

Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 29 June 1998

	versions	lilo	virtdom	kernel	winmodem	basicmail	betterbak
	shadow	dell	dumbterm	whylinux	redhat	netcard	macrovir
	newlook	tacacs	sendmail	dialdppp	ppp233	msmail	procmail