I would have to say it is most likely a huge mistake. Unless the other server is IDENTICAL (which is nearly impossible to accomplish). Think about /var/opt, /var/patches. Are the crontabs (/var/spool/cron) identical?
You would be much, much better off to rebuild your /var from backup.
If /var is corrupted, u should take the server in single user mode and run fsck on that file system(/dev/vg00/lvol?). I believe this will rectify the corrupted /var and if it is not resolving the issue then u should restore the backup through netbackup or whatever u r using for backup..
Is the machine running with this copied /var? Have you been able to successfully reboot it? How recently have patches been applied and what are the possibilities that patches may have to be rolled back (swremove)?
Since you have no backup (shame on you!), the only other possibility is to rebuild the machine from scratch, so it might be worth running with the copied /var until something goes wrong and then rebuild it.
It really comes down to a question of whether you can afford the downtime to rebuild it now or you would rather *try* to wait until later.
Its a two node cluster? If so then definitely the root disk would be mirrored. Pls check the lvol for /var is mirrored or not? if it mirrored then u can restore the data. How can u say that /var is corruted? did u getting any error? Pls reply with all the information. Fire these commands and give me the o/p 1.vgdispaly -v vg00 2.cmviewcl 3.lvlnboot -v 4.setboot
guys, this copy job has been done, and the server looks not bad now. of course there were something weird happened. but it seems that no one has ever explain what harm would do to the server using other's /var.
Well I thought I implied where problems could arise.
/var/opt contains files required by the various optional software packages you may have loaded on your system. /var/adm/sw contains the SD "database". Those two would be my main concern. If you have software that is loaded into /opt which expects to record data into /var/opt, it won't work. If you attempt to do anything involving SD (applying or removing patches, loading software, etc), you will have difficulty if/because things don't match between what is loaded in /opt and what is recorded in the database.
Since it was a two nodes cluster, the two nodes were the same when they were built up, if nothing changed in /opt with new software installed or no new patch installed, it could be nearly ok with this borrowed /var, right?
My main concern in that case would (again) be patches. Even with supposedly identical hardware, different patches can get loaded because there is a subtle difference somewhere - perhaps a newer version of an I/O card in one machine but not the other.
Having two completely identical machines is virtually impossible and the differences might cause problems for you some day.
Your performance software may be affected. (Check /var/opt/perf/) Even in clustered servers your data will be different. I once had a corruption of my mikslp.db and I was not able to copy it from an identical server. (I have a handful of rx6600's all cloned from a master server) Check to make sure glance, smh, sam work.
Also be aware that your btmps and wtmps will not be accurate since they were copied from another server.
As long as it runs fine, you are lucky. But sooner or later you will face the issues.
Any softwares that uses /var might get some trouble. If there is any software product configuration file customized to the system will be replaced with different settings.
As far as Performance Agent is concerned, it would start appending data on /var/opt/perf/datafiles (copied from identical box).
I don't see any issue with glance execution. It should be fine.
> HP_UX 11.23, /var corrupted, copy /var from > other server, will it be a serious mistake? Yes, it would be a serious mistake to copy a /var from another system to this system.
In a mc/sg cluster were the 2 nodes are alike, the better option would have been, when no rootdisk backup is available, to take a "ignite backup" of the "good" mc/sg node rootdisk and restore/clone that to the "bad" mc/sg rootdisk.
The problem is offcourse all patches/products/INDEX file that are beneath /var/adm/sw and that must be consistent with the binaries that are "installed on" the system.
If there are now inconsistencies between what is installed "on" the system and the information that is found in "/var/adm/sw" then there will probably be problems in the future with installing, new patches/product updates.
But anyway now that its done anyway, do a "swverify \*" , on the system that has the /var "copied to", and see how consistent the information in /var/adm/sw is, with what is installed on the system.. (and compare the swverify \* output, found in /var/adm/sw/swagent.log, on the system that has the /var "copied to", with a swverify \* output on the node were the /var filesystem is "copied from".. errors that come in both swagent.log can then be discarded as not interesting.. the others that come on the system were the /var is "copied to" and not on the system were the /var is "copied from" are the errors that probably will give problems in the future)
Like the wizard said, /var/adm/sw might create a problem especially your installed product database from which all your sw* commands work (/var/adm/sw/products). And recovering a curropted IPD is not an easy task. And what about the troubleshooting and security aspects. As of my knowledge a successful attempt on the adoptive node or an unsuccessful attempt will not be matching on the primary and adoptive nodes as the last and lastb commands are basic and integral commands for security aspects.
Regards
Read, read and read... Then read again until you read "between the lines".....
