Ontape restore to another server

Posted in 2006

Summary

Gary wanted to restore a Solaris 9 (raw devices) IDS 9.4 ontape backup onto a Red Hat box with cooked files to recover data from a damaged table, also asking whether remote tape (server:/dev/rmt/0) restore would work. Replies said a cross-platform ontape restore is impossible: on-disk data is stored in native CPU format (SPARC big-endian vs Intel little-endian), so dbexport/dbimport is the usual route. Art Kagel's suggested fix: use the IDS 10 archecker to extract just that table from the tape into a small IDS 10 instance on the Sun box, then reload/copy it back to production (e.g. with dbaccess or his dbcopy utility).

Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.

Topics: Backup & Restore, Platform-Specific Issues

Gary Quiring — 28 Dec 2006 07:01:34 -0800 — source: Usenet: comp.databases.informix

I have a need to restore our production DB (9.4) to a junk box to salvage a table that recently lost some data. I am not very familiar with the steps required. The production server is running Solaris 9 with raw devices. I was hoping to restore to a Red Hat box using cooked files. Is that possible? I also need to remotely restore the data from the tape drive as my RH box has no tape device. I assume just changing the TAPEDEV to server:/dev/rmt/0 will work. Will issuing the ontape -r from the red hat server restore the data to the local drives? I obviously don't want to restore the data over the production server. Thanks Gary Quiring

↪ replying to Gary Quiring

Keith Simmons — Thu, 28 Dec 2006 15:24:13 +0000 — source: Usenet: comp.databases.informix

On 28 Dec 2006 07:01:34 -0800, Gary Quiring <gquiring@gmail.com> wrote: > I have a need to restore our production DB (9.4) to a junk box to > salvage a table that recently lost some data. I am not very familiar > with the steps required. The production server is running Solaris 9 > with raw devices. I was hoping to restore to a Red Hat box using > cooked files. Is that possible? > > I also need to remotely restore the data from the tape drive as my RH > box has no tape device. I assume just changing the TAPEDEV to > server:/dev/rmt/0 will work. Will issuing the ontape -r from the red > hat server restore the data to the local drives? I obviously don't > want to restore the data over the production server. > > Thanks > Gary Quiring > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > Gary Forget it, there is no way this will even begin to work! dbexport/dbimport is your only option between different O/S. Keith

↪ replying to Keith Simmons

Gary Quiring — 28 Dec 2006 07:33:14 -0800 — source: Usenet: comp.databases.informix

Keith Simmons wrote: > Forget it, there is no way this will even begin to work! > dbexport/dbimport is your only option between different O/S. > WOW! Data is not compatible between OS's? Why would Informix be so inflexible about the data between hardware platforms?

↪ replying to Gary Quiring

Madison Pruet — Thu, 28 Dec 2006 11:04:11 -0600 — source: Usenet: comp.databases.informix

Gary Quiring wrote: > Keith Simmons wrote: >> Forget it, there is no way this will even begin to work! >> dbexport/dbimport is your only option between different O/S. >> > WOW! Data is not compatible between OS's? Why would Informix be so > inflexible about the data between hardware platforms? > Integers are not the same on intel chips as they are on the solaris sparc chip. It has nothing to do with the OS, but rather the format of integers used by the chip. For the number 67305985, Intel would use 0x01020304 while the sparc chip would use 0x04030201.

↪ replying to Gary Quiring

Art S. Kagel — Fri, 29 Dec 2006 11:28:54 -0500 — source: Usenet: comp.databases.informix

Gary Quiring wrote: > Keith Simmons wrote: > >>Forget it, there is no way this will even begin to work! >>dbexport/dbimport is your only option between different O/S. >> > > WOW! Data is not compatible between OS's? Why would Informix be so > inflexible about the data between hardware platforms? > When sending data to remote clients network protocols are used and data is converted to be compatible withthe client, but on disk IDS stores native server CPU format for data types supported by the platform like integers ('C' int), smallint ('C short), smallfloat (ie 'C' float) and floats ('C' double) for maximum efficiency with local and native remote clients. Think about it and it makes perfect sense. Orable's insistence on storing BCD for integers and floats is the one I don't fathom. Art S. Kagel

↪ replying to Gary Quiring

Art S. Kagel — Fri, 29 Dec 2006 11:41:00 -0500 — source: Usenet: comp.databases.informix

Gary Quiring wrote: > I have a need to restore our production DB (9.4) to a junk box to > salvage a table that recently lost some data. I am not very familiar > with the steps required. The production server is running Solaris 9 > with raw devices. I was hoping to restore to a Red Hat box using > cooked files. Is that possible? > > I also need to remotely restore the data from the tape drive as my RH > box has no tape device. I assume just changing the TAPEDEV to > server:/dev/rmt/0 will work. Will issuing the ontape -r from the red > hat server restore the data to the local drives? I obviously don't > want to restore the data over the production server. Gary, go with the IDS 10 version of archecker to extract the data from the tape and recreate the table in a small IDS 10 instance on the Sun box. Then you could extract and reload to the production server, or copy directly from one to the other using dbaccess or my dbcopy utility as long as there are no special columns (and you could upgrade the dbcopy source to support your data types as well). Art S. Kagel

Related threads

Glossary

ontape