8.2.4 User Data

8.3 Verifying System Backups

The only method to verify that the system backup will correctly restore with no problems is to actually restore all the files listed in the company's Disaster Recovery Plan. However, in order to minimize problems due to tape media damage, there are a number of ways you can verify whether your backup has been done properly or not:

Note

The only way to verify that the mksysb tape will successfully boot is to bring the machine down and boot from the tape. No data needs to be restored. Data verification can be done using the preceding techniques.

However, caution must be taken if the PROMPT field in the bosinst.data file is set to NO, which will cause the system to begin a mksysb restore automatically.

8.3.1 Using SMIT to Verify a Tape

Generally, mksysb is an unattended activity, therefore you need to look for errors that might have occurred during the save operation and will render data unavailable once you try to restore it. It is always a good practice to look at your smit.log file after a mksysb is run from SMIT. It is recommended that you do not run mksysb directly from the command line in order to ensure that you do not miss errors generated during a save operation.

In order to verify the mksysb tape use the SMIT fast path:

smitty lsmksysb

A screen similar to Figure 101 will be shown.



Figure 101: List mksysb Tape Contents

  1. Select your backup device name.

  2. Select defaults for all other parameters and press Enter=DO. This will list the contents of your mksysb tape and log them in the smit.log as shown below: 
    New volume on /dev/rmt0.1:
Cluster size is 51200 bytes (100 blocks).
The volume number is 1.
The backup date is: Tue Nov 10 17:02:28 CST 1998
Files are backed up by name.
The user is root.
./bosinst.data
./image.data
./tmp/vgdata/rootvg/copied.map
./tmp/vgdata/rootvg/fslv00.map
./tmp/vgdata/rootvg/hd1.map
./tmp/vgdata/rootvg/hd2.map
...

    Cross check the listing and verify that none of your important files are missing. This will ensure that data will be available to you once you need it. The listing that is generated as a result of executing this command is helpful in finding out the date this tape was generated, which might help you if you do a mksysb on a regular basis and do not rotate tapes. If your tape tags are accidently destroyed you can still find out the latest backup you have by using this method.

8.3.2 Using Restore to Verify a Tape

In order to verify a mksysb tape without using SMIT, you need to use the restore command since all the files with mksysb are backed up in backup file format using backup command.

Data on a mksysb tape is written from the fourth file marker onwards (see section 8.2 The Data Layout of a mksysb Tape for details on mksysb tape format), therefore you need to control the tape manually to move to the correct segment of the tape. Use the tctl command to control the tape. The general syntax of the tctl command is as follows: 

tctl [ -f Device ] [ eof | weof | fsf | bsf | fsr | bsr | rewind | offline | rewoffl | erase | retension | reset | status ] [ Count ]

The tctl command gives subcommands to a streaming tape device. Subcommands most frequently used by tctl are listed in Table 14.


Table 14: tctl Subcommands

To see the contents of the mksysb tape use the following sequence of commands:

  1. Rewind the tape using the command: 
    tctl -f /dev/rmtxx rewind

  2. Move to the fourth file marker, read the contents of the tape and redirect the output to a file using the command: 
    restore -s4 -Tvqf /dev/rmtxx.1 > /tmp/mksysb.log

This will generate a listing similar to the smit.log output shown in section 8.3.1 Using SMIT to Verify a Tape.

Note

You may encounter an error similar to: 

0511-160 Cannot read backup media
/dev/rmtx.1 There is an input or output error.

If this happens, your tape block size has changed since your last backup, use the following command to reset the block size: 

chdev -l rmtxx -a block_size=0

8.4 Saving User Data