mksysb restore with map files fails due to hdisk renumbering

mksysb restore with map files fails due to hdisk renumbering

Post by Michael Ben » Fri, 20 Nov 1998 04:00:00



Here's an interesting one for you all to have a go at!

I have (or rather had) an IBM F50 with AIX mirrored across two 4.5GB disks,
which were known as hdisk0 and hdisk2.  I have a 7135 RAID array attached
via a F/W differential SCSI controller and this was configured as a single
RAID5 disk and appeared as hdisk1.

Being a good boy I painstakingly backed up my system with smitty mksysb and
selected to generate MAP files, and to generate a new image.data file.

Before going live with this system I wished to test a restore of the mksysb
tape, so I booted from it and attempted to reinstall.  As soon as the
installation started it objected, saying that the disks were not the same as
they had been when the backup was made.

I tried using one of the 4.5GB disks (shown as being without a map file),
the other (with a map file), and both drives - without success.  The install
failed complaining either that their was insufficient space, the LV policy
could not be kept strict enough,  or indicating that there was a reference
to a non-existant disk in the image.data file.

Looking at this file in the 'limited function maintenance shell' (where did
'ls' go?) I could see that image.data referred to hdisk0 and hdisk2 but my
newly rebooted system had found the disks as hdisk0 and hdisk1. I presume
this is where it is getting confused.

Does anybody know how I can cause the system to recognise the drives with
their original hdisk numbers, or alternatively how I can modify the
image.data when I do not have access to another system with a DLT drive like
mine?

All help would be gratefully accepted.

Michael Benn
Technical Director
Datawright Computer Services Limited

 
 
 

mksysb restore with map files fails due to hdisk renumbering

Post by Ketil Olav Heggtvei » Fri, 20 Nov 1998 04:00:00



> Here's an interesting one for you all to have a go at!

> I have (or rather had) an IBM F50 with AIX mirrored across two 4.5GB disks,
> which were known as hdisk0 and hdisk2.  I have a 7135 RAID array attached
> via a F/W differential SCSI controller and this was configured as a single
> RAID5 disk and appeared as hdisk1.

> Being a good boy I painstakingly backed up my system with smitty mksysb and
> selected to generate MAP files, and to generate a new image.data file.

> Before going live with this system I wished to test a restore of the mksysb
> tape, so I booted from it and attempted to reinstall.  As soon as the
> installation started it objected, saying that the disks were not the same as
> they had been when the backup was made.

> I tried using one of the 4.5GB disks (shown as being without a map file),
> the other (with a map file), and both drives - without success.  The install
> failed complaining either that their was insufficient space, the LV policy
> could not be kept strict enough,  or indicating that there was a reference
> to a non-existant disk in the image.data file.

> Looking at this file in the 'limited function maintenance shell' (where did
> 'ls' go?) I could see that image.data referred to hdisk0 and hdisk2 but my
> newly rebooted system had found the disks as hdisk0 and hdisk1. I presume
> this is where it is getting confused.

> Does anybody know how I can cause the system to recognise the drives with
> their original hdisk numbers, or alternatively how I can modify the
> image.data when I do not have access to another system with a DLT drive like
> mine?

> All help would be gratefully accepted.

> Michael Benn
> Technical Director
> Datawright Computer Services Limited


Hi,

I am not sure how to solve the problem you have now, but  here is how I worked
around backup/restore of rootvg which is mirroed. First I did an unmirrorvg,
then an image.data with one disk is created, then when I do a backup I don't
generate a new image.data but use the one witch is not mirroed.
the advantage of this is that IF your system crach and you needs to take a
restore and only have ONE disk, your restore will still work.
If you have a backup of a mirror rootvg with several disks, then you need to
restore to the same amount disk as the backup was created with.

try unmirror the rootvg,
do a mksysb -e -v -X /dev/rmt0  #I think that's all the option you need, see
man mksysb

NB! when you do a restore, make sure you mirror rootvg if all your disks are
ok.

--
:-) Ketil

