• BACKING UP AND RESTORING
• BACKING UP SELECT FILES
• DATA COMPRESSION
• MISCELLANEOUS TIPS
• Backing Up From the Root Directory
• Saving Screen Output in a File
• Converting Catalog Output to a File List
• Determining the True Capacity of a Tape
• Floppy Disk Block Size
• Using SCO Operating System
• Extra Volume Prompt
• Negatively Compressed Files
• UPGRADING OPERATING SYSTEM VERSIONS
• TESTING & INSTALLING SOFTWARE
• VIRTUAL FILES
• Anatomy of a Virtual File
• How LONE-TAR Deals with Virtual Files
• Compatibility
• RESTORING ENTIRE FILE SYSTEMS FROM SYSTEM CRASHES
• EXCHANGING TAPES WITH OTHER COMPUTER SYSTEMS
• QIC Format Tapes
• 4mm or 8mm Tapes
• Byte Swapped Data
• TROUBLE-SHOOTING COMMON PROBLEMS
• Unattended Backup Fails
• Tape Light Stays on, but there is No Tape Activity
• Cannot Kill LONE-TAR even with kill -9
• Tape Verified Fine, but when Restored, an I/O error 5 occurred
• Distinguishing Software Errors from Hardware Errors
• Directory not in Proper Format
• Ran out of Space during a Restore
• Same filesystem
• XENIX Operating System
• Backed up a file, but LONE-TAR cannot find it when I Restore
• There are Stp Error Messages on the Console in the Morning
• Trouble Restoring Floppy Disks Created with DOS-TAR
• DOS Files are Converted When They Should Not Be
• After a Full Restore the Master Backup Date is Incorrect
• Restore Prompts for more Tape Volumes than Exist
• Restore Prompts for another Tape Volume before it should
• After a Full Restore SCO fixperms Utility Finds Problems
• After a Full Restore some File Permissions Appear to have Changed
• After a Full Restore the Catalog File is Missing Files
• After a Full Restore Special Device Files have Different Major and Minor Numbers
• An Option in the Manual does not Appear on the Help Screen
• File Access Times are Changed even with the -a Option

4.1 BACKING UP AND RESTORING

LONE-TAR makes the ordinary task of archiving data an interesting and enjoyable process. Several items of general interest regarding command-line options should be discussed to understand the full power of LONE-TAR and to avoid potential pitfalls. First, LONE-TAR uses the standard UNIX option argument format. This format is:

commandname -optionlist option-arguments

It is essential that the option characters be given the same order as their respective arguments. If this is not the case, then the arguments are misinterpreted. The '-' dash symbol preceding the option list is optional for LONE-TAR.

For example, to perform a Master backup to a tape device /dev/rct0 with a block factor of 120 and capacity of 150 Megabytes the following command is used:

lone-tar Mvfbk /dev/rct0 120 150000 .

Please note that the arguments follow the options in order. If you were to reverse the order of the options you would need to reverse the order of the arguments. The following commands are all equivalent:

lone-tar Mvfbk /dev/rct0 120 150000 .
lone-tar Mvbfk 120 /dev/rct0 150000 .
lone-tar Mvkbf 150000 120 /dev/rct0 .

Because the number of options and arguments can get large, there is an alternative method of specifying options. Using the above example, the alternative method is:

lone-tar Mv -f /dev/rct0 -b 120 -k 150000 .

Keep in mind, that you must use a leading '-' before each additional option letter with its respective argument. This is so that LONE-TAR can tell the difference between an option letter and the filenames to be backed up.

While restoring, it is important to remember to use the same options in listing, verifying, or extracting that were used in backing up. This means the volume size and block size setting options k, and b, as well as the seeking option n and the file device option f. These options specify the TAR format used and must be used consistently with the same volume set, otherwise erroneous results occur when crossing volumes. It is good practice to record the exact options used directly on the archive media label.

The Master backup (using the M option) should be done on a monthly basis and in some installations weekly. The Incremental backup should be done daily. If the Incremental backups are getting too large then it is time to do another Master backup.

Restoring files from LONE-TAR is very simple. The Master backup is restored first. This brings the filesystem up to the date of the last Master backup. Then the last Incremental backup is restored. This overlays all files that have changed with the current version of these files. All files, empty directories (those with no files), device files, pipes, links, and symbolic links are restored to their previous status. This obviates the need for remaking links, remaking device files, or redoing the port configuration. It also makes disk swapping and filesystem swapping between similar machines much easier.

Keep in mind, that if you are ever doing a Non-Destructive Restore (using the N option), that you should reverse the order of restoring the Master and Incremental backups. You should first restore the Incremental backup and then following this, the Master backup.

For most systems, doing the Master backup and Incremental backup from the root directory will suffice. If the system is large (containing many mounted filesystems), it may be preferable to do an M or I backup on a particular filesystem. There must be a ./etc directory on the local filesystem so that ./etc/Master_backup can be made. If there is not, LONE-TAR makes the file ./Master_backup to hold the backup date. Then, with the filesystem mounted (e.g. on /usr2) one uses the following shell script:

cd /usr2
lone-tar Mvfb /dev/tape 120 .

Then any subsequent Incremental backup from this mount point (/usr2) only backs up files changed since the date of the last Master backup as specified in the file ./etc/Master_backup or
./Master_backup.

If this technique is chosen, one should exclude this filesystem when doing the Master backup from the root directory. Otherwise the filesystem mounted on /usr2 (in this example) is backed up twice. Using the example above, the command to do this would be:

lone-tar MvfbE /dev/tape 120 ./usr2 .

The advantage of this technique is that other users could be using the files in /usr2 while the backup is being made.

4.2 BACKING UP SELECT FILES

Sometimes one would like to back up only select files in a list or a directory. The following simple command shows how this can be done using LONE-TAR. The list can be produced by an editor or with a command such as:

ls . > list

Then the file list can be edited or modified. Once the list is satisfactory, simply run the following command:

lone-tar cvF list

The F option tells LONE-TAR to look in the file specified by the argument for the list of names. The list should be one name per line and can be any length. To add files to the end of the default /dev/ltar floppy archive without compressing one would use:

lone-tar rCvF list

To add these same files to the end of the default /dev/ltar archive with compression use:

lone-tar rvF list

4.3 DATA COMPRESSION

LONE-TAR can compress files to either a floppy disk (seeking device) or tape (non-seeking device). Internally it uses a different method depending on whether the device is seeking or not. If it is seeking, LONE-TAR compresses files without making a temporary file. The file is actually compressed as it is streamed through LONE-TAR and the compressed output goes directly to the backup media. This allows for exceptionally fast compressed backups.

If the device is non-seeking, an indirect method of compression must be used because LONE-TAR does not know how big the compressed file will be until it is fully compressed. This indirect method is initiated using the P option (pack regardless). Most floppy drives are seeking while most tapes are non-seeking.

To initiate compression to a seeking device, the lower-case cn options are used. LONE-TAR assumes the default device /dev/ltar is seeking. Usually this file is linked to the raw floppy device file typically /dev/rfd0. Any device given by the f option is assumed to be non-seeking. Thus, LONE-TAR does not compress files when used with the f option. One can make LONE-TAR think the device is a seeking device by using the n option. LONE-TAR then compresses files. Example:

lone-tar cvfn /dev/rdfd096ds18 files...

To absolutely turn off compression use the C option. Example:

lone-tar Cv files...

If you are not sure if the device is seeking or non-seeking you can use the P option (pack regardless) to compress the files. This option requires the use of the k option to set the size of the backup device in case more than one volume is required. When P is used, LONE-TAR creates a Virtual Pipe (consisting of available memory and free space on the filesystem) which may slow down the backup slightly.

To compress only very large files one can use the L option (limit) as follows:

lone-tar cvL 100 files...

Thus, LONE-TAR only goes into compression mode for files greater than 100 (512 byte) blocks. All smaller files are backed up without compression.

An astute observer will notice that LONE-TAR spends more time compressing ``dense'' files than ``loosely packed'' or redundant files. This is because LONE-TAR is trying to find a way to make the ``dense'' files even more dense and this takes a little more time. Do not be alarmed.

4.4.1 Backing Up From the Root Directory

A common mistake when backing up from the root directory is to use:

lone-tar Cv *

instead of

lone-tar Cv .

The asterisk matches all files in the root directory except those starting with a leading period. Thus, your valuable .login, .exrc, .cshrc, and .profile files are not backed up. If your system crashes and you need to restore, these files are not restored because they were never backed up.

Another common mistake is to use the slash `/' as in:

lone-tar Cv /

This backs up all the files using a leading slash `/`. This is referred to as an absolute pathname format. This makes it somewhat more difficult to restore an individual file in a different directory than the one from which it came. You are forced to use the A option to do this. For example, you might wish to restore one of the files into the /tmp directory to examine it. If you forget to use the A option during the restore, then the file is restored to its exact location on the hard drive.

For this reason, it is recommended that backups from the root directory start with a period `.`. This puts the pathnames in relative format. It is much easier to restore the file to a different directory when files have been backed using the relative pathname format. For example, if the file you want to examine is /usr/bin/chapter1, you would do the following to extract it without wiping out your current version.

cd /tmp
lone-tar xv ./usr/bin/chapter1

In this way the file is available in /tmp/usr/bin/chapter1. Using a leading period `.` when backing up always leaves you with more options when you begin to restore.

 

 

4.4.2 Saving Screen Output in a File

You may encounter a situation in which you want to have the screen output of LONE-TAR go simultaneously to the screen and also be saved in another file for later inspection. This is easy when the V option modifier is used as it creates a catalog file. The catalog file is a carbon copy of the screen output. You can customize the location and name of the catalog file by using the environment variables TARDIR and TARFILE.

LONE-TAR sends all warning messages, error messages, and the filename list to the standard output.

 

4.4.3 Converting Catalog Output to a File List

If you want to take a catalog file and convert it to a raw list of files (one per line), you can do this using the filecnvt utility. This takes any type of catalog file (backup, verify, list, or restore) and converts it to a raw list of files. This raw list is suitable for use with the F option. This utility resides in the /usr/lib/tar directory. For example, to convert the file called LAST_Master to a raw list called /tmp/filelist, the following command is used:

/usr/lib/ltar/filecnvt LAST_Master > /tmp/filelist

At times you want to know the exact size of a tape. You also want to know if the manufacturer's stated capacity of the tape is really the true capacity in actual practice. You can determine the true capacity of a tape by using the sizer option.

lone-tar -zSIZER -b blocksize -f tape_name [ -k kilobytes]

For example, to see how much data can be written to your tape drive /dev/rct0, the following command is used:

lone-tar -zSIZER -b 120 -f /dev/rct0

The sizer option continues to write data to the tape drive at full speed until it hits the end of the tape. It then reports the total amount of data written as well as the backup speed in megabytes per minute.

If you simply want to know how fast your tape drive can back up data under fully optimal conditions, and do not want to wait for sizer to fill up the entire tape, you can limit the amount of data written by adding the kilobyte limitation as the third argument. For example, to test the maximum speed of the tape drive but only write about 4 Megabytes of data, the following command would be used:

lone-tar -zSIZER -b 120 -f /dev/rct0 -k 4096

You should not use sizer with compressing tape drives unless the release notes specify you have a version of sizer that sends uncompressible data to the tape drive. Otherwise, the data sizer sends to the tape drive is compressed and the results are misleading.

 

 

4.4.5 Floppy Disk Block Size

Usually the best blocking factor to use with a floppy disk is the same as the number of sectors per cylinder. For a 1.44 Megabyte floppy with 18 sectors per track and 36 sectors per cylinder, a block factor of 18 is optimum. A 1.2 Megabyte floppy with 15 sectors per track works best at a block factor of 15 or 30. This is because the floppy driver can write all the information within one revolution of the disk.

You can find the optimum block factor by using the timing feature of LONE-TAR's backup summary for comparison at different blocking factors.

 

4.4.6 Using SCO Operating System

When using the SCO operating system all block sizes are rounded down to an even block size. This is because of a peculiarity in the system allowing only 1024 byte read/writes to raw block devices. A block size of 1 is rounded up to 2.

 

4.4.7 Extra Volume Prompt

In a rare instance you may notice LONE-TAR prompt for another volume but not write any information on it. This may occur when the files you are backing up take up exactly the storage capacity of the archive device. The same occurs when listing or extracting the files. Do not be alarmed if this occurs.

 

4.4.8 Negatively Compressed Files

Another problem occasionally encountered is negative compression of a file. Files can be excluded from compression in any of the following three ways:
 

1) Matching for a suffix
2) Pattern matching of file/directory names using wild-cards
3) Using the executable bit
 

First, if the file ends in a unique suffix, you can exclude all files ending in this suffix using the SUFFIXES environment variable. Second, you can exclude the file specifically by putting it in the environment variable COMP_EXCL. Alternatively, you can exclude the parent directory of the file by including it in COMP_EXCL. This excludes all files in the parent directory.

Third, you can change the permission mode of the file to indicate it is executable.

chmod 755 filename

Unless overridden with the Z option, LONE-TAR does not compress any file that has an executable flag in its permissions.

Please refer to the LONE-TAR UNIX Manual section entitled EXCLUDING FILES FROM BEING COMPRESSED for more details and examples.

 

4.5 UPGRADING OPERATING SYSTEM VERSIONS

The N option (Non-Destructive restore option) is ideal for upgrading operating system versions. The following gives some tips using this option. First, make a Master backup of your entire filesystem using the M option. It is best to make a relative pathname backup using ` . ` rather than an absolute pathname backup using ` / `. This is because if you later want to extract certain files you can move to /tmp and restore the entire ./bin directory under /tmp/bin. Then install your new operating system from scratch. Then you need to move system dependent parameter files. These files vary depending on the system you have, but under XENIX they include the following files:

/.profile
/etc/{rc passwd ttys ttytype printers systemid motd group default/*}
/usr/lib/crontab
/usr/lib/uucp/{L.sys L-devices L-dialcodes USERFILE}

Under UNIX System V Release 3 they would include:

/.profile
/etc/{rc passwd inittab ttytype systemid motd group shadow checklist}
/etc/default/*
/etc/conf/init.d/*
/etc/{gettydefs termcap} (if modified)
/etc/rc2.d/S88USERDEFINE
/usr/lib/terminfo/{any entries that you have modified terminfo for}

Some Networking Configuration Files (not inclusive):

/etc/{hosts hosts.equiv rstab advtab}
/.rhosts

SECURITY FILES

/tcb/files/auth/*
/etc/auth/system/ttys

CRON INFORMATION:

/usr/lib/cron/at.allow
/usr/lib/cron/cron.allow
/usr/spool/cron/crontabs/*
/usr/spool/cron/atjobs/*

UUCP INFORMATION:

/usr/lib/uucp/{Systems Devices Dialcodes Dialers Permissions}

PRINT SPOOLERS:

/usr/spool/lp/admins/{interfaces classes forms printers pwheels}
/usr/spool/lp/{default remote}
/usr/spool/lp/model/{any that you have customized}

The above list is not comprehensive and serves only as a guideline for the types of files that contain configuration information. Once you have installed the new operating system version, you should move these files to another location. Some of them need to be merged by hand with the old version. Once these files are moved to another location, you can use the Non-Destructive restore option to restore your backups. If you have both an Incremental backup and a Master backup, the Incremental backup should be restored first followed by the Master backup using the N option. The order is the opposite of what you might initially think.

This method allows you to upgrade to a new version without having to reinstall all of the default options, password accounts, and uucp files to your system. Everything else is preserved, including the new device files that you have made in the past. You should read your documentation carefully to see which, if any, of the above files has had a change in format from the previous release. In these cases, you need to manually merge the old copy with the new one.

4.6 TESTING & INSTALLING SOFTWARE

If you are given a software package in the TAR format and would like to test it out but later remove the files from the hard disk the following can be done:

lone-tar xvG 443

This installs the files but tags them with a group id of 443 (this could be any number). Then later after completing testing one could remove the files (regardless of where they ended up on the hard disk) by using the find utility as follows:

find / -group 443 -exec rm -i {} \;

This prints each file and asks whether or not to remove it. If you desire to back up only those files that were installed (say after branding during an installation) the following script is used:

find . -group 443 -print | lone-tar cvF -

The G option also works when backing up files as well.

lone-tar cvG 443 files...

This backs up all files and assigns the group id of 443 to these files. This can be confirmed using the tv options. When these files are restored they have the group id of 443 (this could be any number).

4.7 VIRTUAL FILES

LONE-TAR supports the backup and restore of virtual files. Since virtual files are treated in a special way, a list of all the virtual files on your system must be created. It is recommended that this list be kept in /usr/lib/ltar/Virtual.lst.

4.7.1 Anatomy of a Virtual File

It is not well known, but UNIX systems have the capability to create what will be referred to here as virtual files. These are files that list larger than the amount of data actually contained in the file. For example, you could have a file 100 blocks when listing, yet it contains only 5 blocks of data. The reason for this is the unique way the UNIX filesystem is set up. If you create a new file and write 4 blocks of data to it, the file is 4 blocks in size. However, if you seek to the 99th block and write one more block of data, the file size will list as 100 blocks. The space from the 4th block through the 99th block is null (zeroes) if you read the file. The actual space for these blocks, however, has never been allocated. This is advantageous because storage space is actually used only when needed.

Virtual files create havoc with tar, cpio, or any other file by file backup program. The reason for this is that there is nothing about the file to signify that it is a virtual file. When an ordinary backup program reads the file, it reads large chunks of nulls and writes these to the backup device.

If you later restore the file, the actual nulls are restored and the space will be allocated. This does not affect the performance of programs that use this file but it could cause your system to run out of hard disk space unexpectedly.

 

4.7.2 How LONE-TAR Deals with Virtual Files

Activation of the virtual file backup feature is accomplished by setting the environment variable VIRTUAL_LIST. This should be set to the pathname of the file containing a list of all the virtual files on your system. It is recommended that you set this as follows:

VIRTUAL_LIST=/usr/lib/ltar/Virtual.lst
export VIRTUAL_LIST

The files in this list can be listed one file per line and can be in either absolute or relative pathname format. Apart from setting the environment variables above, there is no other special action or option needed. Simply run LONE-TAR as you normally do, and the virtual files specified in the list are backed up. These files are backed up first before other files listed on the command-line. You are informed of the percentage of real data that is actually in the file. A sample output to the screen would appear as follows:

a /usr/vpix/C:, 714 blocks <Virtual file: 55% real data>

This means that of the 714 blocks, only 55% are real data. The rest are virtual data consisting of nulls. Keep in mind that compression works fine with virtual files. The file is compressed after the null data is removed.

 

4.7.3 Compatibility

If the standard TAR utility restores a file that has been backed up as a special virtual file, it remains in a compacted state and is unusable. The proper data is inside the file but the virtual null data is not restored. Just as you do not send a tape with compressed data to someone else to read with the TAR utility, do not send them a tape with virtual files either. Only LONE-TAR can re-virtualize these files.

 

4.8 RESTORING ENTIRE FILE SYSTEMS FROM SYSTEM CRASHES

LONE-TAR can be used to very effectively move or restore large filesystems from a tape archive. The secret is to put LONE-TAR on the boot floppy filesystem. This can be done by mounting the boot floppy on a directory, making sure there is enough room for LONE-TAR (if not, remove non-essential files) and then using the cp command to copy LONE-TAR to the /bin directory on the boot floppy filesystem. Then unmount the boot floppy filesystem. Now if you ever have to restore from a system crash you can boot from floppy, remake the filesystem using the mkfs command, mount the new filesystem on the boot floppy, change directory to the new mount point, and then invoke LONE-TAR to extract all files from the tape archive. You do not have to worry about device files, symbolic links, empty directories, etc. This makes the restore process very simple.

4.9 EXCHANGING TAPES WITH OTHER COMPUTER SYSTEMS

4.9.1 QIC Format Tapes

The most common problems encountered arise because the same block factor and capacity was not specified on both ends. If these two items are taken into careful consideration you should not experience any problems with data transfer between systems.

If you have both the /dev/erct0 and /dev/rct0 tape drivers, when transferring tape to another system, it is best to use the /dev/rct0 driver. This puts data in the industry standard QIC format.

 

4.9.2 4mm or 8mm Tapes

A big problem in transferring data on these tapes is that there are two modes in which these tape drives can write data. Each method is incompatible with the other. The tape drive is jumpered for one of the two methods when shipped. The first method is called fixed-block-mode and the second is called variable-block-mode. Although the tape drive is jumpered for one mode or the other, the modes can also be changed through software. SCO UNIX SCSI tape drivers use the fixed-block-mode as the default and SUN OS tape drivers use the variable-block-mode as the default.

If you send an 8mm tape written by a tape drive in variable-block-mode to a computer whose tape drive uses fixed-block-mode you simply are not able to read the tape. The modes are incompatible with each other.

If you try to read a tape written in fixed-block-mode on a tape drive that uses variable-block-mode, it can only be done using a block factor of 2.

If you try to read a tape written in variable-block-mode with a tape drive that uses variable-block-mode, the only way to do this is to use the same exact block factor on the restore as was used on the backup. Otherwise, you receive SCSI error messages about illegal length.

There is only one way a variable-block-mode tape drive can transfer data to a fixed-block-mode tape drive. If the backup on the variable-block-mode tape is done with a block factor of 2, it can be read with a fixed-block-mode tape drive using the same block factor. This is the one exception to the rule stated above stating variable-block-mode and fixed-block-mode are totally incompatible.

 

4.9.3 Byte Swapped Data

Occasionally, you need to byte swap data in order to successfully transfer it. The following command shows how to use LONE-TAR to read a tape with byte swapped data that was written using a block factor of 20.

dd if=/dev/rct0 ibs=20b obs=8k conv=swab | lone-tar xvf -

Some versions of LONE-TAR have a -zSWAB option that automatically does byte swapping on a backup or restore.

 

4.10.1 Unattended Backup Fails

There can be several reasons for the failure of an unattended backup. The most common problem is that the cron utility stops running. Although in theory this should never happen, in practice it does. You can make sure that the cron utility is running by using the following command:

ps -e | grep cron

If you see a line containing the word cron, then it is running. If you see nothing, then the cron utility is not running. You should check the clock specification file to be sure it contains the command-line invoking the unattended backup. Under XENIX the file is called /usr/lib/crontab. Under UNIX it is called /usr/spool/cron/crontabs/root. Under UNIX System V, one reason for cron failing is the system was shutdown improperly and when it came back up the file /usr/lib/cron/FIFO was present. If this file is present, cron does not run. As soon as cron starts running, it creates this file. When the system is shutdown properly, this file is removed.

You should check your system clock using the date command. The system clock could be set for the wrong time. This is especially possible after a hardware crash or change of a system component.

You should check the mail as the root user. If the backup starts and fails, the mail is sent to the root user. Alternatively, there may be a message on your default system printer.

You can see if LONE-TAR is already running. Sometimes, the unattended backup fails because LONE-TAR is already running and hung up for one reason or another. Also, the unattended backup from the night before may have filled one tape volume and is waiting for a reply after you switch tape volumes. The command to see if LONE-TAR is already running is:

ps -e | grep lone-tar

You should check to be sure that you can invoke LONE-TAR manually and that it runs okay. Be sure to use the same parameters the unattended backup uses

 

4.10.2 Tape Light Stays on, but there is No Tape Activity

This is referred to as a hung tape drive. This results when the tape drive has finished writing a chunk of data to the drive and signals the tape driver that it is ready for more data by issuing an interrupt. But the interrupt is never received by the tape driver. This can happen with an interrupt conflict. The most common interrupt conflicts are with serial port (interrupt 3) or with a second parallel port (interrupt 5). In these cases, the driver for the serial port or second parallel port receives the interrupt instead of the driver for the tape drive.

Under SCO you can check for possible conflicts by running the command hwconfig. This shows you the settings of your currently configured hardware. Look at the interrupt settings for any conflicts.

When you have a hung tape drive you cannot use the <DELETE> key to interrupt LONE-TAR. In fact, you cannot even kill LONE-TAR with a kill -9 command. The reason for this is that LONE-TAR is in kernel mode waiting for the tape driver to return and the tape driver is waiting for the interrupt from the tape drive. Sometimes, taking the tape out and putting it back in makes the tape drive usable again. Sometimes turning the unit off and then on again is useful. Sometimes issuing another command that accesses the tape device is useful. There are situations, unfortunately, in which the only solution is to reboot the computer.

 

4.10.3 Cannot Kill LONE-TAR even with kill -9

This happens when the tape drive is hung as explained above. LONE-TAR has been put to sleep by the kernel while it is waiting for the tape driver to return. Since the kernel tape driver routine is hung waiting for an interrupt that never occurs there is nothing that can be done short of making the tape drive generate an interrupt. This can be done by taking the tape out, turning it off and on, putting another tape in, or trying to access the tape device from another terminal.

This situation is not LONE-TAR's fault. It is in kernel context with a hung tape driver and cannot be killed. The same problem can occur with tar, cpio or any other utility that uses the tape driver.

 

4.10.4 Tape Verified Fine, but when Restored, an I/O error 5 occurred

In this case, the tape was probably exposed to electromagnetic radiation between the time it was verified and the time it was restored. The most common cause for this is the tapes are stored near the computer monitor or on a shelf just above a computer monitor or terminal. The electrostatic surge of turning the monitor or terminal on or off weakens the magnetic charge on the tape and introduces an error.

All tapes and other magnetic media should be stored at least 16 inches away from any electromagnetic fields. For stronger electro-magnetic fields, this distance should be increased.

 

4.10.5 Distinguishing Software Errors from Hardware Errors

There are two types of basic errors that can occur when restoring data. The first is a software error. This means that there is data returning from the archive device, but the data is not in the format expected by the backup program. This can happen if the data on the archive media was overwritten or partially overwritten by another piece of software. Also, the data may have been written in a different format.

One classic example of this occurs under the SCO XENIX or UNIX operating systems. Data is backed up using /dev/erct0 as the backup device. This device does error correction and pads the data on the tape with additional error correction information. Then someone decides to restore the data using /dev/rct0 as the tape device. Because this device does not understand how to interpret the additional error correcting information, this information is returned along with the actual data. The combination of two types of data causes LONE-TAR to realize the data is not in proper format. It then aborts with an error message as follows:

lone-tar: directory not in proper format
 

If you see the above message, you know you are dealing with a software error and that the data on the backup media has somehow become corrupted or was never in the TAR format. The integrity of the media, however, is okay. You do not need to get new floppies or tapes or replace the tape drive.

A hardware error, on the other hand, presents itself in a totally different fashion. You receive a message about an I/O error. In most cases this is an error 5. This means that the media has been damaged, either physically or electro-magnetically. Alternatively, your tape drive, floppy drive, or cabling may have a hardware problem.

lone-tar: Tape Write ERROR 5 occurred because I/O error
Offset is 2000K
Room left is 42000 K

This means that the data simply could not be read from the device. This is a hardware error.

 

4.10.6 Directory not in Proper Format

This really means that the data on the archive media is not in the TAR format. The word ``directory'' is confusing. In this context, it refers to the directory of information on the media referring to files. This information has been scrambled, corrupted or was never correct.

 

4.10.7.1 Same filesystem

If you run out of space restoring data to the same filesystem from which it was backed up, there can be several explanations. First, a large file may have been created on the system between the time you backed up and restored. Most commonly, this occurs when you clean the system using fsck and orphan files are put in the ./lost+found directory. Check this directory and remove any files that are not needed. Second, you may have intended to back up only one filesystem but in fact backed up much more than this. Check the listing of the tape and see if there are files on it that you did not intend to back up. Third, if the filesystem you are restoring to has any filesystems mounted on it, the mount may have failed and you don't really have any filesystems mounted. You can check this with the mount command to be sure the proper filesystems are mounted.

Fourth, you may have a problem with virtual files that were not marked and backed up as special virtual files. In this case, they occupy much more space on the hard drive after the restore than they did before the backup. The clue to this problem is the size of the file. If it is very large it could be a virtual file. Your best bet is to exclude the offending file fro the restore. Then, take the tape to another system with more space and try to restore the virtual file. You should review the section entitled VIRTUAL FILES in the manual to see how to properly back up virtual files so that this does not happen again.

 

4.10.7.2 XENIX Operating System

All of the above reasons and solutions also apply to XENIX. In addition, this can represent a hardware problem with your hard disk drive or controller. The XENIX filesystem free list is like a linked chain. If there is any break in any link, it appears that there is no free space left on the filesystem. This occurs without hard disk error messages especially if you have a bad cable.

The clue to this type of problem is that the file that is being restored when you run out of space is not very large. If you repeat the restore, the error occurs in a different location on the tape.

 

4.10.8 Backed up a file, but LONE-TAR cannot find it when I Restore

There are several reasons for this type of problem. Most commonly you have misspelled the name when you restore the file. If you are using the F option and have put the filename to restore into another file, you may have accidentally put a space character or two at the end. Try deleting the name and re-enter it being careful to end the filename properly.

You should list the files on the media to be sure the one you want is there. Be sure you are using the UNIX forward slash '/' in the pathname rather than a DOS backslash '\'. When working in both environments it is easy to get confused.

When all else fails and you see the file listed but cannot get it off, the following technique has proven to be very useful:

TARFILE=/tmp/List
export TARFILE
lone-tar tVf /dev/rct0
/usr/lib/ltar/filecnvt /tmp/List > /tmp/List2
vi /tmp/List2 (or whatever word processor you like)

Remove all files except the one you want, then run:

lone-tar xvF /tmp/List2

The filenames are captured into a catalog file and this file is converted to a raw list of names. At this point the spelling is guaranteed to be correct. All other files from the listing are then removed. Finally, this list which contains the files you are interested in is used as the list from which to restore. This always works!

 

4.10.9 There are Stp Error Messages on the Console in the Morning

Some drivers report error messages about the SCSI tape not being ready and these appear on the console in the morning after an unattended backup. This results from the SCSI requirement to reset a SCSI device twice after certain commands. Some tape drivers don't realize the SCSI device needs to be reset twice and report the initial failure as an error message. Ultimately, a repeat reset is done and all is well.

 

4.10.10 Trouble Restoring Floppy Disks Created with DOS-TAR

Most of the problems result from not re-using the same exact block factor and capacity that was used when the data was backed up. If special attention is directed to these two items the data transfer proceeds smoothly. Keep in mind that the SCO version rounds a block size of 1 up to 2.

 

4.10.11 DOS Files are Converted When They Should Not Be

You do not want the DOS files converted and you keep seeing the message
``DOS textmode conversion'' after some of the files being restored. You should turn off automatic textmode conversion with the -zNOCNVT option.

 

4.10.12 After a Full Restore the Master Backup Date is Incorrect

This is a side effect of the way the Master backup date is updated. Since it is updated at the completion of the backup (only if successful), when the file ./etc/Master_backup is backed up, it still has the old date in it. When you do a full restore, the old date is restored.

The solution is to use the touch utility to adjust the date as follows:

touch /etc/Master_backup

This solution should be performed immediately after the full restore before any files have been modified. Alternatively, after the full restore and any adjustments have been made, you can run a fresh Master backup.

 

4.10.13 Restore Prompts for more Tape Volumes than Exist

This happens if you use a smaller capacity for the tape than was used to back it up originally. The most common example of this is a 150 Megabyte tape being restored as a 60 Megabyte tape. After only 60 Megabytes of the 150 Megabyte tape have been read, you are prompted to switch tape volumes. If you are not sure what capacity was used when the tape was backed up, it is best not to use any capacity when you restore. LONE-TAR determines when it needs to switch volumes. If a file is split across tape volumes, LONE-TAR switches after it reads the first part of the split file. Otherwise, LONE-TAR stops at the proper end of the tape and will require another invocation of the command-line to read each subsequent tape.

 

4.10.14 Restore Prompts for another Tape Volume before it should

This is similar to the above problem. A smaller tape capacity was specified on the restore than on the original backup. When you insert a second tape, you receive a ``Directory not in proper format'' error.

 

4.10.15 After a Full Restore SCO fixperms Utility Finds Problems

This is similar to the above problem. The SCO fixperms utility compares a static database of file permissions and ownerships to the actual files on the hard drive. Any differences are noted and modifications are made if desired. However, if your backup was done in multi-user mode rather than single user mode, you will note differences caused by daemons and other software that are running in multi-user mode. For example, the print spooler package changes the permissions of certain spooler files while it runs and changes them back when it shuts down.

For this reason, the SCO fixperms utility may find some differences. These are usually insignificant. They do not reflect a problem with the way LONE-TAR restores file permissions. If you believe you have a problem, you should run fixperms in single-user mode before doing a Master backup in single-user mode. Then do a full restore to a fresh hard disk. Then run fixperms again and you should see no differences. You will note that all permissions and ownerships are the same.

 

4.10.16 After a Full Restore some File Permissions Appear to have Changed 

LONE-TAR reliably restores the file permissions to what they were when the system was backed up. There are some files that change owner and permissions on a regular basis when the system is in multi-user mode. The login program, for example, changes the owner of the terminal to that of the person logging in. Also the permissions of the terminal are changed. UUCP changes the permissions and ownership of dial out ports while they are in use.

Therefore, any differences that are noted are those that normally occur on an active multi-user system. If you run your backups while in single-user mode, the restored permissions and ownerships are identical to the single-user mode filesystem.

If you restore using a Non-Destructive restore, some directories that were in place before the restore began, do not get their permissions updated. Thus, it can appear that the restore did not set all the permissions.

 

4.10.17 After a Full Restore the Catalog File is Missing Files

This can be noted after a full restore. If you examine the catalog file that reflects the backup that was just restored, only about one half the files are present. This is because at the time the catalog file itself was backed up, it contained only those files that had been backed up at that point in time. It did not contain all the files on the system.

Therefore this phenomenon is a side effect of the normal backup and restore process. If this is bothersome to you, it can be eliminated by setting the environment variable LAST_FILE to the name of the catalog file. Even though the file is backed up twice, the second time includes the complete catalog file except for the backup summary. When you restore the backup, the catalog file contains all the files on the disk.

 

4.10.18 After a Full Restore Special Device Files have Different Major and Minor Numbers

This can occur if you already have a device file present with a major and minor number different from that on the backup tape. When you restore you see the message:

Will not extract because...File exists

This is a safety mechanism. If the device file already exists, the major and minor numbers cannot be changed. The file would have to be removed first. However, the permissions and ownerships are changed to reflect those on the tape.

 

4.10.19 An Option in the Manual does not Appear on the Help Screen

The help screen is designed to show the most commonly used options and what they do. It is not a comprehensive list. There are so many options for the product that this would take several screens. For less commonly used options, you should refer to the written manual.

 

4.10.20 File Access Times are Changed even with the -a Option

This can occur if you are running a Bit-level-verification after the backup. This Bit level verification changes the file access times during the compare. Simply use the -a option modifier as part of the Bit-level-verification command and your access times won't be affected.