If you can, you should restore the system from ignite backup.
A lot of problems will arouse from bad settings in the ownership of the directories/files.
>and now I dont know which all dir under / have their file ownership changed!
If you (or your user who did it...) did not forced interruption of the chown process, all the files have ownership changed. Only newly created files snd directories would have the owner as imposed by the creation process.
everything is gone the only thing u can do is recover from backup, or if its small server and u have little information then u may try to fix major file systems and then fix the things slowlu slowly.
BR, Kapil+
I am in this small bowl, I wane see the real world......
Is there no way else? Or rather - do I have to restore the whole server? Or can I do a recursive copy of / from the Ignite tape -- I dont think so, but surely hope for it!
More points coming on the way for valuable suggestions
Dunke SNS
"Genius is 1% inspiration, 99% Perspiration" - Edison
You should follow the path Robert-Jan Goossens underlined.
Fix the installed (using swverify as suggested) applications and for the rest of the software you must make some time for it. It is a hard job to do but will keep the existing changes (between the backup and current time)
I would take an ignite backup of the current server and then will restore the server and applications/data from the oldest backup I have. Then I will restore data from the newly created ignite backup in another directory using pax in order not to overwrite the ownership/whatever of the files. Then cp will overwrite the files recovered from latest backup..
>would it ever have been possible to trace the changes
There is no automation mechanism that will get you an option of undoing those actions.
You could periodically save somewhere (in a file) all the files ownership and then you could re-staurate the ownership if something would be bad. You could write 2 scripts for this, one that will create the file with the file names and ownerships and the second for restoring the information when needed)
But in practice this is not used as it is an nonstandard procedure (for a strange situation).
>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.
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.
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
"Genius is 1% inspiration, 99% Perspiration" - Edison
>> 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.
>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..
My point was this: if the VGs that contain LUNs from SAN (at SAN level, only LUNs are 'known') were actually mounted on the very same node when your user run the chown command, then the ownership of those files are also modified! So you need to check those files also.
Of course, no harm was done if the volumes were unmounted at that time.
