Christopher Neufeld, v, 5 August 1997
This HOWTO describes how to use a Linux-compatible tape drive installed on an MS-DOS machine to back up the filesystem of a Linux machine.
The criteria I set were that the resulting setup should be as secure as possible and should be fairly simple, and take up little or no space on the MS-DOS machine's hard drive. It should also be capable of recovering from the worst system corruptions, up to and including the theft of the hard disk, requiring a restore to a bare Linux file system. The technique described here uses no hard drive space on the MS-DOS machine, though it requires that that machine be assigned an IP#. You will need three formatted, blank 1.44MB diskettes.
Throughout this description I will refer to two machines as
msdos'' and ``
msdos'' is the name of the machine which has the
tape drive and is usually running MS-DOS. ``
the Linux machine whose disk you are trying to back up or restore
to the tape drive. For simplicity I will refer to the first machine
msdos'' even when it is booted into and running
Linux. Further, all path names in this document should be
considered to be relative to the Linux machine with the
Search-And-Rescue (SAR) disks mounted somewhere on the system. That
means that the file
/etc/passwd is the password file
for your Linux machine's hard drive, while, for instance,
/tape144/etc/passwd is the corresponding file on the
I am using Karel Kubat's backup scripts, version 1.03, available at
the backup scripts''. You do not have to use these scripts for your own backups to tape. I like these scripts as they use afio to form an uncompressed archive of compressed files, rather than a compressed archive of uncompressed files. The former is much safer if there is a media read error during the restore. I understand that Karel is no longer supporting backup, and now has produced 'tob', or tape oriented backup. While I haven't tried the new package myself, it cannot make a significant difference to the procedure outlined here.
First of all, obtain the ftape module. It is a part of all modern kernels, but if you are using an older kernel you can find the module at:
tape144root disk, and put the images onto 3"1/2 floppies.
ftape module will only work if it is installed in
the kernel which was running when you compiled it. I could not get
it to work with the
ftape.o module on the
tape144 root disk, I think because that module has
been stripped of symbols and won't install. So, you now have to
make a new kernel with network and ftape support, and if you're
running an old kernel, a new
ftape.o. Read the
directions which ship with the
ftape archive for
directions at this stage. Remember that the kernel you compile must
support the Ethernet cards on both the Linux machine and the MS-DOS
Copy the newly created kernel image over top of the one on the Net
boot disk. Use
/bin/cp, do not create a boot disk with
dd'' command as you would to create a bootable
kernel image. Write protect the boot disk, and label it: SAR#1.
Now, mount the
tape144 root disk. I'll assume that the
mount point is
/tape144, to avoid confusion in file
names. We need to free some space on it, so delete the following
/tape144/bin/dialog /tape144/bin/elvis /tape144/bin/vi /tape144/boot/ftape.o
Now, create a new file:
which contains the following line:
msdos'' should be replaced with the name or IP# of the MS-DOS machine which has the tape drive installed.
Next, so that you don't have to rely on a name server, add lines to
/tape144/etc/hosts with the names and IP
numbers of the Linux and MS-DOS machines. For instance, mine
contains the following two lines:
18.104.22.168 caliban.physics.utoronto.ca caliban caliban.physics 22.214.171.124 ariel.physics.utoronto.ca ariel ariel.physics
Now, there's some sort of problem with the inetd configuration. We
have to put the full path name of the rsh daemon in it. Change line
/tape144/etc/inetd.conf to read:
shell stream tcp nowait root /usr/etc/tcpd /usr/etc/in.rshd
Add local net routing information to
/tape144/etc/rc.d/rc.inet1 to enable the MS-DOS
machine to use the network. The format of this depends on your
network configuration, you can just copy the appropriate format out
of your Linux
/etc/rc.d/rc.inet1. For my network, the
lines that have to be added are:
The IP# in the ifconfig entry is that of the MS-DOS machine.
/etc/ifconfig eth0 126.96.36.199 broadcast 188.8.131.52 netmask 255.255.255.0 /etc/route add -net 184.108.40.206 netmask 255.255.255.0
Now, copy this file into
and change the IP# in the new file to reflect that of the Linux
machine rather than the MS-DOS machine.
Next, clip out lines 3 to 11 of
That's an if statement which executes the
files. We don't want this to happen during the bootup.
Create a new file:
where, again, ``
linux'' is replaced with the full machine name (including domain) or the IP# of the Linux machine.
Fill in the password field in
the root login to keep people from logging onto the MS-DOS machine
while you're doing the backup. You can do this by copying the
corresponding field from your Linux machine's
Copy /usr/bin/rsh into /tape144/usr/bin.
Copy the following files from
in.rshd rpc.mountd rpc.nfsd rpc.portmap services tcpd
Create a new script,
consists of the following: (change ``
reflect your Linux machine name).
Note that newer kernels will not require the insmod line.
#! /bin/sh /bin/sh /etc/rc.d/rc.inet1 /bin/sh /etc/rc.d/rc.inet2 /bin/mount linux:/nfs /mnt /bin/insmod /mnt/ftape.o
Next, create another new script,
/tape144/bin/msdosset, as follows: (change
linux'' to reflect your Linux machine name).
As above, newer kernels will not require the insmod line.
#! /bin/sh /bin/sh /etc/rc.d/rc.inet1 /bin/sh /etc/rc.d/rc.inet2 mount linux:/mnt /mnt /bin/insmod /mnt/ftape.o
Create a readable file,
contains this helpful information for use in full recovery:
For a full recovery to a trashed hard disk, boot the Linux machine with the SAR disks #1 and #2 then type the following: /bin/sh /etc/rc.d/rc.inet1-l /bin/sh /etc/rc.d/rc.inet2 /usr/etc/rpc.portmap /usr/etc/rpc.mountd /usr/etc/rpc.nfsd Next, insert SAR disk #3 and type: mount /dev/fd0 /mnt Create a new mount point, with: mkdir /mnt2 and mount your Linux hard disk partition on this point. You may have to reformat the partition first, if so, follow the directions in the Linux Installation HOWTO. The SAR disks contain all the files necessary to do the reformat. Finally, use disks SAR#1 and SAR#2 to boot up the MS-DOS machine and run the /bin/msdosset script on that machine. It will take about a minute to run that script because it is getting an NSF file from a floppy drive, so be patient. Now, recover the tape to /mnt2 on the Linux machine.
If you are using the backup scripts you will need to copy 'afio'
/tape144/local/bin subdirectory. It is not
necessary to have the rest of the backup script files on the
recovery disks, an archive can be recovered using only 'afio' and
I was unable to use the backup scripts as they come shipped. The
tape archive appears to build cleanly, but it is unrecoverable. I
found that removing the block size and conversion statements fixed
it. Here is the patch to the ``
Apply this patch to the Linux machine's hard disk copy of
'netbackup' as well as to the copy on the SAR disks.
*** netbackup.orig Mon Jan 9 17:22:32 1995 --- netbackup Mon Jan 9 17:23:25 1995 *************** *** 35,41 **** "'mknod", devname, "p'"); exec ("su -", USERNAME, "-c", "'rsh ", REMOTE_HOST, ! "\"dd", "of=" REMOTE_DEVICE, "obs=20k", "conv=sync\"", "<", devname, "'&" ); --- 35,41 ---- "'mknod", devname, "p'"); exec ("su -", USERNAME, "-c", "'rsh ", REMOTE_HOST, ! "\"dd", "of=" REMOTE_DEVICE, "\"", "<", devname, "'&" ); *************** *** 50,56 **** "'mknod", devname, "p'"); exec ("su", USERNAME, "-c", "'rsh ", REMOTE_HOST, ! "\"dd", "if=" REMOTE_DEVICE, "ibs=20k", "conv=sync\"", ">", devname, "'&" ); --- 50,56 ---- "'mknod", devname, "p'"); exec ("su", USERNAME, "-c", "'rsh ", REMOTE_HOST, ! "\"dd", "if=" REMOTE_DEVICE, "\"", ">", devname, "'&" );
You have now finished your SAR disk #2. Write protect it.
Next, mount a clean, formatted disk (create it with
mkfs). Copy the
ftape.o file onto it, and label it SAR#3. For some
reason things go badly if you write protect this disk, so leave it
On the Linux machine, create a new directory for NFS file serving. I made a directory:
ftape.o(unstripped, about 500+ kB) into this subdirectory. Create an entry in your Linux's exports file
Note that all files in your NFS directory and it's subdirectories are not secure. Somebody else could boot the MS-DOS machine into Linux with his own boot disks and mount this directory, so be certain that you don't put anything sensitive in your NFS subdirectory.
Restart your NFS daemons,
rpc.nfsd. They don't seem to take kindly to a
SIGHUP restart, so kill them and reinvoke them. If
you're not activating these daemons in your
/etc/rc.d/rc.inet2 you might want to do so now.
OK, now we're all set to back up and recover. To make a full backup
from the Linux machine, boot the MS-DOS machine with SAR#1. When
prompted for the second disk, load SAR#2. Log in as root, and
execute the script:
/bin/tapesetup. Log out of the
MS-DOS machine. If you're using the backup scripts, the netbackup
command will now work. You can also use the ``
msdos:/dev/ftape'' switch on GNU
mt, and make your backup this
way. If you have a backup program, which is only capable of writing
to a local file, do the following. Assume that the backup program
is called ``
localbackup'' and writes to the file
represented by its command line argument:
when it's done, delete
mknod /tmp/tapepipe p rsh msdos dd of=/dev/ftape < /tmp/tapepipe & localbackup /tmp/tapepipe
Recovering to a live Linux machine: the
cpio, and so on will all
work without special actions on the part of the operator. If you
have a local recovery program which recovers from a file, do this:
mknod /tmp/tapepipe p rsh -n msdos dd if=/dev/ftape >> /tmp/tapepipe & localrecovery /tmp/tapepipe
/tmp/tapepipewhen you're done.
Notice that I'm using '
rsh' to the root user on the
MS-DOS machine. This works with a correct
entry. The configuration on the '
tape144' disk allows
rsh to root, but does not allow
rlogin to root, logins are restricted to the console.
This is good for security.
If you are worried about a root
.rhost file, you can
create a new user on SAR#2, ``
permissions to operate the tape drive but not the disks (create a
new group and put tapeuser in that group, then
chmod the files
/dev/nrft*). Your backup program then has to know to
rsh to that username rather than to root. Of course,
now there must be an
.rhosts file in
~tapeuser on SAR#2. For my own use, I have chosen this
course, rather than a root
Finally, the directions for a complete recovery to a trashed hard
disk. This assumes that the Linux partition is completely
unrecoverable. If necessary, reformat that partition as described
in the Linux Installation HOWTO. Boot the Linux machine from SAR
disk #1. When prompted, insert disk #2. Now, follow the directions
in the file
/root/notes (this was
/tape144/root/notes when it was mounted on your Linux
machine). Once both machines have been booted up, run the recovery
routine you need. If you are running the backup scripts you can do
it as follows:
- change directory to the mount point of the hard disk partition which you will be recovering.
- if any mounted volumes are on the backup, and you want to recover them, create the mount points within the hard disk partition and mount the volumes.
- Enter the command:
rsh -n msdos dd if=/dev/ftape | afio -i -v -Z -c 1024 -
rsh -n -l tapeuser msdos dd if=/dev/ftape | afio -i -v -Z -c 1024 -
mknod /tmp/backpipe p rsh -n msdos dd if=/dev/ftape >> /tmp/backpipe & afio -i -v -Z -c 1024 /tmp/backpipe
afiopicks it up. The '
-i' switch tells it to recover the files relative to the current working directory (which is the root of the hard disk partition). '
-v' is verbose, listing the files as they are recovered. '
-Z' tells afio that this is an archive of individually compressed files. '
-c 1024' tells it to use a 5 MB streaming buffer to avoid a lot of tape rewinding.
The commands listed in the
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
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
ftape.o to the MS-DOS machine through NFS.
This is because some old versions of the
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
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 ``
identity back again so that you have usable SAR disks.
Modified Feb 6, 1996.
Modified Aug 5, 1997.