Mksysb restoration

Hi,

I am an newbie to AIX.
Recently, I being assigned to do an mksysb restoration at our DR site.
It always encounter "Out of Space" during restoration, this is even when I restored to 4x146GB HDD.
Even though, on production, it only need 2x146GB HDD for the rootvg.
What is the problem, I also redo the mksysb backup and ensure that it is successfully completed without any errors ?

Can someone please kindly help ?

Thanks
AIXBlueCat

When you issue the mksysb command to take the mksysb-image issue the mkszfile first. This command (re-)writes a file named /image.data where the sizes of all PVs, LVs, etc. in the rootvg are stated.

It is possible to edit this file and then use the edited one, this way i.e. taking a mksysb of a mirrored rootvg and restore it without mirroring onto a single disk. Without any other hints i'd start investigating this frst to find out what the culprit is. The /image.data is quite straightforward and although its content is not exactly well-documented you can understand it with some limited guesswork. Reading the man pages for mksysb and mkszfile will sure help too.

I hope this helps.

bakunin

there are 2 Volume of DDS4 tape for the mksysb backup
when I restored to 2x146GB HDD, it failed with Out of Space
but when I restored to 4x146GB HDD, it will prompt for Volume 2 but still encounter an error message - Media Surface Error and Out of Space
can some exper please kindly help.
appreciate it very much

I have already tried to help you, maybe i haven't been clear enough:

take the mksysb image again! Issue the mkszfile command first and examine the newly written /image.data file before you proceed to continue with the mksysb command itself. If you cannot figure out any specific problems post it here (it is several kb in size, you might want to post it as an attachment).

Especially this part is interesting (this is from one of my systems, yours will look similar but different):

source_disk_data:
        PVID= 00f81dc70b958716
        PHYSICAL_LOCATION= U9179.MHD.211AB7V-V5-C2-T1-L8100000000000000
        CONNECTION= vscsi0//810000000000
        LOCATION=
        SIZE_MB= 40960
        HDISKNAME= hdisk0

This is also to be considered:

logical_volume_policy:
        SHRINK= no
        EXACT_FIT= no

Another possibility might be that you have (a) sparse file(s) in your rootvg. These tend to be "expanded" to their virtual size for real when being restored.

I hope this helps.

bakunin

Another thing I could suggest would be that LV mirrors will need to be respected too. I fell over that when restoring to a server with a HUGE single disk protected externally. I can't remember if it was local hardware RAID or a SAN.

The problem is that the mirrors have to go on separate PVs (as far as the OS knows) and we just had one. There was an unsupported adjustment that I had to do to the volume group definition file (created by mkszfile) before running mksysb but once it's written you are a bit stuck.

I have seen it done by DR provider professionals where they copy the image into a NIM server and adjust it, but that's just me witnessing it rather that knowing what they did.

Is your DR site and equipment owned by your company or is it rented time from a DR specialist company?

I must say that using tapes for such a large rootvg seems a little odd. Is there not a DVD-RAM drive available?

Kind regards,
Robin

True, but as threads O/P said he has two target disks i thought that should be cared for. In fact, you are right: for the taking of an mksysb image the mirrors should all be edited out in the image.data file before taking it. I do that routinely because it allows for greater flexibility when restoring. One can always set up a mirror afterwards if that is necessary.

I'd say the large rootvg in itself is ridiculous. The rootvg is for holding the OS and everything pertaining to the systems configuration, not for the application data or the videos taken on the last holiday. Even my biggest systems have a rootvg built from a single 40GB LUN and even that is half empty on most systems.

I hope this helps.

bakunin

thank you all for the help.
as I am not allow to do/check anything on the production server.
I do it the hard way, restore thru OS DVD, then restore the filesystems for rootvg thru the NetBackup server which also have a backup of all filesystems in the server.

Well, it might work.

If you are not allowed access to the production server, can you ask for some details about it? The output of lsvg -l rootvg would be really useful. I'm assuming that you haven't acquired a mksysb media illegally, of course.......:rolleyes:

If you have space and servers, what I have seen done is to read in the image to a NIM server that you can then use to provision a new cloned server and you get the chance to resize/move the logical volumes at that point. You would need a NIM server and plenty of disk space and disks to restore to on it & the eventual target.

Robin

