A formal backup process is really an insurance policy. You will invest in the technology and time to back up systems resources so that in the event of a problem you can rebuild the same system configuration as before, with some reliability.
To determine a backup strategy there are three areas that require consideration:
The general issue you are attempting to balance is the trade-off between the time taken to back up and restore information via a particular technology versus the costs of the backup unit, operators, and removable media. The other major issue that will influence the choice of backup technology is the need to exchange backed up information with other systems.
System data makes up the operating system and its extensions. This data should always be kept in the system file systems, namely / (root), /usr, /tmp and /var.
User data is data which the users need to complete their specific tasks. This data should be kept in /home or in any file systems that are created specially for users. User programs and text should not be placed in file systems designed to contain system data.
If the user data is kept separate from system data, it is easier to manage backups. In general, a backup of user and system data is kept in case data is accidentally removed or in case of a disk failure. When doing backups for these reasons, you should back up the system data separately from the user data.
There are two reasons for keeping data separate from user data:
smit startup smit mksysb mkszfile && mksysb /dev/rmtX.Yare different ways of calling the mksysb program to do a complete backup of all the jfs mounted file systems in the rootvg volume group. If you have more than one volume group (you can use lsvg command to check), you must use one of the backup commands (backup, tar, pax or cpio) to back up the other volume groups, since mksysb only backs up the rootvg volume group.
The mksysb backup makes a bootable tape that can be used to completely rebuild your system or to recover one or more files. It backs up everything in the rootvg volume group, including the ODM database. The ODM contains device configuration data.
Passwords are also restored from a mksysb tape. This can create security problems.
Before using the mksysb command you have to decide if you will keep the user file systems of rootvg mounted.
node mounted mounted over vfs date options
---- --------------- ------------ ---- ------------ ---------------
/dev/hd4 / jfs Jul 28 18:43 rw,log=/dev/hd8
/dev/hd9var /var jfs Jul 28 18:43 rw,log=/dev/hd8
/dev/hd2 /usr jfs Jul 28 18:43 rw,log=/dev/hd8
/dev/hd3 /tmp jfs Jul 28 18:43 rw,log=/dev/hd8
If a local directory is mounted over another local directory, this procedure will back up the files twice. Therefore, you should unmount any local directories that are mounted over another local directory.
# tctl -f/dev/rmtx rewind
# tctl -f/dev/rmtx.1 fsf 3
# tar -xvf/dev/rmtx.1 ./path_name/file_name
This section discusses some points about the backup and restore procedures of the whole system.
This procedure is described in the AIX Installation Guide. Here is the explanation of the two commands mkszfile and mksysb:
This procedure is described in the AIX Installation Guide. However, some notes follow:
Either the / or /tmp file system is not big enough, or mksysb was run outside of SMIT (from the command line or from a script) without the mkszfile command being run first.
When a system is installed from a mksysb tape, the paging space is recreated based on the size of memory at the time of the reinstallation. If you have increased memory and if there is not enough free disk space to hold the corresponding increase in paging space, there will be problems with the creation of logical volumes during installation.
If you encounter this error, you should leave the system as it is and contact your branch office to discuss the recovery options.
This means that one of the file systems has run out of free space.
If you encounter this error, you should leave the system as it is and contact your branch office to discuss the recovery options. There is more than one way to recover, and your branch office can help you determine the best method for your situation.
Sometimes this error may occur if you did a backup of a file system whose mount point starts with /u, for instance /u/catia. Actually this may occur with any file system whose mount point contains a symbolic link (/u is a symbolic link on /home). At restoration time of the mksysb tape, the system first creates the logical volumes and the mount point directories. /home is created and /u/catia also in our example, since it is a file system. Later, when the system files are restored, the system tries to create the symbolic link /u on /home, but can't do it because /u already exists as a directory. That's why you get the tar error message. What you can do in this case is to change the name of this kind of file system (/u/catia) before the mksysb backup and after the restoration. For example /u/catia should be modified into /home/catia, temporarily.
Before backing up a file system, you have to choose the type of backup you will use.
You can choose four aspects of the backup from the list of eight shown
below. Each of the four aspects is chosen from two alternatives shown within
one of the rows in the table below.
Figure: Terminology of Backup Types
This procedure backs up all files changed since the last level backup of the file system.
Each leveled backup will capture all files to the n-1 level backup.
# backup -0 -u /
# backup -4 -u /
The level -4 backup will capture all files for the root(/) file system that have been modified since the level -0 backup.
Use the -u flag when doing an incremental backup. Specify the -Level parameter to ensure that information regarding the last date, time, and level of each incremental backup is written to the /etc/dumpdates file.
Special files associated with each tape device determine which action is taken during open or close operations. These files also dictate, for applicable devices, at what density data is to be written on the tape.
There are two density settings in AIX. You can see and change the density settings by typing smit chgtpe. Here are some possible values for the density settings of tape drives:
The following table shows the different extension number you can use with
these special files and their corresponding characteristics:
Figure: rmt Special Files
The density value (bytes per inch) is ignored when using a magnetic tape device that does not support multiple densities. For tape drives that do support multiple densities, the density value only applies when writing to the tape. When reading, the drive defaults to the density at which the tape is written.
Most tape drives use 512 byte block size. The 8mm tape drive uses a minimum block size of 1024 bytes. If SMIT is used to lower the block size, it will waste space.
For more information about the tape see the System Management Guide for AIX Version 3.2.
If you need to make multiple backups on one tape, you should leave the tape in the tape drive. However, if you need to take the tape out, here are the steps to follow to add backups to the end of a tape.
This example is with an rmt0.1 high density, no rewind and no retension tape, used to make the backup of four users directories.
# find /home/user_1 -print | backup -ivf /dev/rmt0.1 (leave tape in)
# find /home/user_2 -print | backup -ivf /dev/rmt0.1 (leave tape in)
# find /home/user_3 -print | backup -ivf /dev/rmt0.1 (take tape out)
# tctl -f /dev/rmt0.1 fsf 3 (go to end of tape)
# find /home/user_4 -print | backup -ivf /dev/rmt0.1 (backup data)
These commands move the head of the tape drive to the end of the third backup, then back up a fourth user's data.
# tctl -f /dev/rmt0 rewind
# restore -Tvf /dev/rmt0.1 -s1 (reads the first backup - user_1)
# restore -Tvf /dev/rmt0.1 -s1 (reads the second backup - user_2)
# restore -Tvf /dev/rmt0.1 -s2 (reads the fourth backup - user_4)
The -s flag starts from the position of the head and selects the backup # to restore. To list the second and the fourth backup files you would issue the commands:
# tctl -f /dev/rmt0 rewind
# restore -Tvf /dev/rmt0.1 -s2 (second backup)
# restore -Tvf /dev/rmt0.1 -s2 (fourth backup)
If you ever lose your place on the backups, use the tctl rewind command to move the head to the first position on the tape. If you forget how many backups are on the tape, use the restore command with the -s# option.
# restore -f /dev/rmt0.1 -s1
This command keeps a list of the number of times you used this command. When you try to restore the end-of-tape mark, you will receive an error. You can figure out how many backups are on a tape by typing the command multiple times. You can skip the number of backups and add an additional backup.
For more information concerning the backup, tctl, and restore commands see InfoExplorer under List of Commands. The rmt extensions are referenced in InfoExplorer under the rmt special file search keywords.
AIX V3 provides facilities to automate any repetitious tasks such as backups. This can be done by using facilities such as cron or at commands to start the backup process at specified times.
If backup commands require a few steps to work correctly, it could be a good idea to incorporate the backup and associated commands in a shell script. For example, to perform a daily backup see Scripts.
Use the smit backup command and follow the menus. Use this procedure for backing up single and small file systems by name, such as /home on your local system. Before using the SMIT method, note the following:
If you want to back up file systems that may be in use, you should unmount them first to prevent inconsistencies. If you attempt to back up by inode a mounted file system, a message is displayed. The backup command continues, but inconsistencies in the file system may occur. This warning does not apply to the root file system.
The command fuser can help you when you have problems running the command unmount. This command fuser is used to determine what processes are currently using a particular file system in order to stop the processes. The system administrator can then unmount the file system and make a file system backup. The option -u gives the name of the user that is using it, and the -k option immediately kills all processes using it.
It is important that you back up data and file systems that are usable, that is to say not corrupted. If you back up corrupted data, you may be in an unrecoverable situation. Here are some techniques that can be used to check for corruption:
You should establish a backup log and tape labelling systems to track all backups and backup media. When backups are made log entries should be made noting the time, date, and content of the backup. A suggested logging and labelling scheme is as follows:
Date Tape Backup Who Notes 13 Jul G008 Full System SW 14 Jul G017 Daily Incremental PAD 15 Jul G011 Daily Incremental PAD 16 Jul G014 Daily Incremental PAD 17 Jul G017 Daily Incremental PAD Failed, tape fault 17 Jul G002 /home/swamy, at swamy request SW Backed up by name
# restore -Tvf /dev/rmt0
After you have set up a functioning backup strategy, it will be important to test recoverability. You should ensure that your recovery process and backups do what you want, which is to provide a way of recovering from a disaster. You should run a simulated disaster recovery exercise about one to two months after your system was established. You should use this exercise to test that your strategy works. If a recovery exercise reveals minor or major failings you should adjust your strategy accordingly.
Files must be restored using the same method by which they were backed up. If a file system was backed up by name, it must be restored by name. Anyway, if you don't use any particular flag, the restore command finds itself which format to use.
There are several other commands that create backups and archives. The backup and restore commands are unique to IBM.
We are not the only vendor that has unique commands. There are only a few backup commands that AIX, System V** and BSD have in common. They are dd, cpio, and tar.
Here are the backup commands you can use on an AIX system:
You can get more information about these commands in InfoExplorer.
Let's work with a system called pippin as an example for a backup strategy. The system pippin features two major applications. The accounting application LH and office applications. The system pippin has only one volume group: rootvg.
We must summarize the file systems key characteristics as the first part of
our backup planning process, such as in the following table:
Table: File Systems Information for Pippin
We can now start to formulate our backup strategy. We have only one high critical file system, which is /lh/data. It is clear that we should back these files up as frequently as possible. This generally means a daily backup. We have a large number of medium critical file systems. These are all generally software, but they also include the data in user's files in /home. We should back up this information at a regular interval. Weekly backups are the next frequency level used.
Why select weekly backups? The rationale is to keep the backup regimes simple and easily integrated with normal business processes and cycles. After a daily cycle, weekly is the next greater cycle that most organizations use. The next cycle would be monthly and we could use that cycle also. In this example we have chosen weekly because users have their spreadsheets and word processing data held on the system and a loss of three weeks of changes would be considered unreasonable as people probably could not remember what they had done.
This raises the point that some of the information in /home may in fact be critical to individual users. This being the case we can implement a scheme where users can, during the day, back up their own files if they feel that is critical. The smit backup command would allow them to do this.
Finally we have two low critical file systems: /oa and /tmp, which we can back up at monthly intervals or not at all.
It is important to note here that the choice of an 8mm tape drive makes the design of our backup scheme much simpler. The 8mm tape can hold over 2GB on a single tape.
To back up the critical data in /lh/data we will need to back up its contents daily. You will note that 20% of this file changes per day, and that it is 300MB in size. This means that daily backup will be of the order of 60MB if we only back up changed items, or 300MB if we back up all data. If we had a 150MB capacity 1/4" tape, we would find that we are forced to use incremental backup. This is because we may probably want to run an unattended daily incremental backup, but would need to run an attended backup to back up all of /lh/data (300MB or about two tapes).
The remainder of the system accounts for about 372MB of information that we will need to back up weekly. The low priority file system /oa is only 20MB. So, even though it is low priority, we should add it to the weekly backup of the other major file systems. This will simplify the backup scheme, and with the 8mm tape we have plenty of space on the tape. Alternatively we could not back it up at all and rely on the original installation media. If you wish to err on the side of safety, add it to the weekly backup.
In summary our backup strategy will be:
Table: Backup Strategy, File Systems and Frequencies
From among these major backup types we need to select the most appropriate
commands. For our example we have selected the following:
Table: Backup Strategy, Commands to Use
This strategy minimizes the number of tapes and subtleties involved. There are weekly and daily backups that back up everything they need to.
# daily.backup
#
# This script will back up /lh/data on a nightly basis.
# It can be executed via cron or from the command line
# Requires root authority to function correctly
# Set permissions to be -rwxr--r-- user=root group=system
#
# This script does not include handling of common error conditions
#
# This script does not include logging of progress and logging of
# errors. It is recommended that this be added for a production script.
#
# Set up Tape Unit as a variable, tell people what's about to happen.
#
TAPE=/dev/rmt0
#
wall 'The accounting application will be shutdown for backup in 1 minute'
#
sleep 60
#
# fuser will kill processes using /lh/data
fuser -k -u /lh/data
#
# unmount the directory so it cannot be accessed and check it
umount /lh/data
fsck -p /lh/data
#
# back up all files changed since last full backup
backup -1u$TAPE /lh/data
#
# backup completes .... remount
mount /lh/data
#
To perform a weekly backup on pippin we will use the
mksysb script and then stack the level 0 backup of the data at the end
of the tape. We do this to ensure we are using just one tape. Having the
/lh/data separate also helps speed recovery from corruption or loss of
/lh/data.
Recovery is the process of applying the most recent backup material to the
system in the event of some form of failure. It is recommended that you run
a complete system recovery exercise as soon as possible to ensure that the
recovery process works. The recovery process should be documented in the
system log (see Backup Log). By way of example, the
restoration processes for pippin would be as follows:
In the event that the accounting data was corrupted or lost for some reason
it could be restored as follows:
Unmounting makes the file system unavailable for access.
The process of system reinstallation will overwrite, and therefore make
inaccessible, any data currently installed on your system's root volume group.
Note only two steps are necessary because pippin only uses a single volume
group: rootvg.
# weekly.backup
#
# This script will back up the system using mksysb.
# It will then back up /lh/data at level 0.
# It can be executed via cron or from the command line.
# Requires root authority to function correctly.
# Set permissions to be -rwxr--r-- user=root group=system
#
# This script does not include handling of common error conditions.
#
# This script does not include logging of progress and logging of
# errors. It is recommended that this be added for a production script.
#
# Set up Tape Unit as a variable.
#
TAPE=/dev/rmt0
TAPENR=/dev/rmt0.1
#
wall 'The system will be shutdown for backup in 1 minute'
#
sleep 60
#
# Kill all processes and bring the system down into maintenance mode
shutdown -m
#
#Unmount the file system /lh/data so this file system is not in the mksysb
umount /lh/data
# Run mksysb
mkszfile && mksysb $TAPE
#
# Position head at end of data just written (4 separate files)
tctl -f $TAPE rewind
tctl -f $TAPENR fsf 4
#
# Check and backup /lh/data
fsck -p /lh/data
backup -0u$TAPENR /lh/data
mount /lh/data
#
# Reboot the system
shutdown -rF
#
Figure: Weekly Backup Script for Pippin
Recovery
# fuser -u -k /lh/data
# umount /lh/data
# mkfs -V jfs /dev/lv02
# mount /dev/lv02 /lh/data
# restore -rf/dev/rmt0
# umount /lh/data
# fsck -p /lh/data
# mount /lh/data
**** Important! ****