make_tape_recovery of vg00

[ian morgan_3]

Hi there, recently during a recovery test, we used an ignite backup to retrieve vg00. However, vg01 was also recovered which was not expected and eventually not required as problems where encountered. I have modified the command to store only vg00 (inc_entire option), however, vg01 is still stored to tape. Can you advise on howe to store out cg00 only please. I am using the command /opt/ignite/bin/make_tape_recovery -AIv -a /dev/rmt/0mn -t UKCLIVX2_Ignite -x inc_entire=vg00 > /root/backup/weekly_ignite_report. OS is 11.00.

[Pete Randall]

ian,

Your command, as written, should not be going anywhere near vg01. Check for aliases to the make_tape_recovery command, download the latest version ( http://www.software.hp.com/products/IUX/index.html ), and try again.


Pete

[Sunil Sharma_1]

Ian,

You command is perfectly alright. It should not touch vg01.

Sunil

[Borislav Perkov]

Hi,
I think it comes from -A where in the man it says:

-A Based on the files that are specified for inclusion, this option identifies the disk(s) and/or volume group(s) that contain these specified files and includes all files from the disk(s)/vg(s) in the archive.

Regards,
Borislav

[Pete Randall]

I had kind of skimmed over the -A option that Borislav points out. On further review, I'm beginning to wonder if that has something to do with it. Check /opt/ignite/recovery/mnr_essentials or /var/opt/ignite/recovery/mnr_essentials to see if there is any reference to vg01 or the filesystems that reside on vg01.

I would drop the -A option altogether and I'm not sure why you're using the -l option either.


Pete

[ian morgan_3]

Pete et al, thanks for swift replies, I'll look into the mnr_essentials aspect of your reply. I'm using -I to kick off an interactive session during recovery.

[Pete Randall]

OK, that's my fault, I was interpreting it as a lower case ell (l), when, in fact, you are using an upper case eye (I). The fonts here on the forums don't distinguish well between the two.


Pete

[ian morgan_3]

Pete, no connection between fs's listed in mnr_essentials and vg01. I 've checked approx 10 other ignites that run exactly the same script and none of them take vg01 into consideration. I removed the -A flag but this only gave me a partial store of vg01 as opposed to a full store! I'm still baffled. Next step is to download the latest version I suppose and see how that goes.

[Sridhar Bhaskarla]

Hi,

The only case I think of getting vg01 included, if you don't explicitly specify it,
is

//The contents of the system recovery archive will always include all
files and directories which are considered essential to bringing up a
functional system.//

I wonder if you have any essential filesystems like /usr, /opt on your vg01.

Post your bdf output.

-Sri

[Roberto Arias]

Hello Ian:

Please check if you have any system's file in a filesystem of vg01.The make_tape_recovery only store files needed for OS.

Reply with the output of this check and I try need you.

thanks
Rober

[Ravi_8]

Hi,

your command is perfectly alright, it shouldn't touch other vg's other than vg00.

upgrade your ignite version and check it out

[Pedro Cosmen]

Hello Ian,

Maybe you are recovering over the same system with all the disk connected, and the Ignite saves (and then restores) all the vg layout (vg00, vg01,...) So when you boot your recovered systen it recognizes your "old" vg01 then put it "on line".

Regards.

[ian morgan_3]

Ravi, nothing obvious except /home/oracle may be getting interpreted as a required system f/s,

/dev/vg00/lvol3 204800 39064 155414 20% /
/dev/vg00/lvol1 99669 36626 53076 41% /stand
/dev/vg00/lvol8 1064960 729767 314405 70% /var
/dev/vg00/lvol9 1228800 1406 1150690 0% /var/adm/crash
/dev/vg00/lvol7 1130496 516491 575683 47% /usr
/dev/vg00/tivoli 73728 39360 32265 55% /usr/tivoli
/dev/vg00/lvol6 307200 95899 198661 33% /tmp
/dev/vg00/lvol5 512000 372757 130570 74% /opt
/dev/vg00/lvol4 204800 157270 44623 78% /home
/dev/vg01/lvol1 2560000 2417192 133926 95% /home/oracle
/dev/vg02/lvol2 4694016 1541203 2955827 34% /home/oracle/oradata/temp
/dev/vg02/lvol1 4194304 160241 3781937 4% /home/oracle/oradata/redolog
/dev/vg01/lvol3 4096000 885241 3010092 23% /home/oracle/oradata/partition3
/dev/vg04/lvol1 8888320 7171340 1663840 81% /home/oracle/oradata/partition2
/dev/vg03/lvol1 8888320 5415100 3364940 62% /home/oracle/oradata/partition1
/dev/vg01/lvol2 1536000 26909 1415535 2% /home/oracle/oradata/archredo
/dev/vg00/exp 1024000 4073 956251 0% /home/oracle/exp1

[Bill Hassell · Accepted solution]

The -A option will introduce instability (IMHO) in your backup. In the old make_recovery program, it was required to copy everything rather than a minimum system. In the new make_tape_recovery, -A says to copy from any VG where 'required' files are located. My guess is that /home is the problem. Even without -A, it is still saving vg01 files, probably anything in the /home tree that exists on other VGs.

I ran into this exact scenario because I had to move /opt to VG01. The warning is found in the -v option:

"WARNING: The volume group /dev/vg01 will be only partially included in the System Recovery Archive. This means that not all files and directories on this volume group will be restored when the archive is installed."

This isn't desirable because Ignite realizes that VG01 must be part of the backup but worse: the WARNING causes a non-zero exit code, so scripting an mtr backup always returns a failure code on this machine. A similar cituation exists for a CDROM in fstab. I use the nifty noauto option to keepp it from being mounted at bootup, but just issue the command: mount /cdrom whenever I need the CD. mtr doesn't know about noauto or cdfs so it thinks this is an unmounted filesystem and returns an error code. The lab is supposed to be looking into these problems.

In your case, moving the oracle directory structures out of /home (even though they are separate mountpoints) is probably the only fix.

Rather than redirecting the output into a logfile (I did this too for a while), I use the file /var/opt/ignite/recovery/latest/recovery.log which is always a copy of the screen when mtr was last run.

[Prashant Zanwar_4]

-A Based on the files that are specified for inclusion, this option identifies the disk(s) and/or volume group(s) that contain these specified files and includes all files from the disk(s)/vg(s) in the archive.

I believe you dont have to mention the -A option. If I am not wrong, you are asking copy VG00 entirely. For this -x inc_entire=vg00 will be taking care in all. If you say -A then if there are any files which are relevant and present on other VG, then that VG might be copies partially whereever it comes across references to such files.

/opt/ignite/bin/make_tape_recovery -x inc_entire=vg00 -vl -t "Recovery tape created on $(hostname) on $(date)"

This is how I create my ignite. in addition you may try using -x include=
This does not cross the mount point.

Hope this helps.
Thanks
Prashant

[ian morgan_3]

Bill/Prashant, thanks v much for valauble input. All in all, with the advice given from all replies, I can ascertain that removing the -A option still gives me a partial backup of vg01. Soooo this leads me to believe that Bills /home explanation is the culprit. Although I 'd like to strip out Oracle f/s's (and leave them that way hahaha) its not an option. Upon system build non standard f/s have been setup for oracle. None of our other systems have this setup and stunningly?, none of those systems attempt to extract /vg01 to mtr. Thanks a lot everyone, I'm happy with consclusion to this problem. Give yourselves a shiny!!!

[Prashant Zanwar_4]

Good that you have got a conclusion. I am happy too..Please dont forget to assign points whenever you get time.
Thanks
Prashant

[Bill Hassell]

One possibility for the difference between systems:

cat /opt/ignite/Version
what /opt/ignite/bin/make_tape_recovery

You may have different versions of Ignite on your systems.