chown -R xyxname:users run from / !!!

[S.N.S]

To be clearer:

1.No applications running on the Server - the server is a part of a two node cluster

2. Only application running - Oracle - is on the SAN

3. Latest Ingite backup dated 6th April


So, purely, only the OS need to be restored - and nothing else.
I can directly go the the Ignite restore - I dont see any issues - Am I correct?

Kindly advice if I am mistaken.

Dunke
SNS

[Dennis Handly]

>I just have to recover from this Disaster from Ignite Backup - Am I correct?

It depends on how much programming/scripting you want to do. Your data is all there, it's just the ownership that's wrong.

If you can get the ownership off of ignite and your other backups, you can just do chowns.

[Horia Chirculescu]

>The swverify worked-thanks

This is a start...

>No other applications running on the vg00- the only VG on this server

And this is good for you.

I believe you should check first the errors from alert.log. If by any chance you do not have any, you can continue with the instance/application up...

I would restore data from the newest ignite backup in another directory in order not to overwrite the files, then change the file ownership on the installation directory according to those.


Horia.

[S.N.S]

Hi Dennis,

Is that a very intensive process?
And can it be fully done with scripts?

I am not aware - is there any script in handy? If yes, that would simply be great!

Hoping for the best,
SNS

[Horia Chirculescu]

>1.No applications running on the Server - the server is a part of a two node cluster

You have a clustered environment. This is good.

2. Only application running - Oracle - is on the SAN

Do you mean the ORACLE instance/package was up on this node or only the application? Maybe both of the packages were running on this very same node?

>vg00- the only VG on this server

If this is a clustered environm., are you sure that you do not have also another VG?

Horia.

[S.N.S]

Horia,

>>then change the file ownership on the installation directory according to those.

There are many recursive files - how best to go about to change each dir?

Merci
SNS

[Horia Chirculescu]

>- how best to go about to change each dir

Use the recursive (-R) option.

Or you could write a script that first would read the owner/group for each file from the ignite backup then restore those on your actual server.

But in case of ORACLE instance and application things should be easier because the ownership is the same (or maybe with only a few exceptions which must be threated individually) on all files from the top directory. So chown -R should be fine.

Horia.

[Dennis Handly]

>Is that a very intensive process? And can it be fully done with scripts?

If you have a cluster, you can read the ownership from one machine and apply to the other.

>is there any script in handy?

See my scripts in:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1215123

>There are many recursive files - how best to go about to change each dir?

If the ownership is all the same, that's easy. :-)

[S.N.S]

Thanks for that again folks - Dennis and Horia...

And by the only VG on the server >>
There is only one VG - vg00 on the server;
other VGs pertain to the SAN - all related to cluster VG, and VGs for Oracle -
in recovery terms - no related application data on the server..

I look up the script from the linl - thanks!
I am taking a backup of the server as we speak...

Thanks all for your valuable advice...
Will update You, and then close the post-[ no points before the update :-)..]

Merci
SNS

[Bill Hassell]

>> One of the Users with "rootly" powers run from / the command

So you have changed the root password and will not give it to novice user ever again, correct? If you don't have sudo installed, that is strongly recommended so that your helpers will be restricted as to the damage they can cause.

>> run from /

Where is root's $HOME directory? If you made the mistake of leaving it in /, then this type of catastrophe will happen again and again. HP (and most other Unix vendors) still put root's home in / -- the worst possible location. To avoid future damage like this, move root's home directory (and root's files) to something like /root.