make_tape_recovery behavior

Go to solution
Mel Burslan
Honored Contributor

make_tape_recovery behavior

Yesterday, before I left, I have started a make_tape_recovery session with the following command

make_tape_recovery -I -x inc_entire=vg00 -x exclude=/usr/app

I was hoping to have a system image that I can use to ignite install a new server, but instead of the behavior I ecxpected from the command, which was backup entire vg00 with the exclusion of /usr/app filesystem, it went ahead to backup the entire system with all the extra volume groups for application files, databases and what have you. Is there something I am missing about the make_tape_recovery command ? Like which -x option overrides others or something like that ?

As always, thanks in advance
UNIX because I majored in cryptology...
Victor Fridyev
Honored Contributor

Re: make_tape_recovery behavior


It seems to me, -A parameter may resolve the problem

Entities are not to be multiplied beyond necessity - RTFM
Steven E. Protter
Exalted Contributor

Re: make_tape_recovery behavior

Shalom Mel,

I've always thought the commands were processed left to right on the command line (as opposed to right to left as I now have to read half the time).

It may be a problem with your version of Ignite, or a simple mis-use of the second -x command. I've always used exclude/include to exclude or include volume groups, not filesystems.

It appears your include of vg00 over-rode the second directive.

It may be normal behavior of ignite.

Steven E Protter
Owner of ISN Corporation
Mel Burslan
Honored Contributor

Re: make_tape_recovery behavior


Even if my -x inc_entire=vg00 took effect and -x exclude=/usr/app was thrown out the window, what would warrant the command to go ahead and iclude all other volume_groups in the archive ? The exclude directive was for a filesystem in vg00 that I will not need on the new server. But the system went ahead to include all other volume groups which has no relevance to vg00 or excluded filesystem.

By the way, the ignite version on this system is as foillows:
# swlist -l product | grep -i ignite
# Ignite-UX C.6.6.93 HP-UX System Installation Services

UNIX because I majored in cryptology...
Patrick Wallek
Honored Contributor

Re: make_tape_recovery behavior

What does the output from the Ignite backup show? Check your /var/opt/ignite/recovery/latest/recovery.log for any errors or to see what was or wasn't included.

I use syntax similar to what you include on a couple of machines and it seems to work well.

Just thinking...What it may have done is backed up the LV structures so you have the LV for that mount point, but NOT include the data from that mount point. You should probably also checkc /var/opt/ignite/recovery/latest/flist to see if the files from that mount point were actually backed up.

If that is the case, then when you install from that tape you should just be able to delete those LV's.

Re: make_tape_recovery behavior

I have exactly the same problem.
I have done some experimentation, here is the data i have gathered.

basic make_tape_recovery with no parameters correctly backups only the minumum "essential list" files (all from vg00)

make_tape_recovery -A will try to backup the ENTIRE system, with ALL volume groups

make_tape_recovery -x inc_entire=vg00 is exactly like -A

specifying all filesystems on vg00 (-x include=/ -x include=/stand -x include=/var -x include=/usr -x include=/tmp -x include=/oracle -x include=/oracle/PR1 -x include=/oracle/PES -x include=/oracle/CEP/920_64 -x include=/opt -x include=/opt/sapbc47 -x include=/home) works correctly, only vg00 is added to the backup

sounds like a bug in -A ?