Monday, July 23, 2018
Friday, July 13, 2018
Creating a mksysb backup to tape in AIX
What is a mksysb and why create one ?
A mksysb is a bootable backup of your root volume group. The
mksysb process will backup all mounted JFS and JFS2 filesystem
data. The file-system image is in backup-file format. The tape
format includes a boot image, system/rootvg informational files, an
empty table of contents, followed by the system backup (root
volume group) image. The root volume group image is in
backup-file format, starting with the data files and then any optional
map files.
When a bootable backup of a root volume group is created, the boot
image reflects the currently running kernel. If the current kernel is the
64-bit kernel, the backup's boot image is also 64-bit, and it only boots
64-bit systems. If the current kernel is a 32-bit kernel, the backup's
boot image is 32-bit, and it can boot both 32-bit and 64-bit systems.
In general the mksysb backup is the standard backup utility used to
recover a system from an unusable state - whether that be a result of
data corruption, a disk failure, or any other situation that leaves you in
an unbootable state. You should create a mksysb backup on a
schedule in line with how often your rootvg data changes, and always
before any sort of system software upgrade.
A mksysb tape can also be used to boot a system into maintenance
mode for work on the rootvg in cases where the system can not boot
into normal mode.
Mksysb tape structure
When creating a mksysb to tape, 4 images are created in total.
Image #1: The bosboot image contains a copy of the system's kernel
and specific device drivers, allowing the user to boot from this tape.
Image #2: The mkinsttape image contains files to be loaded into the
RAM file system when you are booting in maintenance.
Image #3: The dummy image contains a single file containing the
words "dummy toc". This image is used to make the mksysb tape
contain the same number of images as a BOS Install tape. This is
merely reference to pre-AIX V4 days when AIX was installed from tape.
Image #4: The rootvg image contains data from the rootvg volume
group (mounted JFS/JFS2 file systems only).
Files important to the mksysb
There are a few files that the mksysb uses in order to successfully
rebuild your rootvg environment. These files are located on the 2nd
image of your mksysb tape. Three of the files you may find yourself
working with are described below.
bosinst.data : This file can be used to pre-set the BOS menu options. Selections such as which disk to install to, kernel settings, and
whether or not to recover TCP related information can all be set here.
This file is mainly used for non-prompted installations. Any option
selected during a prompted install will override the corresponding setting in this file.
For more information concerning the individual stanza descriptions see the publib website PubLib Documentation by searching on "bosinst.data file stanza descriptions". http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.install/doc/insgdrf/bosinst.data_file_stanza_desc.htm
image.data : This file is responsible for holding information used to
rebuild the rootvg structure before the data is restored. This
information includes the sizes, names, maps, and mount points of
logical volumes and file systems in the root volume group. It is
extremely important that this file is up to date and correct, otherwise
the restore can fail. It is common to edit this file when it is necessary to
break mirroring during a restore.
For more information concerning the image.data file and the stanza
descriptions see the publib website PubLib Documentation. by searching on "image.data file".
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/image.data.htm
tapeblksz : This is a small text file that indicates the block size the
tape drive was changed to in order to write the 4th image of the
mksysb. This information would be useful if you wanted to restore
individual files/directories from your mksysb image.
Important information concerning mksysb flags
It is very important that you understand the use and intent of a few of
the flags used by the mksysb command. Improper use, lack of use, or
use of certain flags in certain situations could cause your mksysb to
be difficult to restore. In some cases it may cause your mksysb to be
unrestorable.
-i : Calls the ‘mkszfile’ command, which updates the image.data file
with current filesystem sizes and characteristics. This flag should
always be used unless there is a very specific reason you do not
wish to have this information updated. Failure to have an accurate
image.data file can cause your mksysb restore to fail with “out of
space” errors.
-e : Allows you to exclude data by editing the /etc/exclude.rootvg file.
A few tips on excluding data from your mksysb are listed below :
While the /etc/exclude.rootvg file excludes data, bear in mind that it
does not exclude the fact that a filesystem exists. For example if you
have a 50Gig filesystem “/data” and add an entry in your
/etc/exclude.rootvg file :
^./data
This will exclude all files in /data but it will still recreate the /data
filesystem as a 50Gig filesystem (except it will now be empty).
The only way to truly exclude a filesystem from your mksysb would
be to unmount the filesystem before initiating your mksysb.
-p : Using this flag disables the software compression algorithms.
When creating a mksysb during any level of system activity it is
recommended to use the “-p” flag. Failure to do so can cause
“unpacking / file out of phase” errors during your mksysb restore.
These errors are fatal (unrecoverable) errors. No warning is given
during the creation of the mksysb that notifies you of the possibility
of having these errors during the restore.
You may want to make the “-p” flag compulsory when running your mksysb command so you do not run into this situation.
-X : This flag will cause the system to automatically expand the /tmp
filesystem if necessary. The /tmp filesystem will require approximately
32Mb of free space.
For more information about these and other mksysb command flags, please refer the the mksysb man page.
Creating a mksysb to a tape drive in AIX V5
The only required selection here would be the tape drive to use for
the backup. Default flags are listed above. Change flags as necessary
for your environment / situation.
*Please refer to the section above entitled “Important Information Regarding Mksysb Flags"
2. From command line :
This command reflects the options listed in the above “smitty mksysb”
output. This does not take into account any customization flags.
Please review the section above entitled “Important Information
Regarding Mksysb Flags” to be best informed concerning the
flags that you should use.
Creating a mksysb to a tape drive in AIX V6
The only required selection here would be the tape drive to use for
the backup. Default flags are listed above. Change flags as necessary
for your environment / situation.
*Please refer to the section above entitled “Important Information Regarding Mksysb Flags"
There are a few extra options with V6 mksysb using SMIT. The most
notable being the option “Location of existing mksysb image”. You
can now use an existing mksysb taken to file and copy that to tape. An
attempt will be made to make the tape a bootable tape. You should
use a system at the same or higher technology level and service pack level as the mksysb
image if you choose to do this. The command line flag would be “-F”.
This does require a minimum of 100Mb free in /tmp. See the manpage
for further information. This flag was introduced as a command line
option in AIX V5 (5300-05).
2. From command line :
This command reflects the options listed in the above “smitty mksysb”
output. This does not take into account any customization flags.
Please review the section above entitled “Important Information
Regarding Mksysb Flags” to be best informed concerning the
flags that you should use.
Verification of a mksysb
There is no true verification of the “restorability” of a mksysb other
than actually restoring it. Taking cautions such as understanding the
flags used for the creation of the mksysb, checking your error
report for any tape drive related errors before running the mksysb,
regular cleaning of the tape drive, and verifying the readability of the
mksysb after creation are all good checks.
If your system is in good health your mksysb should be in good
health. Similarly, if you attempt to create a mksysb of a system
logging hundreds of disk errors, or a system with known filesystem
corruption, your mksysb will likely retain that corruption.
To verify the readability of your backup run the following command :
Any errors that occur while reading the headers of any of the files will
be displayed, otherwise only the initial backup header information will
be displayed. Keep in mind that this check tests the readability of the
file only, not the writeability.
Restoring a mksysb
To restore a mksysb image you simply need to boot from the tape and
verify your selections in the BOS menus. Next, we’ll cover two
booting scenarios. One in which your system is currently up and
operational, the next in which your system is down.
1. If your system is currently running and you need to restore your
mksysb, simply change the bootlist to reflect the tape drive and reboot
the system.
2. If your system is in a down state you should boot to the SMS menus
and set your bootlist to reflect the tape drive. The SMS menu options
are listed below. Your menu options may be different (depending on
your level of firmware), however it should be clear enough by following
this document to figure out what options should be chosen if yours differ.
The system will scan itself to determine which devices are available to
boot from. All of your available boot devices will be displayed here.
This menu can be a little tricky. If you have a device pre-selected it
will have a 1 next to it under the “Current Position” column. Use the
“Select Device Number” listing to choose the device you want to boot
from to change that.
The next screen will offer you three choices :
Restore menus
I. From the Installation and Maintenance Menu, select (2):
II. From the System Backup Installation and Settings, you’ll see the
default options that are taken from your “bosinst.data” file. If these are
correct select (0) and skip down to step 6 below.
If you need to change any options such as the disks you would like to
install to select (1):
To shrink the file systems to reclaim allocated free space, select
option 2 so the setting is set to Yes. For the file systems to be
restored with the same allocated space as the original system, make
sure option 2 is set to No.
III. Change Disk(s) Where You Want to Install.
After the desired disks have been chosen, select (0) to continue.
IV. System Backup Installation and Settings, select (0 to continue)
Restoring individual files or directories from a mksysb tape
You may at some point need to restore a file, several files, or
directories from your mksysb. You’ll need to first find the block size the
rootvg data was written at (4th image). Files will be restored relative to
your current location on the system when the restore command is
executed. If you would like the files to return to their original location
run the restore command (step 3) from /, otherwise cd down to the
path you wish the file(s) to be restored.
1. Display the contents of the ./tapeblksz file on the mksysb to
determine the correct block size the tape drive should be set to for the
restore command.
The output that is given is the blocksize to which the tape drive was
set when the mksysb was made.
2. Next, set the blocksize of the tape drive accordingly by running the
following command :
3. Restore the files or directories by running the following commands :
You can specify multiple <pathname> entries for multiple
file(s)/directory structures to restore. Simply separate each entry with
a space. Remember to always use a “./” before each pathname.
**As an alternative you can also use the 'restorevgfiles' command. In
the interest of keeping this document "relatively" short - no further
examples will be given. Please see the manpage for use of this
command.
FAQ
This section is included to provide answers to common questions
asked concerning mksysb. This section is not intended to diagnose
any problem or perform any problem determination. These
questions/answers are intended to hopefully prevent the need to call
up and open a problem ticket for a short duration / short answer
question. If you have any questions that you feel might be helpful,
please submit feedback on this document and it may be added.
1. The rootvg on my mksysb tape has all JFS filesystems, and
I’d like to change them to JFS2 filesystems. How can I do this ?
The only supported method of changing rootvg system filesystems
from JFS to JFS2 would be to run a “New and Complete Overwrite”
installation.
2. Does the mksysb command backup nfs mountpoints ?
No, nfs mountpoints are not followed.
3. Will my non-root volume groups automatically mount after
the restore completes ?
That volume group setting is held on the VGDA of the disk the
volume group is held. There is a new option that will allow this to be
set in the BOS menus, so this should no longer be an issue.
4. The document mentions I can restore files from my mksysb.
Are there any restrictions to what I should/should not restore ?
Absolutely. You do not want to restore any files that are critical to the
system running.
Examples of files you do not want to restore: most library files, ODM
files, applications, the kernel...
Examples of files safe to restore : /etc/group, /etc/passwd, cron related
files, /home, any data filesystems you created....
5. How long will my mksysb take to restore ?
That is dependent on many factors - the amount of data that needs to
be restored being the major player in the restore time. A ballpark rule
of thumb would be 1.5 - 2x the time it took to create the mksysb. You
also have to consider reboot time.
6. The restore appears to be hung at 83%, what do I do ?
First you want to make sure this is a “true” hang. This point in the
restore can take anywhere from 10 minutes to even upwards of 60
minutes depending on the size of the rootvg. Make sure you’ve given
it ample time to bypass this portion of the restore before becoming
concerned.
7. I have a mksysb tape but I don’t know anything about it. Are
there any commands that I can run to get information about the
rootvg it contains ?
There are some very helpful ‘lsmksysb’ commands that can provide all
sorts of information. Some of the things you can find out :
- the ‘lslpp -L’ output to see what filesets are installed on that rootvg
- ‘lsvg -l rootvg’ output will show:
A mksysb is a bootable backup of your root volume group. The
mksysb process will backup all mounted JFS and JFS2 filesystem
data. The file-system image is in backup-file format. The tape
format includes a boot image, system/rootvg informational files, an
empty table of contents, followed by the system backup (root
volume group) image. The root volume group image is in
backup-file format, starting with the data files and then any optional
map files.
When a bootable backup of a root volume group is created, the boot
image reflects the currently running kernel. If the current kernel is the
64-bit kernel, the backup's boot image is also 64-bit, and it only boots
64-bit systems. If the current kernel is a 32-bit kernel, the backup's
boot image is 32-bit, and it can boot both 32-bit and 64-bit systems.
In general the mksysb backup is the standard backup utility used to
recover a system from an unusable state - whether that be a result of
data corruption, a disk failure, or any other situation that leaves you in
an unbootable state. You should create a mksysb backup on a
schedule in line with how often your rootvg data changes, and always
before any sort of system software upgrade.
A mksysb tape can also be used to boot a system into maintenance
mode for work on the rootvg in cases where the system can not boot
into normal mode.
Mksysb tape structure
When creating a mksysb to tape, 4 images are created in total.
+---------------------------------------------------------+ | Bosboot | Mkinsttape | Dummy TOC | rootvg | | Image | Image | Image | data | |-----------+--------------+-------------+----------------| |<----------- Block size 512 ----------->| Blksz defined | | | by the device | +---------------------------------------------------------+
and specific device drivers, allowing the user to boot from this tape.
blocksize: 512
format: raw image
files: kernel device drivers
RAM file system when you are booting in maintenance.
blocksize: 512
format: backbyname
files: ./image.data, ./tapeblksz,
./bosinst.data and other
commands required to initiate
the restore.
words "dummy toc". This image is used to make the mksysb tape
contain the same number of images as a BOS Install tape. This is
merely reference to pre-AIX V4 days when AIX was installed from tape.
Image #4: The rootvg image contains data from the rootvg volume
group (mounted JFS/JFS2 file systems only).
blocksize: determined by tape drive
configuration on creation
format: backbyname (backup/restore)
files: rootvg, mounted JFS/JFS2
filesystems
WARNING: If the device blocksize is set to 0, mksysb will
use a hardcoded value of 512 for the fourth image. This can
cause the create and restore to take 5-10 times longer than
expected. You should set your tape drive’s block size to the
recommended value for optimal performance.
Files important to the mksysb
There are a few files that the mksysb uses in order to successfully
rebuild your rootvg environment. These files are located on the 2nd
image of your mksysb tape. Three of the files you may find yourself
working with are described below.
bosinst.data : This file can be used to pre-set the BOS menu options. Selections such as which disk to install to, kernel settings, and
whether or not to recover TCP related information can all be set here.
This file is mainly used for non-prompted installations. Any option
selected during a prompted install will override the corresponding setting in this file.
For more information concerning the individual stanza descriptions see the publib website PubLib Documentation by searching on "bosinst.data file stanza descriptions". http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.install/doc/insgdrf/bosinst.data_file_stanza_desc.htm
image.data : This file is responsible for holding information used to
rebuild the rootvg structure before the data is restored. This
information includes the sizes, names, maps, and mount points of
logical volumes and file systems in the root volume group. It is
extremely important that this file is up to date and correct, otherwise
the restore can fail. It is common to edit this file when it is necessary to
break mirroring during a restore.
For more information concerning the image.data file and the stanza
descriptions see the publib website PubLib Documentation. by searching on "image.data file".
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/image.data.htm
tapeblksz : This is a small text file that indicates the block size the
tape drive was changed to in order to write the 4th image of the
mksysb. This information would be useful if you wanted to restore
individual files/directories from your mksysb image.
Important information concerning mksysb flags
It is very important that you understand the use and intent of a few of
the flags used by the mksysb command. Improper use, lack of use, or
use of certain flags in certain situations could cause your mksysb to
be difficult to restore. In some cases it may cause your mksysb to be
unrestorable.
-i : Calls the ‘mkszfile’ command, which updates the image.data file
with current filesystem sizes and characteristics. This flag should
always be used unless there is a very specific reason you do not
wish to have this information updated. Failure to have an accurate
image.data file can cause your mksysb restore to fail with “out of
space” errors.
-e : Allows you to exclude data by editing the /etc/exclude.rootvg file.
A few tips on excluding data from your mksysb are listed below :
- There should be one entry per line of the file. It can be either a single file or directory name.
- The correct format of each entry should be ^./<path>
- Never use wildcards.
- Do not leave extra spaces or blank lines in the file.
While the /etc/exclude.rootvg file excludes data, bear in mind that it
does not exclude the fact that a filesystem exists. For example if you
have a 50Gig filesystem “/data” and add an entry in your
/etc/exclude.rootvg file :
^./data
This will exclude all files in /data but it will still recreate the /data
filesystem as a 50Gig filesystem (except it will now be empty).
The only way to truly exclude a filesystem from your mksysb would
be to unmount the filesystem before initiating your mksysb.
-p : Using this flag disables the software compression algorithms.
When creating a mksysb during any level of system activity it is
recommended to use the “-p” flag. Failure to do so can cause
“unpacking / file out of phase” errors during your mksysb restore.
These errors are fatal (unrecoverable) errors. No warning is given
during the creation of the mksysb that notifies you of the possibility
of having these errors during the restore.
You may want to make the “-p” flag compulsory when running your mksysb command so you do not run into this situation.
-X : This flag will cause the system to automatically expand the /tmp
filesystem if necessary. The /tmp filesystem will require approximately
32Mb of free space.
For more information about these and other mksysb command flags, please refer the the mksysb man page.
Creating a mksysb to a tape drive in AIX V5
1. Using SMITTY : # smitty mksysb Backup DEVICE or FILE.........................[/dev/rmt0] Create MAP files?.............................no EXCLUDE files?................................no (-e) List files as they are backed up?.............no Verify readability if tape device?............no Generate new /image.data file?................yes (-i) EXPAND /tmp if needed?........................no (-X) Disable software packing of backup?...........no (-p) Backup extended attributes?...................yes Number of BLOCKS to write in a single output..[]
the backup. Default flags are listed above. Change flags as necessary
for your environment / situation.
*Please refer to the section above entitled “Important Information Regarding Mksysb Flags"
2. From command line :
# mksysb -i /dev/rmt0
output. This does not take into account any customization flags.
Please review the section above entitled “Important Information
Regarding Mksysb Flags” to be best informed concerning the
flags that you should use.
Creating a mksysb to a tape drive in AIX V6
1. Using SMITTY : # smitty mksysb Backup DEVICE or FILE.........................[/dev/rmt0] Create MAP files?.............................no EXCLUDE files?................................no (-e) List files as they are backed up?.............no Verify readability if tape device?............no Generate new /image.data file?................yes (-i) EXPAND /tmp if needed?........................no (-X) Disable software packing of backup?...........no (-p) Backup extended attributes?...................yes Number of BLOCKS to write in a single output..[] Location of existing mksysb image.............[] File system to use for temporary work space...[] Backup encrypted files?.......................yes Back up DMAPI filesystem files?...............yes
the backup. Default flags are listed above. Change flags as necessary
for your environment / situation.
*Please refer to the section above entitled “Important Information Regarding Mksysb Flags"
There are a few extra options with V6 mksysb using SMIT. The most
notable being the option “Location of existing mksysb image”. You
can now use an existing mksysb taken to file and copy that to tape. An
attempt will be made to make the tape a bootable tape. You should
use a system at the same or higher technology level and service pack level as the mksysb
image if you choose to do this. The command line flag would be “-F”.
This does require a minimum of 100Mb free in /tmp. See the manpage
for further information. This flag was introduced as a command line
option in AIX V5 (5300-05).
2. From command line :
# mksysb -i /dev/rmt0
output. This does not take into account any customization flags.
Please review the section above entitled “Important Information
Regarding Mksysb Flags” to be best informed concerning the
flags that you should use.
Verification of a mksysb
There is no true verification of the “restorability” of a mksysb other
than actually restoring it. Taking cautions such as understanding the
flags used for the creation of the mksysb, checking your error
report for any tape drive related errors before running the mksysb,
regular cleaning of the tape drive, and verifying the readability of the
mksysb after creation are all good checks.
If your system is in good health your mksysb should be in good
health. Similarly, if you attempt to create a mksysb of a system
logging hundreds of disk errors, or a system with known filesystem
corruption, your mksysb will likely retain that corruption.
To verify the readability of your backup run the following command :
# listvgbackup -Vf /dev/rmt0
be displayed, otherwise only the initial backup header information will
be displayed. Keep in mind that this check tests the readability of the
file only, not the writeability.
Restoring a mksysb
To restore a mksysb image you simply need to boot from the tape and
verify your selections in the BOS menus. Next, we’ll cover two
booting scenarios. One in which your system is currently up and
operational, the next in which your system is down.
1. If your system is currently running and you need to restore your
mksysb, simply change the bootlist to reflect the tape drive and reboot
the system.
# bootlist -m normal rmt0 # shutdown -Fr
and set your bootlist to reflect the tape drive. The SMS menu options
are listed below. Your menu options may be different (depending on
your level of firmware), however it should be clear enough by following
this document to figure out what options should be chosen if yours differ.
SMS - SYSTEM MANAGEMENT SERVICES - 1. Select Language 2. Change Password Options 3. View Error Log 4. Setup Remote IPL (RIPL (Remote Initial Program Load)) 5. Change SCSI Settings 6. Select Console --> 7. Select Boot Options
The next menu should come up : --> 1. Select Install or Boot Device 2. Configure Boot Device Order 3. Multiboot Startup
The next menu will have the following : Select Device Type : 1. Diskette 2. Tape 3. CD/DVD 4. IDE 5. Hard Drive 6. Network --> 7. List all Devices
boot from. All of your available boot devices will be displayed here.
This menu can be a little tricky. If you have a device pre-selected it
will have a 1 next to it under the “Current Position” column. Use the
“Select Device Number” listing to choose the device you want to boot
from to change that.
The next screen will offer you three choices :
1. Information --> 2. Normal Mode Boot 3. Service Mode Boot
Restore menus
I. From the Installation and Maintenance Menu, select (2):
1) Start Installation Now with Default Settings
2) Change/Show Installation Settings and Install
3) Start Maintenance Mode for System Recovery
default options that are taken from your “bosinst.data” file. If these are
correct select (0) and skip down to step 6 below.
If you need to change any options such as the disks you would like to
install to select (1):
Setting: Current Choice(s):
1. Disk(s) where you want to install... hdisk0
Use Maps............................ No
2. Shrink File Systems................. No
0. Install with the settings listed above.
option 2 so the setting is set to Yes. For the file systems to be
restored with the same allocated space as the original system, make
sure option 2 is set to No.
III. Change Disk(s) Where You Want to Install.
Type one or more numbers for the disks to be used for
installation and press Enter. The current choice is indicated by >>>.
To deselect a choice, type the corresponding number and press Enter.
At least one bootable disk must be selected. Choose the location by its SCSI ID.
Name Location Code Size (MB) VG Status Bootable
>>> 1. hdisk0 00-01-00-0,0 70008 rootvg yes
>>> 2. hdisk1 00-01-00-1,0 70008 rootvg yes
0. Continue with the choices indicated above
IV. System Backup Installation and Settings, select (0 to continue)
Setting: Current Choice(s):
1. Disk(s) where you want to install......... hdisk0...
2. Use Maps.................................. No
3. Shrink File Systems....................... No
0. Install with the settings listed above.
Restoring individual files or directories from a mksysb tape
You may at some point need to restore a file, several files, or
directories from your mksysb. You’ll need to first find the block size the
rootvg data was written at (4th image). Files will be restored relative to
your current location on the system when the restore command is
executed. If you would like the files to return to their original location
run the restore command (step 3) from /, otherwise cd down to the
path you wish the file(s) to be restored.
1. Display the contents of the ./tapeblksz file on the mksysb to
determine the correct block size the tape drive should be set to for the
restore command.
# cd /tmp # tctl -f /dev/rmt0 rewind # chdev -l rmt0 -a block_size=512 # restore -s2 -xqvdf /dev/rmt0.1 ./tapeblksz # cat ./tapeblksz
set when the mksysb was made.
2. Next, set the blocksize of the tape drive accordingly by running the
following command :
# chdev -l rmt0 -a block_size=<number in the ./tapeblksz file>
# cd / (if the file is to be restored to its original place) # tctl -f /dev/rmt0 rewind # restore -s4 -xqdvf /dev/rmt0.1 ./<pathname>
file(s)/directory structures to restore. Simply separate each entry with
a space. Remember to always use a “./” before each pathname.
**As an alternative you can also use the 'restorevgfiles' command. In
the interest of keeping this document "relatively" short - no further
examples will be given. Please see the manpage for use of this
command.
FAQ
This section is included to provide answers to common questions
asked concerning mksysb. This section is not intended to diagnose
any problem or perform any problem determination. These
questions/answers are intended to hopefully prevent the need to call
up and open a problem ticket for a short duration / short answer
question. If you have any questions that you feel might be helpful,
please submit feedback on this document and it may be added.
1. The rootvg on my mksysb tape has all JFS filesystems, and
I’d like to change them to JFS2 filesystems. How can I do this ?
The only supported method of changing rootvg system filesystems
from JFS to JFS2 would be to run a “New and Complete Overwrite”
installation.
2. Does the mksysb command backup nfs mountpoints ?
No, nfs mountpoints are not followed.
3. Will my non-root volume groups automatically mount after
the restore completes ?
That volume group setting is held on the VGDA of the disk the
volume group is held. There is a new option that will allow this to be
set in the BOS menus, so this should no longer be an issue.
4. The document mentions I can restore files from my mksysb.
Are there any restrictions to what I should/should not restore ?
Absolutely. You do not want to restore any files that are critical to the
system running.
Examples of files you do not want to restore: most library files, ODM
files, applications, the kernel...
Examples of files safe to restore : /etc/group, /etc/passwd, cron related
files, /home, any data filesystems you created....
5. How long will my mksysb take to restore ?
That is dependent on many factors - the amount of data that needs to
be restored being the major player in the restore time. A ballpark rule
of thumb would be 1.5 - 2x the time it took to create the mksysb. You
also have to consider reboot time.
6. The restore appears to be hung at 83%, what do I do ?
First you want to make sure this is a “true” hang. This point in the
restore can take anywhere from 10 minutes to even upwards of 60
minutes depending on the size of the rootvg. Make sure you’ve given
it ample time to bypass this portion of the restore before becoming
concerned.
7. I have a mksysb tape but I don’t know anything about it. Are
there any commands that I can run to get information about the
rootvg it contains ?
There are some very helpful ‘lsmksysb’ commands that can provide all
sorts of information. Some of the things you can find out :
- the ‘lslpp -L’ output to see what filesets are installed on that rootvg
- ‘lsvg -l rootvg’ output will show:
- volume group information and oslevel
- total backup size and size of volume group if shrunk to minimum
Backup and Restore With AIX
While there are some strong third-party tools available to you for backup and restore purposes on the AIX OS, don't be afraid of the standard AIX toolset to archive your data.
AIX Tools
As most systems administrators can attest, there is absolutely nothing wrong with using the utilities that come preloaded with your OS to perform standard backup and recovery. While it’s true that in most cases you do get what you pay for, these tools work very well, though they might not scale as well off-the-shelf products you must purchase. I should also point out that using standard OS tools usually means having to rely on several backup utilities in order to properly safeguard all your system data.There are three ways in which to kick-off AIX utilities for backup: the System Management Interface Tool (known as SMIT or smitty), WebSM and the command line. I strongly suggest you use the command line for utilities such as tar, cpio and even mksysb, though I usually have no problems using SMIT for most of the other utilities.
Some of the archiving commands available to you include:
- mksysb—This is the most important utility you should know. Only mksysb lets you recreate your root volume group. Actually, this command will only back up rootvg. There are many flags that you can use with mksys, so I strongly suggest you look at the man pages and fully understand this powerful utility.
- tar—Tar is usually used to archive files and directories rather than entire filesystems. It allows one to create, view or retrieve archived data from either external media or shared network drives.
- cpio—This command copies from and to archive storage device. It’s often used to copy files from UNIX to AIX systems. Though not as widely used, I prefer using cpio to tar because it can restore empty directories.
- dd—This powerful, albeit rarely used, command allows one to make a block-by-block representation of data. It’s very useful in terms of moving data from disparate environments. Decades ago I remember using dd to move ASCII data from my SCO servers to IBM mainframes in EBCDIC, all with dd.
- savevg—This command backs up data belonging to a specific volume group. In many ways it’s similar to mksysb, but for non-rootvg volume groups.
- alt_disk_install—This utility allows one to actually clone systems. It’s used frequently by administrators that have several physical devices in their rootvg. Cloning allows administrators to upgrade their OS and then fall back to other disks in case of a problem.
- multibos—This command allows the root user to make and preserve two versions of the OS in the root filesystem as bootable copies. This option is only available in AIX 5.3.tl3 and higher.
tar
If you don’t need to perform a backup of the rootvg but only backup a filesystem or directory, use this syntax:# tar -cvf /dev/rmt0 /yourdata
This command creates a new archive at the beginning of the /dev/rmt0 tape device and each file is listed during backup.
Restore using the x flag:
# tar xvf /dev/rmt0 /yourdata
mksysb
In the AIX OS, perhaps the single most important command is mksysb. A little known bit of trivia is that IBM was the first vendor who came up with a utility which provided for a full system restore—mksysb. Its purpose isn’t to back up user data, but to create an installable image of the root volume group (rootvg). To reiterate, user data should be kept out of the rootvg. The format of a mksysb includes:- Base Operating System boot image
- Base Operating System install image
- Dummy table of contents (TOC)
- Actual data on the volume group
# mksysb -i /dev/rmt0
This command also creates an /image.data file, which is generated by the mkszfile command. The mkszfile command overwrites the existing /image.data file with new information. The information includes system installation information, logical volume information for the root volume group and filesystem information.
The syntax in using mkszfile is:
# mkszfile -f
With mksysb you can do a complete restore or alternatively selectively restore files. To perform a manual restore of file from a mksysb archive:
# restore -xqvf /dev/rmt0 /myrestorationfile
savevg
In this example I’ll use savevg to backup an entire filesystem:savevg -f /dev/rmt0 oravg
To restore the filesystem on to one of the physical disks:
restvg -f /dev/rmt0 hdisk6
Third-Party Tools
I love Tivoli Storage Manager For System Backup and Recovery, though I admit I liked it more before it was swallowed up by TSM. Among other features it handles multiple volume groups and backups striped over multiple backup devices. It can even restore to a different platform—in this sense it’s more useful than mksysb and savevg. You can even run this tool using SMIT. It also allows you to choose between varying types of backups including full system (installation image), volume group, filesystem, file or directory, and raw logical volumes. It can also backup and restore non-rootvg data.SBAdmin from Storix is a turnkey solution which lets you rebuild your entire AIX system from the ground up, including LVM. It can individually back up and restore files, directories, filesystems, raw partitions, volume groups, raw logical volumes or the entire system in case of a disaster. Backups can be archived to local or remote tape or disk on any AIX or Linux system. It also has full support for AIX 6.1. SBAdmin records your system and storage configuration with each system backup, allowing you to restore your data to different hardware.
Back Up Your Data
I’ll reiterate that while there are some strong third-party tools available to you, don’t be afraid of the standard AIX toolset to archive your data. If the complexity of your environment requires you to have more options available to you in a more simplistic manner, look into third-party tools, which in many cases function as more of a turn-key backup solution that using standard AIX commands. Whatever you decide to use, make sure you perform daily backups of your critical data. While backing up your data can be tedious, there’s no larger responsibly you have than to back up your data.Thursday, July 12, 2018
Saving to and restoring from a tape device
Use these procedures to save and restore Linux files between a Linux logical partition
that uses IBM® i resources
and a shared tape drive.
Ensure that your Linux data is in the file
server.
Linux typically
treats tape as a character device that it can quickly read
from or write to in long streams of data, but cannot quickly access
to find specific data. By contrast, Linux treats a disk or
CD as a block device that it can read from or write to quickly
at any point on the device, making it suitable for the mount command.
Complete the following steps to save and restore Linux files between a logical
partition that uses IBM i resources
and a shared tape drive:
Using alt_disk_copy
Cloning rootvg
David Tansley
- A failed ML upgrade.
- It's getting to the end of the day.
- You cannot fix it.
- It's too late to get it resolved by third-party support.
- You need to back out.
The alt_disk utilities consist of the following commands:
alt_disk_copyperforms disk cloning.alt_rootvg_opperforms maintenance operations on the clone rootvg.alt_disk_mysysbperforms a mksysb copy.
The filesets required for the alt commands are:
1
2
3
| bos.alt_disk_install.boot_imagesbos.alt_disk_install.rte bos.msg.en_US.alt_disk_install.rte |
Overview information
Because the alt_disk_copy command takes a copy of the current running rootvg to another disk, be sure to have all the file systems mounted that you want cloned across. alt_disk_copy only copies the currently mounted file systems in rootvg. There is no need to stop processes to execute alt_disk_copy; however, this process can take some time, so it is best to do it at lunchtime or in the evening (remember it is taking a running copy). Once the copy has completed, you will be presented with two rootvg volume groups:
1
2
| rootvgaltinst_rootvg |
altinst_rootvg is the cloned non-active/varied off
rootvg. The cloned rootvg has all its logical volumes prefixed with the name 'alt'.
The boot list is also changed to boot off altinst_rootvg. AIX likes to do things like
this; it assumes you will want to boot off the cloned and not the real rootvg. If the
system is now rebooted and when the system comes back up, the original rootvg will become:
1
| old_rootvg |
1
| rootvg |
1
| rootvg |
1
| altinst_rootvg |
With a successful completion of an upgrade, the disk containing the cloned rootvg can then be destroyed using the alt_rootvg_op and mirrored back in. If the upgrade event has gone disastrously, there is no real problem--simply take a snapshot for third-party support, then boot off the good rootvg. For users to log in, it is business as normal.
When you get a response back from support on the fix, during off-line hours, simply reboot off the cloned rootvg and fix the issue. There is no need to go through the time-consuming tasks of re-applying the upgrade because you already have it on the cloned rootvg. Get the upgrade tested, and if it is all OK, destroy the cloned rootvg and mirror back in.
With the cloned rootvg, you can mount the file systems by waking up the disk using alt_rootvg_op. Doing whatever works is required on the cloned file systems, and one would assume here to fix a patch of link, or gather information for third-party support, then put the disk back to sleep, which will also unmount the file systems.
Excluding directories when cloning
When cloning, you can exclude certain directories by creating the file:/etc/exclude.rootvg.
The entries should start with the ^ /.
characters. The '^' means to search for the string at the beginning of
the line and the './' means relative to the current directory. You are
advised to do this so alt_disk_copy does not misinterpret the command,
as it uses grep to search for the string. So, make sure you provide the
full pathname, prefixed with '^.' , for example, to exclude the
following directories:
1
2
| /home/reps/opt/installs |
1
2
| ^./home/reps^./opt/installs |
Let's get cloned!
Let's now go through a typical clone. Assume you have a software two-disk (hdisk0 and hdisk1) mirror of rootvg, and further assume that you are going to do a ML (or application upgrade, assuming it is installed in rootvg) upgrade on this system. I will demonstrate one way this can be done to clone the disk and after a successful upgrade will bring the disk back into rootvg and re-mirror. I will also demonstrate the actions you can take if the upgrade fails.Pre-checks
Before unmirroring the rootvg, first take some time to ensure you are correctly mirrored and have no stale LV's, because if you do, the unmirrorvg will fail. Of course, you could always do a migratepv to move the missing LV's across if the unmirrorvg fails. A simple method to check that you are mirroring is to issue the command:
1
| lsvg -l rootvg |
Another method to check to see if you are mirroring is to use:
lspv -l <hdiskx>
and compare the output to make sure you have entries for each LV on both disks.Next, issue the bosboot command. I personally always do this prior to either rebooting or disk operations involving rootvg; it is a good habit to have:
1
2
| # bosboot -abosboot: Boot image is 35803 512 byte blocks. |
1
2
3
| # lspvhdisk0 0041a97b0622ef7f rootvg activehdisk1 00452f0b2b1ec84c rootvg active |
1
2
3
4
5
6
7
8
9
10
| # unmirrorvg rootvg hdisk10516-1246 rmlvcopy: If hd5 is the boot logical volume, please run 'chpv -c <diskname>' as root user to clear the boot record and avoid a potential boot off an old boot image that may reside on the disk from which this logical volume is moved/removed.0516-1804 chvg: The quorum change takes effect immediately.0516-1144 unmirrorvg: rootvg successfully unmirrored, user should perform bosboot of system to reinitialize boot records. Then, user must modify bootlist to just include: hdisk0. |
1
| # reducevg rootvg hdisk1 |
1
2
3
| # lspvhdisk0 0041a97b0622ef7f rootvg activehdisk1 00452f0b2b1ec84c None |
Running alt_disk_copy
Now you are ready to issue the alt_disk_copy. Simply supply hdisk1 as a parameter to the command. The basic format is:
1
| alt_disk_copy -d <hdisk to clone rootvg> |
1
| alt_disk_copy -e /etc/exclude.rootvg -d <hdisk to clone rootvg> |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| # alt_disk_copy -d hdisk1Calling mkszfile to create new /image.data file.Checking disk sizes.Creating cloned rootvg volume group and associated logical volumes.Creating logical volume alt_hd5Creating logical volume alt_hd6Creating logical volume alt_hd8Creating logical volume alt_hd4Creating logical volume alt_hd2Creating logical volume alt_hd9varCreating logical volume alt_hd3Creating logical volume alt_hd1Creating logical volume alt_hd10optCreating /alt_inst/ file system.Creating /alt_inst/home file system.Creating /alt_inst/opt file system.Creating /alt_inst/tmp file system.…......…......for backup and restore into the alternate file system...Backing-up the rootvg files and restoring them to thealternate file system...Modifying ODM on cloned disk.Building boot image on cloned disk.forced unmount of /alt_inst/varforced unmount of /alt_inst/usrforced unmount of /alt_inst/tmpforced unmount of /alt_inst/optforced unmount of /alt_inst/home…..…..Changing logical volume names in volume group descriptor area.Fixing LV control blocks...Fixing file system superblocks...Bootlist is set to the boot disk: hdisk1 |
1
2
3
| # lspvhdisk0 0041a97b0622ef7f rootvg activehdisk1 00452f0b2b1ec84c altinst_rootvg |
1
2
| # bootlist -m normal -ohdisk1 blv=hd5 |
1
| # bootlist -m normal hdisk0 |
1
2
| # bootlist -m normal -ohdisk0 blv=hd5 |
1
2
3
| # lspvhdisk0 0041a97b0622ef7f rootvg activehdisk1 00452f0b2b1ec84c altinst_rootvg |
1
2
3
4
| alt_rootvg_op -X < cloned rootvg to destroy># alt_rootvg_op -X altinst_rootvgBootlist is set to the boot disk: hdisk0 |
1
2
3
4
5
6
| # extendvg -f rootvg hdisk1# mirrorvg rootvg hdisk10516-1804 chvg: The quorum change takes effect immediately.0516-1126 mirrorvg: rootvg successfully mirrored, user should perform bosboot of system to initialize boot records. Then, user must modify bootlist to include: hdisk0 hdisk1. |
1
2
3
4
5
6
7
8
| # bootlist -m normal -o hdisk0 hdisk1hdisk0 blv=hd5hdisk1# bosboot -abosboot: Boot image is 35803 512 byte blocks.# bootlist -m normal -ohdisk0 blv=hd5hdisk1 blv=hd5 |
Recovery positions, please
Let's now assume you have just installed the ML upgrade and rebooted, and issues have been found with the operational running of AIX. Remember, you currently have the disks in the following state:
1
2
3
| # lspvhdisk0 0041a97b0622ef7f rootvg activehdisk1 00452f0b2b1ec84c altinst_rootvg |
rootvg: with post-upgrade issues.altinst_rootvg: with good copy pre-upgrade.
Take me back
To get back to the pre-upgrade, simply change the bootlist to boot off the (altinst_rootvg) hdisk1, then reboot. It's that simple:
1
2
3
4
5
| # bootlist -m normal -o hdisk1hdisk1 blv=hd5# bootlist -m normal -ohdisk1 blv=hd5# shutdown -Fr |
1
2
3
| # lspvhdisk0 0041a97b0622ef7f old_rootvghdisk1 00452f0b2b1ec84c rootvg active |
1
2
3
4
| # bosboot -abosboot: Boot image is 35803 512 byte blocks.# bootlist -m normal -ohdisk1 blv=hd5 |
Post upgrade fixing
At a convenient time schedule that is agreed-upon with the end users, and with information provided by third-party support, you can then boot off the ML failed upgraded disk (hdisk0) and apply a fix that might solve the issue, so change the bootlist to boot off (old_rootvg) hdisk0 and reboot:
1
2
| # bootlist -m normal -o hdisk0# shutdown -Fr |
1
2
3
| # lspvhdisk0 0041a97b0622ef7f rootvg activehdisk1 00452f0b2b1ec84c altinst_rootvg |
After the system has been tested and signed off bring in hdisk1, use the commands described earlier:
#
1
| alt_rootvg_op -X altinst_rootvg |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| Bootlist is set to the boot disk: hdisk0# extendvg -f rootvg hdisk1# mirrorvg rootvg hdisk1bootlist -m normal -o hdisk0 hdisk1hdisk0 blv=hd5hdisk1# bosboot -abosboot: Boot image is 35803 512 byte blocks.# bootlist -m normal -ohdisk0 blv=hd5hdisk1 blv=hd5# lspvhdisk0 0041a97b0622ef7f rootvg activehdisk1 00452f0b2b1ec84c rootvg active |
Waking the disk up
Within a cloned rootvg environment, you can wake up the cloned rootvg to be active. All cloned file systems from the cloned rootvg will be mounted. It is quite useful because you have a good running system, but at the same time mount the file systems from the cloned rootvg for further investigation or file modification. When a cloned rootvg is woken up, it is renamed to:
1
| altinst_rootvg |
Assume you have the disks in the following state:
1
2
3
| # lspvhdisk0 0041a97b0622ef7f old_rootvghdisk1 00452f0b2b1ec84c rootvg active |
1
| alt_rootvg_op -W -d < hdisk> |
1
2
| # alt_rootvg_op -W -d hdisk0Waking up old_rootvg volume group ... |
1
2
3
| # lspvhdisk0 0041a97b0622ef7f altinst_rootvg activehdisk1 00452f0b2b1ec84c rootvg active |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| # df -mFilesystem MB blocks Free %Used Iused %Iused Mounted on/dev/hd4 128.00 102.31 21% 2659 11% //dev/hd2 1968.00 111.64 95% 40407 58% /usr/dev/hd9var 112.00 77.82 31% 485 3% /var/dev/hd3 96.00 69.88 28% 330 3% /tmp/dev/hd1 208.00 118.27 44% 1987 7% /home/proc - - - - - /proc/dev/hd10opt 1712.00 1445.83 16% 6984 3% /opt/dev/alt_hd4 128.00 102.16 21% 2645 11% /alt_inst/dev/alt_hd1 208.00 33.64 84% 1987 21% /alt_inst/home/dev/alt_hd10opt 1712.00 1445.77 16% 6984 3% /alt_inst/opt/dev/alt_hd3 96.00 72.38 25% 335 2% /alt_inst/tmp/dev/alt_hd2 1968.00 100.32 95% 40407 59% /alt_inst/usr/dev/alt_hd9var 112.00 77.53 31% 477 3% /alt_inst/var |
1
| alt_rootvg_op -S -t <hdisk> |
1
2
3
4
5
6
7
8
9
10
11
12
| # alt_rootvg_op -S -t hdisk0Putting volume group altinst_rootvg to sleep ...Building boot image on cloned disk.forced unmount of /alt_inst/varforced unmount of /alt_inst/usrforced unmount of /alt_inst/tmpforced unmount of /alt_inst/optforced unmount of /alt_inst/homeforced unmount of /alt_instforced unmount of /alt_instFixing LV control blocks...Fixing file system superblocks... |
1
2
3
| # lspvhdisk0 0041a97b0622ef7f altinst_rootvghdisk1 00452f0b2b1ec84c rootvg active |
altinst_rootvg.It is sometimes good to go back to the original state of the disks to save confusion, especially if you have more than one cloned disk. So rename altinst_rootvg back to old_rootvg. The basic format is:
1
| alt_rootvg_op -v <new cloned rootvg name> -d <hdisk> |
1
2
3
4
| # alt_rootvg_op -v old_rootvg -d hdisk0# lspvhdisk0 0041a97b0622ef7f old_rootvghdisk1 00452f0b2b1ec84c rootvg active |
1
2
3
4
| # alt_rootvg_op -v bad_rootvg -d hdisk0bash-2.05a# lspvhdisk0 0041a97b0622ef7f bad_rootvghdisk1 00452f0b2b1ec84c rootvg active |
From this point, the system is now operational or not, depending on the success of the fix, using the commands described earlier.
If the fix worked on (old_rootvg) hdisk0, then run with the new ML version.
Confirm that the disk will boot off hdisk0:
1
| # bootlist -m normal -o hdisk0 |
1
| # shutdown -Fr |
1
| # alt_rootvg_op -X altinst_rootvg |
1
2
3
4
| # extendvg -f rootvg hdisk1# mirrorvg rootvg hdisk1# bosboot -a# bootlist -m normal -o hdisk0 hdisk1 |
Confirm that the disk will boot off hdisk1:
1
| # bootlist -m normal -o hdisk1 |
1
| # alt_rootvg_op -X old_rootvg |
1
2
3
4
| # extendvg -f rootvg hdisk0# mirrorvg rootvg hdisk0# bosboot -a# bootlist -m normal -o hdisk0 hdisk1 |
Conclusion
This article showed that using the alt command is a quick way to recover rootvg if events go wrong on an AIX upgrade and how to mount the cloned rootvg filesystem on a running system. The alt command can also provide a path to a migration of a rootvg disk to another hardware. It is also very useful in having two different versions of AIX installed for testing migrating procedures.
Subscribe to:
Posts (Atom)