System Administration
cancel
Showing results for 
Search instead for 
Did you mean: 

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

 
SOLVED
Go to solution
stephen peng
Valued Contributor

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

guys,
HP_UX 11.23, /var corrupted, copy /var from other server, will it be a serious mistake?

regards
Stephen
16 REPLIES
Pete Randall
Outstanding Contributor

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

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.


Pete

Pete
ani007
Super Advisor

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

Hope you have veritas netbackup.so restore it ASAP.
shikhar_1
Regular Advisor

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

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..
stephen peng
Valued Contributor

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

these two nodes belong to same cluster. they were built up together 3 years before.
fsck failed to recover /var, and no backup for restoring.

regards
Stephen
Pete Randall
Outstanding Contributor

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

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.


Pete

Pete
amipankaj
Frequent Advisor

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

In any case, coying /var is not good idea. Its better to recover troubled system from ignite of other one in the cluster.


Cheers!
Pankaj
shikhar_1
Regular Advisor

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

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

stephen peng
Valued Contributor

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

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.

regards
Stephen
Pete Randall
Outstanding Contributor

Re: what problem will be when 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.

I'm sure the list goes on, but that's the start.


Pete

Pete
stephen peng
Valued Contributor

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

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
Outstanding Contributor

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

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

Pete
S. Ney
Trusted Contributor

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

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
Valued Contributor

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

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
Honored Contributor
Solution

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

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
Esteemed Contributor

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

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
Read, read and read... Then read again until you read "between the lines".....
stephen peng
Valued Contributor

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

finished. should be problems, go and see.

regards
Stephen