Hi,
I just want to ask whether anyone has experience on restoring mksysb backup in NIM. We have taken the mksysb backup and the SPOT has been configured on NIM also. I just want to know the checkpoints before doing this. Is there any checkpoints we need to do? Do we need to unmirrorvg? This server is running HACMP. Thanks.
Yes, of course. It is actually hard to avoid when you work with AIX.
I don't know what you mean by "checkpoints". If you have used the NIM methods to create the mksysb you have already established a working communication between the NIM server and the client. If you want to restore the mksysb image to the client create a NIM resource for this client, shutdown the client, start it into the SBB menu, enter the IP address of the NIM server into the appropriate menu screens and off you go. NIM relies on bootp as a protocol, therefore all the routers, switches and whatever network equipment you have between client and server have to pass through bootp.
Further, there is a common problem with exports: NIM will create a (temporary) NFS share (/etc/exports) for the client on the server. If a superdirectory of this share is already exported this may (or may not) confuse NIM. The best way to avoid this is not to export any superdirectory of the place where the NIM resources are located.
If you run a server with HACMP this is indicative of the server being quite critical to some operation. In such a case not having tested backup and restore of the system before commissioning it is somehow careless, isn't it? In this case you should announce some downtime with the users to test the process. It is almost 100% foolproof and rarely fails, but in the remote case of failing you will not have to explain why you're testing on a productive system.
Anyway you don't have to unmirror anything: a mksysb image is basically a "savevg rootvg" and contains not only the data of the rootvg, but also the disk layout, the filesystem layout, etc..
I hope this helps.
bakunin
Hi bakunin,
Thanks for the prompt help. I thought that the server will be rebooted automatically when you do a administration task in NIM? I have found the below link. Can you please verify that the informations and steps provided are correct:
(uN)Tech blogs: AIX 5L NIM mksysb restore
These are newly configured servers (not live yet) but the client need to test backup and restoration from NIM. Do you have any site where explains the step by step procedure? I just want to be safe. Thanks
The description seems to be to the point. In case you are not familiar with the NIM concepts you might want to read this little description.
Btw., just to be sure: you can create an mksysb image into a file on the client machine too - this is NOT a valid NIM resource, even if it is more or less the same. For NIM it is NOT the same. You have to create a mksysb image through NIM means on the server (like it is described in the document you linked) to get a valid NIM resource to boot from.
I hope this helps.
bakunin
Hi Bakunin,
Thanks for the help. I will try this one and let you know. Hope everything goes smooth and if not I hope I can ask again for help. Thanks a lot.
---------- Post updated 04-06-10 at 03:37 AM ---------- Previous update was 04-05-10 at 08:12 PM ----------
Hi Bakunin,
Just an update. I seek IBM engineer advice to make sure everything works fine. He told me to do the following:
1.) unmirrorvg hdisk1
2.) reducevg hdisk1
3.) bosboot -a hdisk1
4.) bootlist -m hdisk0
5.) Create mksysb via NIM
6.) Install in hdisk0
If everything fails, I can still set the boot device to hdisk1. I am going to do it tomorrow. So does it mean that if I trigger the backup in NIM the server will automatically restart and I will need to set the IPL to network?
Thanks and Regards,
Don
This is true in a way: if you break the mirror you have two identical copies of the rootvg and if you destroy one you still have the other. The same principle is used in the alt-disk-install procedure.
I still don't think this is necessary because you said above that the server is not commissioned yet. The worst which could happen is that you will have to set up the server from scratch.
While the IBM engineer is right about this being the most failsafe procedure it also introduces a little uncertainty because you are not testing what you will use in production. I prefer to make my tests always as close to production as possible.
Not at all! If you trigger the backup on the NIM server it will create a NIM resource of type mksysb, nothing more. You will have to allocate this (and a few secondary) resource(s) and generally the follow procedure for installing NIM clients from a server to reinstall your system using this mksysb image. You will also have to manually stop the client and initiate the reinstall in the POST-menu there.
I hope this helps.
bakunin
Hi bakunin,
Thanks for the prompt reply. I just found out that I don't have the fileset
bos.alt_disk_copy.rte which is needed for cloning the disk to hdisk1
and I only have the bos.alt_disk_install.
Though the server is not live yet and the worst thing that could
happen is to reinstall everything, we really cannot afford to
reinstall since most of the vendors are from different parts of
the world who flew in here to do the configuration and installation
There are some application specific configuration in the rootvg
that we could not replicate if any damage is done on the rootvg.
Moreover, I have already have the mksysb and have the SPOT which
is of the same TL level. From the previous document I showed you
I can do the following:
1.) smitty nim_bosinst
2.) choose mksysb
3.) choose the SPOT image
If you are not that busy, can we chat so I can ask some questions?
Thanks and Regards,
Don
You won't need alt_disk_copy or alt_disk_install as far as i know. You can mirror the rootvg and then unmirror it, just like the IBM engineer advised you to do.
If you can't afford to risk the machine i suggest you follow this advice and create a spare mirror of the rootvg disk(s) as a safety device. What i said about near-production conditions is true but an ideal: one has to make do with what one has got and what one can afford.
I hope this helps.
bakunin
Moderative Postscriptum BEGIN
If you still have questions ask them here and I (and everybody else) will be glad to answer them: the goal of this board is to create a knowledge base for everyone and when i answer your questions i will not only help you but hopefully everybody else with the same or a similar problem and the skill to use our (quite user-friendly) search engine. If i would tell you the same in a chatroom it would be wasted insofar as nobody else would have the possibility to benefit from it. I hope you understand that.
Moderative Postscriptum END
Hi bakunin,
Thanks alot for the info and I'm very sorry to ask you to talk privately. It is not my intention. Just to ask, is this the steps to do this:
1.) unmirrorvg rootvg hdisk1
2.) reducevg rootvg hdisk1
3.) do a mksysb backup
4.) bootlist -m normal hdisk1
5.) bosboot -a hdisk0
6.) bosboot -a hdisk1
7.) nim_bosinst on NIM server
8.) System will reboot and point the boot device to ethernet
9.) install on hdisk1
The system will boot and hdisk1, bring up HA and test. If everything okay how can I remirror back? I actually don't know how to make the client boot from nim. I already checked that there is /tftpboot in place and that /etc/bootptab already have the client IP addresses. Please note that NIM was previously used to install the base OS. But I have never really done this before. Thanks.
I am not trying to take over here, bakunin is doing a fine job but I just wanted to mention that on my NIM server when you set up a mksysb install to a client the "Initiate reboot and installation now?" option is defaulted to "yes". If I misunderstood the task being performed here I beg for your forgiveness.
Hi jurred1,
Thanks for the response. Yes, i saw this option when I do a smitty nim_bosinst. I am to try it later. I think the client should reboot by itself and boot thru network and in SMS. If my previous resource document is correct. I am doing this later and cross-fingered everything works fine. By then, I can only confirm the results of your suggestions. Thanks a lot.
You are welcome. The idea of this board is to OPENLY DISCUSS and everybody contributing to this is welcome. Btw., my advice is far from being perfect, see below.
Sorry for answering sloppily before: yes, you can initiate the reboot from the NIM server provided that the NIM client fileset is already installed on the client. You have to start up to the POST-menu and enter the IP address of the server like described above in case of some "virgin" hardware. The only thing you need to know to define a "standalone client" (NIM wording) is the MAC-address of the interface used to install it and you can find this out in the POST-menus too, so it is possible to install a system completely from scratch.
This brings me to a suggestion: if you don't want to risk your precious installation but you have some spare hardware you could get a maintainance-window, shut down the production machine (to avoid double IP addresses, etc.), install the spare hardware with the image you took (you can allocate the mksysb image to any client, not only the one it originated from) and restore there. Then test the installation, scratch your test installation and start up your production system again.
I hope this helps.
bakunin
PS: insist on getting such test hardware. It is necessary not only for such purposes but also for testing updates, regression tests, .... If it is argued that money is an issue: if the costs of such a test system do not equal the risk of interrupted service because of updates or maintainance gone awry then this risk is not all too big at all, yes? If the customer who is paying for the system isn't valueing its high availability why should you?
I think I only have one other thought. bakunin suggested installing on some spare hardware and taking down the production machine to avoid duplicate IP address after the spare hardware comes up.
I have done the same thing here but placed the spare hardware on a different VLAN than the production hardware. Setup a temp hostname in the /etc/hosts file, such as unixtest and given it an unused IP from the other VLAN. Create a new host within NIM called unixtest. Then you should be able to leave the current production up because after the install finishes on test hardware even when the production IP is placed on test hardware it will not be detected since it will be on a different VLAN.
Then you can get in through the console, HMC, etc..... to change the IP to a usable one for that VLAN. Just be cautious about crontab entries on the test machine running and doing things you don't want them to.