The commands listed in the /tape144/root/notes file could be run from a script. When I tried, I got rpc setup errors. I suspect it was just that the commands were run too quickly, and the portmapper hadn't properly installed itself. I found that typing the sequence in manually worked fine, so I've recommended that.
I think this setup is secure. Note that somebody can still get access to all your files if they go to the tape drive and pull the tape out before you get there, then then read the tape themselves. People with very sensitive data might consider encrypting the stream from the archiver. Archive to standard output and pipe the output to the encrypter, and redirect the output of the encrypter to append to the named pipe /tmp/tapepipe as described above. Note that errors in the recovery process will result in all files after that point being unrecoverable, as the entire archive is now a single DES-encrypted stream. It is possible to use options on afio to send each file in the archive first through gzip, then into an encryption program like des, but note that this compressing first does provide a fair amount of known plaintext for determined code breakers to work with, so a better approach might be to skip the gzip step and simply encrypt it with des, at the expense of significantly more tape area. Needless to say, DES encrypted files don't compress.
The rc.inet1 directions I've included will allow only communication with the local network, not the rest of the world through a gateway.
During a full recovery to a blank hard disk the SAR disk #3 provides ftape.o to the MS-DOS machine through NFS. This is because some old versions of the ftape module can't control some tape drives when there is a disk mounted in the floppy drive. With newer kernels, the entire NFS stuff can be omitted.
This is very important. ***TEST*** the SAR recovery procedure. I did, but don't leave anything to chance. Make sure that you can recover at least one file from your tape to the Linux machine using only the SAR disks (i.e. without mounting the hard disk). If you can't reboot the Linux machine without inconveniencing a lot of users, change the setup information on the SAR disks to assign the ``linux'' identity to another MS-DOS machine and then boot the two MS-DOS machines into Linux to make sure everything works. Then, change the ``linux'' identity back again so that you have usable SAR disks.