For reasons to complex to go into, we're now backing up to disk (data
and logs), using onbar -w and ISM, pool names ISMDiskData and
ISMDiskLogs whereas before we used an external storage manager to
tape.
We do a copy of our live database (300Gb or so) on a regular basis
onto our development system, a separate machine running the same
version of IDS and HP-UX, to an instance configured exactly the same
as the live instance (spacenames, chunknames etc).
Under the old system we had a procedure we followed that worked fine;
now we're building the procedure to do this under the new ISM regime.
All the "Imported Restore" methods I've seen include a step to re-
initialize ISM on the target machine and rebuild the indexes, catalogs
etc using the imported catalogs and indexes from the source machine,
but that's not an option on our development system because we have
several IDS instances running and communicating with ISM, only one
instance of which is to be restored over; so if we overwrite ISM we
prevent the other running instances from using it, which we can't do.
Anyone know how to do an imported restore under these circumstances?
Can't we import just the relevant

So far I've looked at:
http://www-01.ibm.com/support/docvie... SGU8G&mync=R
http://publib.boulder.ibm.com/infoce...i051000051.htm

To complete the truncated line!...

> Can't we import just the relevant media entries?

C'mon, anyone?
To use ISM restore an instance from our live server to our test
server, which carries 3 instances, we have to trash all ISM info on
the target server regarding all 3 instances?
No way around that?

On Nov 11, 10:21*am, Malc <mal... (AT) googlemail (DOT) com> wrote:
As per http://publib.boulder.ibm.com/infoce....doc/ism02.htm

- run ism_show -devices
- link your volume to the device
- run ism_op -mount <device>
- run ism_recatalog -recreate_from <device>

You may need to recreate the storage poosl for the original server
first, I have some undocumented commands to do that which I canot
share, check early Legato Networker documentation.

Hello Malc,

David is probably right. Another option is to backup the live
production to disk using ontape with compression. It is easier, more
reliable, usually 1/10 the original size and usually "fast enough".
Or, if you can shutdown production, then run cp, rcp, dd or whatever
to copy the chunk files to the backup (or restore) location. I have a
terabyte cooked system and for more speed I run "compress -c FILENAME
directory.

-LS

*Sigh*.
I'm reading something wrong, here, surely? Or maybe I'm not expressing
what the situation is and what we need to do?
The imported restore procedure in the link mentioned is the one I'm
already working from.
I have set up a minimal instance on our live and development machines
to test with and have followed the procedure (with some minor
deviations that weren’t mentioned), and as far as it goes, it worked
ok.
BUT.
It seems to only cover the situation where you need to restore the
database from one server to another completely blank server (hence the
section "You need to port and replicate ISM on the target database
server."); i.e. a disaster recovery or the first phase of replication.
It doesn't take account of the fact that the target machine *already
has* a running ISM on it and this target machine also has three
database instances on it, only one of which is being restored to, that
are constantly running and using ISM; and by porting ISM to that
machine you by default have to trash that ISM installation. AFAICS,
anyway. Not being a Legato expert.
I just want to restore one instance but it doesn’t seem possible…
ontape is not an option, we use ISM to disk and that's taken later by
the corporate backup mechanisms(tm) and that's it!

Ah well.
We've got a procedure together for restoring, following the arcane
"Imported Restore" process from chapter 5 of the ISM guide.
If anyone else has used this procedure, do you get a really S-L-O-W
turnaround on the "ism_catalog -recreate_from" stage?
Looks like it's reading all the data from each and every chunk on disk
and it takes forever...12 hours+ in our case (on a remotely mounted
filesystem from our dev box to the production box for 290Gb of data).
OK we can probably tune this with some super hoopy network cards and
so on but does anyone know why this stage takes so long? What's it
doing?

Hello Malc,


yes have been there also with the real legato product, took back then
longer then a week to recreate from device.
In the end we copied the catalog from production to test and that
worked.
On windowze ism_catalog -recreate <from tapedev> does not work at
all....


Yes it will try to reconstruct it's catalog doing small io's

You are better off to grab the catalog using tar or backup the
bootstrap, this however will kill the other stuff.
sorry no better answer; so you can accept it or use something else.
I would however if i were you file a feature request to ibm/informix
to make this better.
will be difficult though.

Superboer.


On 1 dec, 12:01, Malc <mal... (AT) googlemail (DOT) com> wrote:

SB, thanks for that, not as if it's encouraging info though!

I'll have a go at copying the catalog over, we're resigned to trashing
the target machine ISM installation anyway - which files will we
require?

Hello Malc,

shutdown ism;

tar up stuff under
/nsr
and you may need to hack around the files in /nsr/res/* ; change and
replace the prod host name /ip to the test hostname /ip

When we did all of this legato told us that this was highly
unsupported........!!!!!!!!!
please do test this first on a test box and make plenty of copies..



Superboer.

On 4 dec, 16:51, Malc <mal... (AT) googlemail (DOT) com> wrote: