Tar and Taper for Linux
Below is a list of the more common preferences. For a complete list, see the man page.
Tells taper whether to compress files it writes to an archive. Default is TRUE.
- log file
Where taper logs activity to. Default is ~/.taper_log.
- Klog level
The level of logging from 0 (no logging) to 3 (verbose). Default is 2.
- prompt directories
Whether taper confirms before selecting directories in restore and backup. Default is FALSE.
- incremental backup
Whether incremental backup is used as a default. Default is TRUE.
- most recent restore
Whether, by default, taper should restore the most recent file or the file the user specifies. Default is TRUE.
- exclude compress
Certain types of files can bypass the compression facility—e.g., by default, taper doesn't try to compress .gz or .gif files. This preference specifies which files not to try and compress. The preference is simply a string with the files you wish to exclude given as a space-separated list (e.g., default is .gz .gif .Z)
- exclude files
Certain types of files can be excluded from the archive, even if explicitly specified—e.g., by default, taper doesn't try to back up .o files. This preference specifies which files to automatically exclude. The format is the same as the “exclude compress” preference and the default is .o ~
You can save your preferences to customize your particular setup. There are two ways to s: one is to a preference file and the second is to a command line file which can then be used to start taper in the future. Simply select the appropriate option from the main menu.
taper looks for a preference file in the following order:
The filename given by the -p (--preference-file) option on the command line
The filename given by the environment variable TAPER_PREFS
The file ~/.taper_prefs
The file /usr/local/etc/.taper_prefs
Some tape drives write zeros to the beginning of a tape and this can cause confusion with taper, which thinks it has reached the end of the tape when it detects zeros. To find out if your tape drive does this, put a tape in the drive and run the testzero program—note that the tape will be overwritten. taper will test your tape and print the result on the screen.
If taper says that your drive writes leading zeros, you will have to run mktape on every tape before you can use it with taper.
People using floppy tape drives have to both format and erase tapes. These users must either format tapes using DOS, OS/2 or WINDOWS or buy pre-formatted tapes. Erasing tapes is done automatically by taper.
People with SCSI tape drives generally don't need to format tapes. Some SCSI tape drives don't even need erasing (e.g., DAT). To tell taper not to erase tapes before using them, change the erase tape option in the backup preferences menu and save the preferences. Run mktape on all tapes before you use them so that taper doesn't think they are bad.
If you have a SCSI drive and are not sure whether you need to erase tapes, tell taper not to erase tapes and see what happens.
Linux has support for a /proc file system. This is a directory that looks like a normal directory, but actually contains information about the current machine state. It is useful for programs like ps which can read this directory and print the information contained in it.
However, we obviously don't want to back up this directory. You can tell taper to automatically exclude this directory. Run the which_device program:
$ ./which_device /proc
and the device on which the /proc directory is mounted is printed. Most probably this is 1, in which case you don't need to do anything because this is taper's default. If it is not 1, tell taper this via the backup options or via the command line (--proc-device num).
If you have many files to backup, taper can end up using quite a bit of memory. If you wish to minimize the amount of memory taper uses while running, edit your Makefile and un-comment the line (i.e., remove the #] in front of the line):
Now, when taper runs, it will be quite memory efficient. The downside (of course, there's a downside!) will be that performance will not be as good. However, on most machines, you will not notice a performance degredation until you reach 2,000-3,000 files.
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!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide