Re: OK Next step: ISM imported restore of onbar -w using disk-based backups

*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?