what problem will be when using other's /var?

[stephen peng]

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?

[Pete Randall]

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.


Pete

[S. Ney]

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.

[muruganantham raju]

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.

[chris huys_4 · Accepted solution]

Hi stephen,

> 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)

Greetz,
Chris

[Ismail Azad]

Hi,

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

[stephen peng]

finished. should be problems, go and see.

regards
Stephen