QUESTION:
I had a customer that recently lost a hard drive. Rather than doing a
mksysb backup of his system, he went in and backed up from /. Upon
getting his system back up, using the PID tapes, he went in and
restored the /. Obviously, losing all of his configuration files, any-
way he can recover this? This includes SNA profiles, printer and
terminal definitions, etc...
---------- ---------- ---------- --------- ---------- ----------
A: I have left a phone message for you to contact me. I want to find
out the results that you have already seen, and the exact tar
command you used to back up the system before I test this. If your
system is close to inactive when you restored the tar, you may have
tar'ed your Cu* files (which contain the customizations you need)
back to your system and thus it may be working already.
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
Thanks for your call. We were not able to try your suggestions,
because the customer decided to scratch load the machine, we had to
get it back up right away, and trying to do testing was unacceptable
to the customer. We scratch loaded created all the logical volumes,
and then yanked his files from the tape a loaded into the appropriate
logical volumes. The customized devices, were all rebuilt from
scratch including all of the SNA profiles, luckily, he had documented
his system real well. The system is back up and operational, however,
we are still interested if we can recover customized device information
(Cu*) with that kind of backup.
---------- ---------- ---------- --------- ---------- ----------
A: Yes, restoring a tar backup of the entire system over an active system
will keep the same configurations as original system. The following
answer explains the steps I used to test this and the results of that
test. Please realize that this will work best on a system with
minimal activity.
1. On an active system, record the size of all the filesystems.
2. Unmount all NFS filesystems and run the exportsna command for good
measure.
3. Do a complete system backup by cd'ing to / and using the command:
tar -cvf /dev/rmt0 /
4. I then remade the system using a mksysb of another machine at the
same level of operating system. Please realize that this will
not work if I am trying to do this over different levels of AIX.
5. Once I decided to overlay the system with the tar backup, I
touched the /etc/nologin file to prevent more users from logging
in, and forced all other users from the system. I could have
gone into single user mode (and probably should have) to have the
same effect.
6. Using SMIT, I the size of all the filesystems so that the tar
would have enough room to restore into them. I used the sizes
recorded in step one plus an allotment for things that would not
be overwritten. I purposely had installed a mksysb from a smaller
and less full system so that I would be able to increase my sizes
and overwrite most of the data, thus not losing so much room.
7. I also created and mounted any filesystems that were on the
original system and were not created by the re-install of the
mksysb.
8. I then cd'ed to / and restored the tar using the command
tar -xvf /dev/rmt0
I would like to note that I had to restore more than once because
I had not allocated enough room in some of the filesystems. Once
when part of the / filesystem was copied over, I was unable to
extend the filesystem until after I ran the rvgrecover script to
correct the ODM.
9. Once the entire restore from the tar completed, I ran the
rvgrecover script again to correct the ODM, then I rebooted. The
system came up fine.
I noticed that all the printer definitions and the SNA profiles were
exactly the same as the original system. The hostname and tcpip
definitions also reflected the original system. There were some files
that did not get over-written because the were in use, but because I
was at the same level of operating system, the system files that
didn't get overwritten were exactly the same. All problems that I
found on the restored system were the same as the ones on the original
system.
I will now include the rvgrecover script (as distributed by Software
Services fax line, 1-800-IBM-4FAX) for added aid.
07/28/93
RECOVERING VOLUME GROUPS IN AIX 3.1 OR 3.2
SPECIAL NOTICES
Information in this document is correct to the best of our
knowledge at the time of this writing. Please send feedback
by fax to "AIXServ Information" at (512) 823-5972.
Please use this information with care. IBM will not be
responsible for damages of any kind resulting from its use.
The use of this information is the sole responsibility of
the customer and depends on the customer's ability to eval-
uate and integrate this information into the customer's
operational environment.
ABOUT THIS DOCUMENT
Run the script in this document when the ODM (Object Data
Manager) entries for the root volume group are corrupted.
The script may be modified for volume groups other than
rootvg. (See "About the Script" in this document.)
PROBLEM DETERMINATION
When the ODM entries for a volume group are corrupted, you
may notice that volume-group and logical-volume commands
fail, that you cannot change the size of file systems, or
that the system cannot find volume groups or device IDs.
Run "lslv -l" to see if a corrupted ODM description is the
problem -- if it is, information will probably be missing
from the "lslv" output, or there may be '?'s in the output.
BEFORE USING THE SCRIPT
Before using the following script, save the current version
of your /etc/objrepos/Cu* files, in case you want to go back
to that version at some time. (In the following commands,
replace "mmmdd" with the month and day, such as "jan01".)
cd /etc/objrepos
cp CuAt cuat.mmdd
cp CuDep cudep.mmmdd
cp CuDv cudv.mmmdd
cp CuDvDr cudvdr.mmmdd
ABOUT THE SCRIPT
1. This script contains only a few provisions for handling
error conditions because it is designed to minimize
typing mistakes.
2. The PV (physical volume) and VG (volume group) variables
on the first two lines of the script are defaulted for
the root volume group (rootvg). The PV is set to
/dev/ipldevice, which is a synonym for one of the phys-
ical volumes that is a member of the rootvg volume
group.
If you wish to run this script for a volume group other
than the rootvg, you must change the VG variable to
match the volume group you wish to fix, and change the
PV variable to match any one of the physical volumes
(/dev/hdisk#) that is a member of that volume group. To
determine to which VG a PV belongs, enter the command:
(/dev/hdisk#) that is a member of that volume group. To
determine to which VG a PV belongs, enter the command:
lsvg `lqueryvg -vp hdisk# ` | grep GROUP
3. It is not necessary to reboot after running this script.
THE SCRIPT
Run the following script while in Normal mode and logged in
as root. On line 14 of the script, "." should be a left
bracket and "." should be a right bracket.
----------------------------------------------------------------------
PV=/dev/ipldevice
VG=rootvg
lqueryvg -Lp $PV | awk '{ print $2 }' | while read LVname; do
odmdelete -q "name = $LVname" -o CuAt
odmdelete -q "name = $LVname" -o CuDv
odmdelete -q "value3 = $LVname" -o CuDvDr
done
odmdelete -q "name = $VG" -o CuAt
odmdelete -q "parent = $VG" -o CuDv
odmdelete -q "name = $VG" -o CuDv
odmdelete -q "name = $VG" -o CuDep
odmdelete -q "dependency = $VG" -o CuDep
if . "$VG" = rootvg .
then
odmdelete -q "value1 = 10" -o CuDvDr
else
odmdelete -q "value1 = $VG" -o CuDvDr
fi
odmdelete -q "value3 = $VG" -o CuDvDr
importvg -y $VG $PV # ignore lvaryoffvg errors
varyonvg $VG
----------------------------------------------------------------------
---------- ---------- ---------- --------- ---------- ----------
This item was created from library item Q656263 CQJVX
Additional search words:
APR94 BACKOUT BACKUP CFG CQJVX DRIVE DRIVER HARD HIS IX LOST
MANAGEMENT MKSYSB NON OP OZIBM OZNEW RECENTLY RECOVER RECOVERABLE
RECOVERY RESTART RISCMGMT RISCSYSTEM SOFTWARE SYS SYSTEM TRYING
WWQA: ITEM: RTA000040895 ITEM: RTA000040895
Dated: 03/1996 Category: RISCMGMT
This HTML file was generated 99/06/24~12:43:16
Comments or suggestions?
Contact us