Backing Up In Linux
There are currently three main types of tape drives available for the PC (and hence Linux). There are those based on SCSI interfaces, those based on the floppy drive interface (QIC-40, QIC-80, QIC-117, QIC-3010 and QIC-3020), and QIC-02 type drives. A new breed of tape drives that attach to the IDE interface is coming, but at the moment, Linux support is minimal. There is no Linux support for drives that attach to the parallel port.
You cannot simply attach a tape drive to your machine and expect Linux to automatically recognize it. You need to tell the kernel about it, and this can involve recompiling the kernel. In addition, you need entries in your /dev directory so that programs under Linux can access the tape drives.
Below, I will describe how to set up the two most common types of tape drives.
Tape drives that connect to the floppy drive interface have the advantage that no separate interface card is required; they are, therefore, fairly cheap and reliable. Thus, this breed of tape drive has been very popular.
One of the first tape drives of this type was the Colorado Jumbo 250. The tape drive cable for these drives attaches to the floppy drive interface. The QIC-80 specification defines how to access these tape drives. Many other tape drives, including the Iomega 250, Conner C250MQ, Wangtek 304, and Colorado Jumbo 350 are QIC-80 compatible.
Tape drives that use the QIC-80 specification require a program (actually, a “Loadable Kernel Module”) called ftape, written by Bas Laarhoven and Kai Harrekilde-Petersen, which at the time of writing is at version 2.03b. QIC-117 and QIC-40 formats are also supported by ftape, as is QIC-3010 and QIC-3020 (i.e. QIC-WIDE) in an experimental form. A complete list of tape drives supported by ftape can be found in the vndors.h file in the ftape source distribution. Support for some enhanced controller boards is also provided—specifically Iomega Tape Accelerator, Colorado FC-10, and Mountain MACH-2. Support for the FC-15 and FC-20 high speed Colorado controller boards is not yet provided.
Most Linux distributions include ftape; if yours doesn't, you will have to download it (see Tape Resources sidebar). Unless you are using module version support in your kernel (if you don't understand what this means, you can assume that you are not using it), ftape will need to be recompiled each time you update your kernel.
First, go to your source directory and unpack the sources:
:$ cd /usr/local/src $ tar xzf ftape-2.03b.tar.gz
You will end up with a directory ftape-2.03b; all the ftape source files will be in this directory along with some documentation files. You now need to compile ftape to end up with a file ftape.o:
$ cd ftape-2.03b $ make clean $ make dep $ make all
Next, you need to make sure that your kernel has been compiled with ftape support built in. Recompiling the kernel is beyond the scope of this article (see the Kernel-HOWTO more details), but basically, do:
$ cd /usr/src/linux $ make config
to accept all the default values for all options (unless, of course, you do want to change them), and when you get to the QIC-117 option, answer Y. Leave the NR_FTAPE_BUFFERS at the default value of 3. Then recompile the kernel (usually make clean dep; make zImage) and install the new kernel. Don't forget to re-run lilo if you use it.
If you are using very recent kernels (1.3.30 and above), you will have to use zftape. zftape (written by Claus Heine) is based on ftape but provides support for the dynamically loaded buffers provided by the later kernels. You compile it exactly the same way as ftape. Installing it is also done the same way as with ftape, except that you will use the name zftape instead of ftape. When configuring your kernel, you will not get asked any questions about QIC-117 options or NR_FTAPE_BUFFERS.
Even if you are not using recent kernels, zftape provides some very good enhancements over the basic ftape package, including software compression, and it is well worthwhile upgrading to get it.
Next, you need to make sure that the /dev entries have been created correctly for ftape. Once again, if you have a Linux distribution, this will more than likely have been done, otherwise; you will have to create them manually. Do:
$ ls /dev/*rft* /dev/*tape*
and you should have at least the following files:
/dev/rft0 /dev/nrft0 /dev/ftape /dev/nftape
If you do not, create them (you will have to be root):
$ mknod -m 666 /dev/rft0 c 27 0 $ mknod -m 666 /dev/nrft0 c 27 4 $ ln -s /dev/rft0 /dev/ftape $ ln -s /dev/nrft0 /dev/nftape
Alternatively, if you have a script called MAKEDEV in your /dev/ directory, you can simply run this to have your devices created correctly.
$ cd /dev $ ./MAKEDEV ftape
If you are using the zftape package, there are certain other device names that you will require. They can be created from the zftape Makefile by:
$ make mknod $ ln -s /dev/rft0 /dev/ftape $ ln -s /dev/nrft0 /dev/nftape $ ln -s /dev/qft0 /dev/qftape $ ln -s /dev/nqft0 /dev/nqftape
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open