IDS 10.0FC3 on Solaris 9

I'm trying to do a redirected restore as per the instructions here:
http://publib.boulder.ibm.com/infoce...help/index.jsp.

I'm obviously doing something very silly but I can't for the life of me see
what. Can someone please poing out my mistake?:

$ cat restore_paths
/opt/informix/dbspaces1/rootdbs_1 0 /opt/informix/dbspaces2/rootdbs_1 0
/opt/informix/dbspaces1/physdbs_1 0 /opt/informix/dbspaces2/physdbs_1 0
/opt/informix/dbspaces1/llogdbs_1 0 /opt/informix/dbspaces2/llogdbs_1 0
/opt/informix/dbspaces1/capsdbs_1 0 /opt/informix/dbspaces2/capsdbs_1 0
/opt/informix/dbspaces1/capsdbs_2 0 /opt/informix/dbspaces2/capsdbs_2 0
/opt/informix/dbspaces1/capsdbs_3 0 /opt/informix/dbspaces2/capsdbs_3 0

$ ontape -r -rename -f /opt/informix/dbspaces2/restore_paths

Please mount tape 1 on /opt/informix/dbspaces2/tapedev and press Return to
continue ...

Archive Tape Information

Tape type: Archive Backup Tape
Online version: IBM Informix Dynamic Server Version 10.00.FC3
Archive date: Mon Aug 15 18:57:55 2005
User id: informix
Terminal id: /dev/pts/2
Archive level: 0
Tape device: /opt/informix/dbspaces1/tapedev
Tape blocksize (in k): 768
Tape size (in k): 0
Tape number in series: 1

Spaces to restore:1
]
2
]
3
]
4
]

Archive Information

IBM Informix Dynamic Server Copyright(C) 1986-2004 IBM Informix Software,
Inc.
Initialization Time 08/01/2005 23:20:06
System Page Size 2048
Version 14
Archive CheckPoint Time 08/15/2005 12:55:22

Dbspaces
number flags fchunk nchunks flags owner
name
1 40001 1 1 N B informix
rootdbs
2 40001 2 1 N B informix
physdbs
3 40001 3 1 N B informix
llogdbs
4 42001 4 1 N TB informix
tempdbs1
5 42001 5 1 N TB informix
tempdbs2
6 42001 6 1 N TB informix
tempdbs3
7 40001 7 3 N B informix
capsdbs


Chunks
chk/dbs offset size free bpages flags pathname
1 1 0 256000 253180 PO-B
/opt/informix/dbspaces1/rootdbs_1
2 2 0 256000 0 PO-B
/opt/informix/dbspaces1/physdbs_1
3 3 0 5120000 0 PO-B
/opt/informix/dbspaces1/llogdbs_1
4 4 0 1024000 1023847 PO-B
/opt/informix/dbspaces1/tempdbs1_1
5 5 0 1024000 1023847 PO-B
/opt/informix/dbspaces1/tempdbs2_1
6 6 0 1024000 1023847 PO-B
/opt/informix/dbspaces1/tempdbs3_1
7 7 0 10240000 13 PO-B
/opt/informix/dbspaces1/capsdbs_1
8 7 0 10240000 10 PO-B
/opt/informix/dbspaces1/capsdbs_2
9 7 0 10240000 5702745 PO-B
/opt/informix/dbspaces1/capsdbs_3

Continue restore? (y/n)y
Do you want to back up the logs? (y/n)n
Physical restore failed - ONCONFIG ROOTPATH:
'/opt/informix/dbspaces2/rootdbs_1' differs from archive:
'/opt/informix/dbspaces1/rootdbs_1'
Correct ONCONFIG before restoring this archive.


Program over.

Thanks
Neil

"Neil Truby" <neil.truby (AT) ardenta (DOT) com> wrote

Actually you *do* need to change the $ONCONFIG to have the "wrong" ROOTDBS,
although these somewhat "counter-intuitive" to say the least. The restore
process seems to change it to the correct value later.

renaming chunks duing a restore..key considerations...

"During a cold restore, ontape performs the following validations to
rename chunks:

3. If renaming the primary root or mirror root chunk, it updates the
ONCONFIG file parameters ROOTPATH and ROOTOFFSET, or MIRRORPATH, and
MIRROROFFSET. The old version of the ONCONFIG file is saved as
$ONCONFIG.localtime. "

I assume ontape needs the onconfig to match what is on the tape. It
then
does the update to onconfig itself and create a new
$ONCONFIG.localtime!

The ROOTPATH in the restore instance ONCONFIG must be the same as the
ROOTPATH in the source instance. The rename restore process then
changes it later on based on the restore_path file.

Bill


sending to informix-list