mksysb restores

mksysb restores

Post by Harry Spellme » Wed, 06 Feb 2002 06:12:28



Restoring a 4.3.2 system to a new system.  I get the mksysb to run and do
the restore, but every filesystem comes up with a length of (0).  All the
filesystems on this box are on either SSA drives, or the ESS.  How do I
recover the filesystem sizes?

Harry

 
 
 

mksysb restores

Post by chuc » Wed, 06 Feb 2002 16:14:44


mksysb only backs/restores rootvg

> Restoring a 4.3.2 system to a new system.  I get the mksysb to run and do
> the restore, but every filesystem comes up with a length of (0).  All the
> filesystems on this box are on either SSA drives, or the ESS.  How do I
> recover the filesystem sizes?

> Harry


 
 
 

mksysb restores

Post by Clive Sparke » Wed, 06 Feb 2002 19:54:29



> Restoring a 4.3.2 system to a new system.  I get the mksysb to run and
> do
> the restore, but every filesystem comes up with a length of (0).  All
> the
> filesystems on this box are on either SSA drives, or the ESS.  How do I
> recover the filesystem sizes?

> Harry

mksysb only handles rootvg.  If you still have access to the original
SSA/ESS disks that other VGs were stored on you will need to exportvg
those VGs and then importvg them from the disks/LUNs.

Note, if this action is because the node crashed then the disks/LUNs may
still have locks on them which would prevent access.  To break the locks
on SSA you need to power off the disks, remove & replace them in the
drawer and power them on again.  For ESS LUNs I think you need to
perform a state save on the ESS to break the locks.

--
Regards,
Clive

 
 
 

mksysb restores

Post by Harry Spellme » Thu, 07 Feb 2002 02:26:33


Ok, will tivoli handle rebuilding the file systems in this case?

Harry



> > Restoring a 4.3.2 system to a new system.  I get the mksysb to run and
> > do
> > the restore, but every filesystem comes up with a length of (0).  All
> > the
> > filesystems on this box are on either SSA drives, or the ESS.  How do I
> > recover the filesystem sizes?

> > Harry

> mksysb only handles rootvg.  If you still have access to the original
> SSA/ESS disks that other VGs were stored on you will need to exportvg
> those VGs and then importvg them from the disks/LUNs.

> Note, if this action is because the node crashed then the disks/LUNs may
> still have locks on them which would prevent access.  To break the locks
> on SSA you need to power off the disks, remove & replace them in the
> drawer and power them on again.  For ESS LUNs I think you need to
> perform a state save on the ESS to break the locks.

> --
> Regards,
> Clive

 
 
 

mksysb restores

Post by Clive Sparke » Sat, 09 Feb 2002 00:30:26



> Ok, will tivoli handle rebuilding the file systems in this case?

> Harry

< snippage due to top-posting >

No, TSM is for data, not the FS/LVM structure.

The only way to get back the FS/LVM structure is via importvg.  
Caveat, if no exportvg has been run then the ODM should still contain
the names of the LVs entries for the other VGs which you can recover
with:
odmget -q parent=$VG_NAME CuDv
and then you could get the details of the LV with:
odmget -q name=$LV_NAME CuAt

With this data you could then run exportvg to clean out the ODM and
/etc/filesystems and then manually rebuild your VGs.  Note, the size of
the LVs in this output is in multiples of PP (physical partitions) and
if you don't know what that was set at you'll just have to take a 'best
guess' based on the disk/LUN size, try 16M for 9G disks and 32M for
bigger.

For future reference:
When using a 3rd party product to handle data backups my preferred
method:
1)  ensure that the backup/archive client is part of rootvg
2)  create archives of other VGs LVM/FS structure using savevg with an
exclude file of "/" to backup the LVM/FS structure to a file stored in
rootvg (I store them in /var/savevg).

This gives you a layered method of handling both data & disaster
recovery, ie, when things go totally wrong you rebuild the system from
the mksysb, rebuild the other VGs from the savevg archives in
/var/savevg then restore the data using the backup/archive client.  

--
Regards,
Clive

 
 
 

mksysb restores

Post by Anthony Johnso » Sat, 09 Feb 2002 05:51:17


Consider Storix, which does a System backup and you can specify which volume
group data you want included (and also if you want raw logical volume data).
When you reinstall from the backup, you can recreate all VGs, even if the
data is not included on the backup, or you can recreate VGs and choose not
to restore the VG data even if it was included. Lots of other features that
I think would be helpful.

The FREE version will do all this if you are backing up to a local tape
drive. Go to http://www.storix.com for a free download.


> Restoring a 4.3.2 system to a new system.  I get the mksysb to run and do
> the restore, but every filesystem comes up with a length of (0).  All the
> filesystems on this box are on either SSA drives, or the ESS.  How do I
> recover the filesystem sizes?

> Harry

 
 
 

1. mksysb restore fails

If anyone has had any experience of the following problem ( or knows
the answer anyway ) I'd be very grateful for their expertise.

I'm trying to clone one H80 from another ( slightly different config -
the source m/c is multi-processor with rootvg mirrored on 2 x 9gb
drives, and the target is uni-processor with 2 x 18gb. )

On the source, I've modified bosinst.data with 'RECOVER_DEVICES = no'
. The source box is in use 24 x 7, so I've had to mksysb in-flight.

When I come to do the recover, I boot from the install cd, and then
choose the option to install from a backup, without changing any
default settings ( both disks have been pre-selected for installing ).

As the install progresses, it fails to unpack a series of log files:

Unpack: file out of phase
Unpack: internal unpacking error: decode failure
Restore: error during unpack of ....
Unpack: bad read of pipe
:Error 0
BOS Install: Restore of Base Operating System from rmt0 failed.

At this stage I felt not too concerned, as these were unneeded log
files, and the install gave me the option to continue, which I did.
Then after that I received:

BOS Install: Could not populate devices directory

( Option to continue, so I did.... )

BOS Install: Could not copy volume group information to the disk

( Option to continue, so I did.... )

Copying Cu* to disk

After this, the install just suspended.

If anyone has any ideas on this, I'd be very interested.

TIA
Mark

2. Question on DNS requests

3. mksysb restore

4. Which of these processes keeps spinning up my HDD?

5. mksysb restore question

6. cron troubles

7. 43P mksysb restore

8. Small awk question

9. After a Mksysb restore, rpc.lockd will not stay up.

10. mksysb restore with map files fails due to hdisk renumbering

11. Mksysb restore screen "Maps" setting question

12. How to do network mksysb restore??

13. mksysb restore "not enough disk space selected"