restore file systems

[Hanry Zhou]

We've decided to restore all application file systems from 3 months old backup with 0exception of those on vg00(/usr, /, /var...).

In order to match all user id's, we will first restore /etc/passwd and /etc/group, and these are only two files we think we need to restore from file systems on vg00.

We will also shutdown oracle database first.

Is there any other consideration with regards this task?

[Mel Burslan]

usually .home is part of vg00 and as it gets modified very often by the users, you may want to include this in your restore plan.

avoid restoring anything to
/
/stand
/var
/usr

also if your database is running on raw disk devices, you may need to consider recovery of these volumes as well.

[Geoff Wild · Accepted solution]

I would make sure before you started - that you also backup the system as is.

As far as user id's - you may want to find all files owned by users that don't exist in the old /etc/passwd prior to restore...

Rgds...Geoff

[RAC_1]

you can restore /etc/passwd and /etc/group to some other location. This will help you know who were the users and group then.

The file systems you restore, if can jot match the use, then will put them as root owned files.
Later on you can grant access to what ever users you want to.

Anil

[Hanry Zhou]

Geoff,

Your suggestion to backup the system first is great!

anybody else?

[Steve Post]

look at tech doc OV-EN010346
"What files to exclude from restore of root volume group on omniback cell manager."

I know you're skipping vg00...GOOD.

Here's the files they list to skip.
/dev/vg0X for vg's not being restored
/dev/dsk/*
/dev/rdsk/*
/stand/ioconfig
/etc/ioconfig
/etc/lvmtab
/etc/lvmconf/vg00
/etc/fstab
/var/opt/omni (well it IS a document about omniback...I mean Dataprotector).
--------------------------------------
Make map files of the volume groups. Make sure you use the "-p" preview mode when running vgexport.
--------------------------------------
Have the results of "ls -l /dev/vg*/group".

Have paper copies of the ioscan, vgdisplay -v, swapinfo, bdf, lanscan -v, netstat -i, netstat -in.

steve

[Hanry Zhou]

If I want to restore the entire application file system from 3 month old data, and also with the option of "overwritten", the restore will give me the exactly the same file system as it appeared 3 month ago? what about those file or directories we have created within the last 3 months, would they still there after the restore?

[Steve Post]

I don't know. Since I don't know, the answer would be to run a test on a DIFFERENT box.
Have a SMALL directory with subdirectories and files in it.
Back it up (with whatever backup application you are using).
Add new files to the directories.
Remove some files from the directories.
Run a restore.
Were the removed files restored?
Were the new files (the ones not backed up) destroyed?

Now I assume when you restore the data, the filesystem will already be mounted, and empty. Or the filesystems will be mounted and you will choose to overwrite.

Another thing....
What if the file you are overwriting is in use? In omniback there is an option to restore busy files.

[Hanry Zhou]

Should I remove all date on the file system( by recreating the file system) first, then perform the restore? In this way, it will be sured the entire file system will be exactly same as the one appeared to be 3 month ago.

Does anybody have the experiece?

[G. Vrijhoeven]

Hi,

If you remove all data prior to restoring the backup, you are sure you are 3 months back. Just make sure you have all the users/groups available on the server prior to restoring. If you have enough free space you can do a move of all in the filesystem to a backup dir.

Regards,

Gideon

[Hanry Zhou]

G.


I have about 20 file systems need to be restored, so it is quite a lot of work to recreate file systems and then restore from the backup.

Do I have to clean up all date (recreating file systems) before I perform the restore?

[Patrick Wallek]

Actually it wouldn't be too hard at all to clean up all the filesystems if that is what you REALLY REALLY REALLY want.

The easy way would be to do:

# umount /filesystem
# newfs -F vxfs -o largefiles /dev/vg??/rlvol?
# mount /filesystem

The newfs will create a blank filesystem on that LVOL.

The above could be scripted, just MAKE ABSOLUTELY SURE you use the CORRECT rlvol name in the newfs command.

[Hanry Zhou]

Patrick,

I don't konw. that is why I post the question. In order to recover all these file systems to exactly same as before, no more, no less, do I have to clean up the file systems and recreate them to get clean empty first, then finally recover the file system from the backup?

[Patrick Wallek]

If you want to be ABSOLUTELY sure you want to be at the EXACT same point as 3 months ago, then YES I would clean out the directories you plan to restore.

Just be sure what you are cleaning out. Don't accidentally clear out something that the OS needs.

I would NOT use my newfs idea above on ANYTHING that has VG00 as the volume group.

[Hanry Zhou]

Patrick,

No, I'm not going to do anything on vg00, other than those application file systems.

So, I really should recreate all these 20 file systems, and get a empty ones, then finally perfom the restore from previous backup. Is this a good idea, is there any other better idea?

I did a test, if I restore and with overwitten option, the newer files would be still existed on restored file systems.

[Patrick Wallek]

>>>No, I'm not going to do anything on vg00

Good!

>>>So, I really should recreate all these 20

>>>file systems, and get a empty ones, then
>>>finally perfom the restore from previous
>>>backup.

If your goal is to be exactly as they were when the backup was 3 months ago -- Yes.

>>>Is this a good idea

I have no idea. Apparently it is something you must do.


>>>, is there any other better idea?

To go back to 3 months ago -- None that I can think of.

>>>I did a test, if I restore and with
>>>overwitten option, the newer files would be

>>>still existed on restored file systems.

That is true!