_/_/_/_/_/_/_/_/_/_/_/_/_/Signature_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ Ketil Heggtveit
_/ DnB ASA ,P&U IT-Drift        Adr:Sandslimarka 260
_/ Basis Steotte                5049 Sandsli
_/ Telf:(095)-55 22 34 71       Telefax:(095)-55 22 33 00



 
 
 

mksysb restore with map files fails due to hdisk renumbering

Post by Alan Mac » Sat, 21 Nov 1998 04:00:00


The document
        How to Restore a mksysb without Preserving Mirrors
on the IBM support page
        http://service.software.ibm.com/rs6k/techdocs/90605188214722.html#1
will talk you through "doctoring" your image.data file, copying it to diskette
and using this "doctored" version during a mksysb restore.

Good luck.
Let us all know if it does the trick


> Here's an interesting one for you all to have a go at!

> I have (or rather had) an IBM F50 with AIX mirrored across two 4.5GB disks,
> which were known as hdisk0 and hdisk2.  I have a 7135 RAID array attached
> via a F/W differential SCSI controller and this was configured as a single
> RAID5 disk and appeared as hdisk1.

> Being a good boy I painstakingly backed up my system with smitty mksysb and
> selected to generate MAP files, and to generate a new image.data file.

> Before going live with this system I wished to test a restore of the mksysb
> tape, so I booted from it and attempted to reinstall.  As soon as the
> installation started it objected, saying that the disks were not the same as
> they had been when the backup was made.

> I tried using one of the 4.5GB disks (shown as being without a map file),
> the other (with a map file), and both drives - without success.  The install
> failed complaining either that their was insufficient space, the LV policy
> could not be kept strict enough,  or indicating that there was a reference
> to a non-existant disk in the image.data file.

> Looking at this file in the 'limited function maintenance shell' (where did
> 'ls' go?) I could see that image.data referred to hdisk0 and hdisk2 but my
> newly rebooted system had found the disks as hdisk0 and hdisk1. I presume
> this is where it is getting confused.

> Does anybody know how I can cause the system to recognise the drives with
> their original hdisk numbers, or alternatively how I can modify the
> image.data when I do not have access to another system with a DLT drive like
> mine?

> All help would be gratefully accepted.

> Michael Benn
> Technical Director
> Datawright Computer Services Limited


 
 
 

1. Mksysb restore screen "Maps" setting question

When called with the -m and -i flag the mksysb script will call
mkszfile to generate map files (/tmp/vgdata/rootvg/*.map) and
the /image.data file.  When restoring the mksysb image the RS/6000
looks to the tape image to determine whether maps are available or not
and will set the Maps setting on the mksysb restore screen (in service
mode)to yes or no respectively.  This setting can not be edited by the
user at that time.

My question is: What file on the tape image is the system looking at to
make that determination?

I thought perhaps it was the /image.data files "EXACT_FIT= yes" entry,
but testing has shown that is not it.  The map files where placed on
the test mksysb image (saw them in the front of the file list when
mksysb ran.

The catch is:
I'm running mkszfile with the -m flag to create maps and a image.data
that points to the maps.
I'm then editing the map files to reallocate the lv's.
I'm then running the mksysb command without the -i and -m flags.
The maps are still getting placed on the tape as the files already
exist.

When booting off the mksysb in service mode the "Maps" setting remains
set at "No", meaning mapfiles are not available.

Is there something in the mkszfile or mksysb scripts that somehow sets
the mksysb tape image such that it indicates maps are not available?

I'm considering commenting out mkszfile's function call that creates
the map for each individual lv to see if the mksysb flags are required
to allow the restore screen Maps setting to flip to "Yes".

TIA

Sent via Deja.com http://www.deja.com/
Before you buy.

2. struct align on 8 byte boundary for gcc

3. Mksysb restore "Maps" option setting question

4. Finding where a symbolic link points to

5. restore one file from mksysb file?

6. Problem with PPP on kernel 1.3.54

7. mksysb restore fails

8. RAID CONTROLLER RECOMENDATION????

9. mksysb restore fail for license server

10. Restoring mksysb insists on restoring mirrors.

11. Some device special files missing after restoring from mksysb

12. Restore single file/directory from mksysb tape (aix 4.2.1)?

13. mksysb to disk file/restore