"I am not allow to do/check anything on the production server."
what I mean is that i was still new at that time, my senior did the mksysb backup and checked that the backup was good.
my task at that time, was to ensure that the DR testing is successful, for audit purpose, which i was very fortunate that it ended well.
i have taken all the pointers, and make an mksysb.
now waiting for a chance to do the restoration at our DR site and hope that it will go through.

Can you share the output from lsvg -l rootvg so we can point out any risks?

Robin

Good idea. You should include the output of lsvg rootvg (without the -l) too, because LV sizes in the output of lsvg -l is in PPs and only lsvg will tell you the PP size.

I hope this helps.

bakunin

i will have to do another mksysb and exclude /opt/bea92 and /opt/filenet.
these two filesystems are installed and mounted on rootvg, each allocated 20GB, usage is 70%

As already said, that is a bad design, however it depends on the hardware you have available.

What hdisk do you have available on the production side? It would be far better to create replacement filesystems in another volume group and move the data. Is this possible? With increasing minimum sizes of disks, it is becoming more common to have huge amounts of unused space in rootvg and it is important to keep the contents down to the minimum to boot the OS. Anything to do with the application or data storage should really be kept out of rootvg to avoid problems like this.

Kind regards,
Robin

this production server is an legacy.
my seniors taking over from the previous vendor, did not even do any mksysb backup until i join and ask them to do it.
that is where, I encounter so many problems with the restoration.
and the server has not been shutdown before.
i know from reading thru threads here, it is an terrible design, waiting for disaster to happen.
so until, the management gives me approval to change it, i am afraid i also cannot do anything.
once i do another mksysb backup excluding the two filesystems /opt/bea92 and /opt/filenet, i will find a chance to do the restoration at our Disaster Recovery vendor's site.
if the restoration is successful, i will stick to my workable ways to do restoration during Disaster Recovery Testing.
although more work to do and take more times.
thank you everyone for the help and advise.

There is are tools that can help you (no doubt for a fee) but are destructive, so be sure you have your DR procedures nailed down first.

One tool I have used is Storix which will allow you to backup and when you come to restore you can adjust the volume group and filesystem layout.

It would, of course, be safer to restore to a blank server rather than to overwrite the original but it depends what you have available. Your DR vendor may also be able to work through this with you.

Kind regards,
Robin

First off: no problem. I have seen worse, so stay cool. You can handle that.

The first thing you need to explain (to your seniors) is: taking an mksysb is not changing or even doing anything to their precious production server. Getting a working mksysb image in fact enhances runtime security. Here is how to do it correctly:

1) on your production server create a file "/etc/exclude.rootvg" where you put in all the directories you do not want to have in your mksysb-image. Possible contents could be:

^./opt/bea92/
^./opt/filenet/
^./var/tmp/
^./var/log/
^./tmp/

2) Issue the mkszfile command. This generates a file called /image.data in which the layout of the FSes, LVs, disks, etc. is described as it is used by the mksysb -command. You need to edit this file prior to running the mksysb itself to remove LV-copies (mirrors) and the like. If you need help there: just post the file and we can go over it.

3) Only after adapting both these files run the mksysb -command, exactly as follows:

mksysb -e <device>

Note that you do NOT use the -i flag, which would overwrite the /image.data file you edited, voiding your edits.

The resulting mksysb-image should fit onto a tape and you can subsequently install it onto another system. If the resulting restore is not to your liking: finetune the process by excluding more directories, etc.. You can do this over and over again without changing your environment itself in any way.

I hope this helps.

bakunin

still waiting to test the concept.
thank you everyone for the advice.

sorry for asking again,
can we do an mksysb backup with other userid other than root ?
if we do it using other userid, will the mksysb backup be bootable.
cos i do it with an userid, the backup was successful, but when i tried to boot thru it to do an restoration, it was not successful.

Consider this: to create a backup of something you need at least read access to it. A mksysb image is the complete rootvg, which includes the most sensitive information of the system (namely everthing in /etc/security and the like). Ask yourself: will any other user except root be allowed to do it?

The answer is: of course NOT! That should answer your other questions too.

You can do it from a user using a sudo -rule if you have sudo installed, but that means that this user runs some process effectively as root either.

I hope this helps.

bakunin

thank you very much.
yes, the userid i used is use to execute backup script.
but i will be using root to do the mksysb backup and test it again today.

Thank You.
After using root to do the mksysb backup, the restoration was successful.