💣 This thread may describe something risky to do carelessly
Describes manually copying and hand-editing the ixbar.N backup catalog file and building a chunk-rename file to clone a restore across instances; doing this without fully understanding onbar's catalog/storage-manager bookkeeping risks a corrupted or unusable restore.
onbar -r -p -f manual edit of ixbar.N catalog file
Advisory only — not a substitute for testing in a non-production environment first.
IDS v11.50.UC6
Solaris 10
I am trying to restore an archive of my test instance to my testfms instance.
These instances reside on the same Unix host. Here is what I have done:
The DBSERVERNAMEs involved are test and testfms andthe SERVERNUMS are 3 and 5
respectivley.
Here is what I have done so far:
1) Copied the ixbar.3 to ixbar.5 and edited out all entries other than those
from the archive I want restored.
2) Copied the oncfg_test.3 to oncfg_testfms.5
3) Created my rename chunk file with the old chunk name and offset and the new
chunk name and offset. Touched all new chunk files and chmod'd to 660,
informix, informix.
4) Copied the onconfig.test file to onconfig.testfms, updated DBSERVERNAME to
testfms and SERVERNUM to 5.
5) Ran: onbar -r -p -f /informix/etc/rename_chunks.out
And I get this:
2011-01-31 12:08:56 7440 7438 Working with cvsm as generic storage manager.
2011-01-31 12:08:56 7440 7438 There are no storage spaces/logical logs to
backup/restore.
2011-01-31 12:09:01 7440 7438 (-43140) Due to the previous error, logical
restore will not be attempted.
2011-01-31 12:09:01 7440 7438 /opt/informix/bin/onbar_d complete, returning
147 (0x93)
On a whim I tried onbar -r -f <filename> and saw the onbar process salvage
logs from test and when done it puked with the above error.
Is what I am trying to do possible? and if so what am I missing?
Thanks to Art K. for a head start on this...
MM