Tar and Taper for Linux
Most people who write software for Linux and make it available to others distribute it via tar files. For example, say that you have downloaded a new game, best_game-1.3.tar.gz. To install (restore) this game in your home directory:
$ cd$ tar xzf best_game-1.3.tar.gz
The game and all its applicable files will then be restored. If the author of the program has followed normal convention, all the files will be in a directory called best_game-1.3. Note that when restoring files from an unknown source, it is a very good idea to restore the files in your home directory, examine the files, and then when sure everything is correct, move them to the location suggested by the author. This way, you will avoid inadvertent file overwrites. It is also best to first use the t option to see whether the author has put the files in a subdirectory. If not, make a subdirectory and use it:
$ cd$ mkdir worst_game-0.1$ cd worst_game-0.1$ tar xzf worst_game-0.1.tar.gz
Some of the other options that tar supports are:
Tells tar to use multi-volume archives. If tar comes to the end of the floppy or tape, it will not abort with an error, but prompt for insertion of a new floppy or tape, which it calls a “volume”. Each volume contains a stand-alone archive file and you don't need all the volumes to extract files, but if a file is split across two volumes, you will need to extract that file with the -xM option. Note that some tape devices, such as DATs, do not work with this option.
- N DATE
Tells tar to operate only on files that are newer than DATE. Thus, you can tell tar to backup only files that are newer than a certain date. DATE is specified in the same format produced by the date command. Normally, directly before doing one backup, you use the date command to record the date and time when the backup was made, like this:$ date > last_backupThen the next time you are backing up, you can backup only files that have been changed during or since the last backup by including the option -N "cat last_backup" in tar's command line.
- T FILENAME
Tells tar that a list of files to backup/restore is in FILENAME. For example, tar czf /dev/ftape LIST_FILES would create an archive containing files that are named in the LIST_FILES file. The LIST_FILES file is simply a straight text file with one filename on each line.
When tar comes across a link, it normally stores details about that link. If this option is given, tar will actually store the file pointed to by the link and pretend the link doesn't exist. Use this with caution since you can end up with many different copies of the same file.
Causes tar to verify the archive after it has written it. It will not work on tape drives that cannot rewind.
Normally tar strips the leading / from a pathname so that when you restore, the file is restored in a directory relative to the current one (see the above example with /usr/home/john). By specifying this option, the file is restored from where it was backed up. Use this with caution since you can inadvertently overwrite a file on your hard disk.
More details can be found in the tar man page as well as in the info files that come with the tar sources.
Although most backups are done on tape drives, it is sometimes useful to use your floppy drive (which can be very slow and frustrating!). To use your floppy, give tar the filename /dev/fd0 for the first floppy (drive A: in DOS parlance) and /dev/fd1 for the second floppy (drive B:). So, to make a backup of your /etc directory to “drive A:”
$ tar czf /dev/fd0 /etc
Note that the existing contents of the floppy will be totally overwritten. When using floppy drives, the -M option is very handy since after one floppy is full, tar will automatically prompt for the next floppy.
If you use ftape, you cannot append files to an existing tar backup. Therefore, if you make a backup that occupies only 10 MB, you will have wasted the rest of the tape. Fortunately, there is a way of using the rest of the tape, using the mt program. After tar has written a backup to the tape, it writes two EOF marks on the tape. Schematically, your tape now looks like:
You can tell mt to advance to these EOF marks by
$ mt -f /dev/nftape fsf 1
Note that you must use the non-rewinding device (/dev/nftape), because if you don't, after mt has repositioned the tape, it will automatically be rewound and your repverbose mode positioning will be lost. The fsf 1 is an mt command that advances the tape to the first EOF mark.
Your tape will now be positioned at the end of the first backup, and you can create another backup at this position:
$ tar czf /dev/ftape files_for_backup_2
Because you used the rewinding device, the tape will rewind after the tar backup has been written. Your tape will look like this:
Should you wish to add a third backup, you can do the following:
$ mt -f /dev/nftape fsf 2< $ tar czf /dev/ftape files_for_backup_3
The fsf 2 advances past two EOF marks—hence, past the first two backups. Your tape will look like:
and will be positioned at the beginning of the tape because you used the the rewinding device to do the backup.
If you wish to restore files from the first backup, you can do the following:
$ mt -f /dev/ftape rewind< $ tar xzf /dev/ftape files_from_backup_1
This first line ensures that the tape has been rewound. The second line then restores files from the first backup. If you wish to get files from the second backup, do the following:
$ mt -f /dev/ftape rewind $ mt -f /dev/nftape fsf 1 $ tar xzf /dev/ftape file_from_backup_2
Similarly, to restore files from the third backup:
$ mt -f /dev/ftape rewind $ mt -f /dev/nftape fsf 2 $ tar xzf /dev/ftape files_from_backup_3
You can continue adding backups until your tape is full. Note that strictly speaking, you do not need to rewind the tape each time—if you are sure that the tape is rewound, you can skip the rewind command; however, I would recommend that you always rewind prior to use to avoid problems. If you are already at the beginning of the tape, the rewind command will not take any time at all. You are likely to get into all sorts of bother if you assume that the tape is rewound when it is not. You can find out where your tape actually is by:
$ mt -f /dev/nftape status
As you can imagine, maintaining backups this way is awkward and very time-consuming since if you do not know what is on the third backup, you have to rewind your tape, advance to the third backup and then read what is there.
Another problem with tar is that, when using the compression mode, tar compresses all the files and then writes them to the tape. This leads to a very serious problem. If your tape somehow becomes corrupted, you lose all the files after the corruption occurred.
Because of the above, and because of tar's command-line user-interface, the author was tempted to fill the gap with a user-friendly backup program—hence, taper was born...
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- Non-Linux FOSS: libnotify, OS X Style
- UX Designer
- RSS Feeds
- It is quiet helping
18 min 57 sec ago
36 min 1 sec ago
- Reachli - Amplifying your
1 hour 52 min ago
2 hours 41 min ago
- good point!
2 hours 44 min ago
- Varnish works!
2 hours 53 min ago
- Reply to comment | Linux Journal
3 hours 22 min ago
- Reply to comment | Linux Journal
5 hours 48 min ago
- Reply to comment | Linux Journal
9 hours 48 min ago
- Yeah, user namespaces are
11 hours 4 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?