Dbspace recovery
Testing disaster recovery, the poster tried to restore a single dbspace (ontape -r -D db_tables) from an old server's level-0 archive into a freshly created instance on a new host, hitting "not in DBspace table", "Invalid DBspace list" and "Archived 'db_tables' is a different space" errors. Answers: chunk pathnames must match (or use ontape's -rename/-f options), and you can't graft a dbspace onto an unrelated instance. Losing a server requires a full cold restore; a warm single-dbspace restore is only possible once the matching rootdbs has been cold-restored. For recovering dropped/deleted data, archecker table extraction was suggested. INFORMIXSERVER name is irrelevant. No confirmation the poster's restore succeeded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi,
I have started testing revovery of a singe dbspace or all. The senario
is that the server that the IDS was running on is completely gone and
we have to restore a backup from the backupsystem (we use Veritas
NetBackup) to a new server/host running the same IDS version (for time
being 11.50.FC5 64-bits). On this new server I wanted to restore the
db_tables dbspace after creating it with same size. I created the
dbspace and started a ontape -r db_tables using the fullbackup (ontape
-s -L 0) from the old "gone" instance, but it failed with error :
Spaces to restore:1
[db_tables ]
Physical restore failed - DBspace db_tables can not be restored; not
in DBspace table.
A full resore of all the dbspaces failed also with error:
Spaces to restore:1
[db_rootdbs ]
2
[db_loglog ]
3
[db_physlog ]
4
[db_temp ]
5
[db_tables ]
6
[db_indices ]
Physical restore failed -
[db_rootdbs ]
Invalid DBspace list
Program over.
After a bit of research I understod that the dbspaces has to be made
excatly with the not only the same names, but also the dbspace number.
So I reInitialized the rootdbs (it was named something else on the new
server) and all the abow dbspaces in the same order. Still it failes:
-bash-3.00$ ontape -r -D db_tables
Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
Return to continue ...
Archive Tape Information
Tape type: Archive Backup Tape
Online version: IBM Informix Dynamic Server Version 11.50.FC5
Archive date: Tue Feb 23 22:00:29 2010
User id: informix
Terminal id: ?
Archive level: 0
Tape device: /backup/informix/backup_device
Tape blocksize (in k): 64
Tape size (in k): 10000000
Tape number in series: 1
Continue restore? (y/n)y
Spaces to restore:1
[db_tables ]
Physical restore failed - Archived 'db_tables' is a different space
from the
current 'db_tables'. Only physical restores of
existing spaces are allowed.
Program over.
... and a full resore of all dbspaces ...
-bash-3.00$ ontape -r
Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
Return to continue ...
Archive Tape Information
Tape type: Archive Backup Tape
Online version: IBM Informix Dynamic Server Version 11.50.FC5
Archive date: Tue Feb 23 22:00:29 2010
User id: informix
Terminal id: ?
Archive level: 0
Tape device: /backup/informix/backup_device
Tape blocksize (in k): 64
Tape size (in k): 10000000
Tape number in series: 1
Continue restore? (y/n)y
Spaces to restore:1
[db_rootdbs ]
2
[db_loglog ]
3
[db_physlog ]
4
[db_temp ]
5
[db_tables ]
6
[db_indices ]
Physical restore failed -
[db_temp ]
Invalid DBspace list
Program over.
I then ran archecker on the fullbackup device/file (archecker -t -d -v
-s /opt/informix/data/LEVEL_0_backup), and all looked ok.
The difference between old server/instance and the new one is that the
rawdevices used have differnt paths and names, the DBSERVERNAME is
different and of course the hostname.
Does these 3 differences also be the same as the old "gone" host and
IDSinstance or what am I doing wrong?
Regards!
-POW
I got a bit confused. You mention you use NetBackup, but then your commands
use ontape. I assume NetBackup is used for filesystem and ontape for
Informix.
Anyway... The PATHNAMEs of the chunks in a "simple" ontape -r must match.
But if you need to change them you can use the -rename or -f filename
syntax.
Note that in case a server is lost you will need a full cold restore.
Warm restores (with the engine up) can be used for non-critical dbspaces,
but they assume you have a backup of the same server. They'll need logical
restores to bring the system into a consistent state, and they're used to
recover chunks/dbspaces where you had physical disk problems.
Hope this helps.
Regards.
On Fri, Feb 26, 2010 at 3:45 PM, pow43 <faber_38@yahoo.no> wrote:
> Hi,
>
> I have started testing revovery of a singe dbspace or all. The senario
> is that the server that the IDS was running on is completely gone and
> we have to restore a backup from the backupsystem (we use Veritas
> NetBackup) to a new server/host running the same IDS version (for time
> being 11.50.FC5 64-bits). On this new server I wanted to restore the
> db_tables dbspace after creating it with same size. I created the
> dbspace and started a ontape -r db_tables using the fullbackup (ontape
> -s -L 0) from the old "gone" instance, but it failed with error :
>
> Spaces to restore:1
> [db_tables
> ]
> Physical restore failed - DBspace db_tables can not be restored; not
> in DBspace table.
>
> A full resore of all the dbspaces failed also with error:
>
> Spaces to restore:1
> [db_rootdbs
> ]
> 2
> [db_loglog
> ]
> 3
> [db_physlog
> ]
> 4
> [db_temp
> ]
> 5
> [db_tables
> ]
> 6
> [db_indices
> ]
> Physical restore failed -
> [db_rootdbs
> ]
> Invalid DBspace list
>
>
> Program over.
>
> After a bit of research I understod that the dbspaces has to be made
> excatly with the not only the same names, but also the dbspace number.
> So I reInitialized the rootdbs (it was named something else on the new
> server) and all the abow dbspaces in the same order. Still it failes:
>
> -bash-3.00$ ontape -r -D db_tables>
> Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
> Return to continue ...
>
> Archive Tape Information
>
> Tape type: Archive Backup Tape
> Online version: IBM Informix Dynamic Server Version 11.50.FC5
> Archive date: Tue Feb 23 22:00:29 2010
> User id: informix
> Terminal id: ?
> Archive level: 0
> Tape device: /backup/informix/backup_device
> Tape blocksize (in k): 64
> Tape size (in k): 10000000
> Tape number in series: 1
> Continue restore? (y/n)y
>
> Spaces to restore:1
> [db_tables
> ]
> Physical restore failed - Archived 'db_tables' is a different space
> from the
> current 'db_tables'. Only physical restores of
> existing spaces are allowed.
>
>
> Program over.
>
> ... and a full resore of all dbspaces ...
>
> -bash-3.00$ ontape -r>
> Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
> Return to continue ...
>
> Archive Tape Information
>
> Tape type: Archive Backup Tape
> Online version: IBM Informix Dynamic Server Version 11.50.FC5
> Archive date: Tue Feb 23 22:00:29 2010
> User id: informix
> Terminal id: ?
> Archive level: 0
> Tape device: /backup/informix/backup_device
> Tape blocksize (in k): 64
> Tape size (in k): 10000000
> Tape number in series: 1
> Continue restore? (y/n)y
>
> Spaces to restore:1
> [db_rootdbs
> ]
> 2
> [db_loglog
> ]
> 3
> [db_physlog
> ]
> 4
> [db_temp
> ]
> 5
> [db_tables
> ]
> 6
> [db_indices
> ]
> Physical restore failed -
> [db_temp
> ]
> Invalid DBspace list
>
>
> Program over.
>
> I then ran archecker on the fullbackup device/file (archecker -t -d -v
> -s /opt/informix/data/LEVEL_0_backup), and all looked ok.
>
> The difference between old server/instance and the new one is that the
> rawdevices used have differnt paths and names, the DBSERVERNAME is
> different and of course the hostname.
>
> Does these 3 differences also be the same as the old "gone" host and
> IDSinstance or what am I doing wrong?
>
> Regards!
>
> -POW
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
On 26/02/2010 16:07, Fernando Nunes wrote:
> I got a bit confused. You mention you use NetBackup, but then your
> commands use ontape. I assume NetBackup is used for filesystem and
> ontape for Informix.
> Anyway... The PATHNAMEs of the chunks in a "simple" ontape -r must match.
> But if you need to change them you can use the -rename or -f filename
> syntax.
>
> Note that in case a server is lost you will need a full cold restore.
> Warm restores (with the engine up) can be used for non-critical
> dbspaces, but they assume you have a backup of the same server. They'll
> need logical restores to bring the system into a consistent state, and
> they're used to recover chunks/dbspaces where you had physical disk
> problems.
>
> Hope this helps.
> Regards.
>
>
Also, you cannot just plug a dbspace from an instance into another instance
You cannot restore a single dbspace to a new location. You can only restore
a single dbspace to the same existing instance from which it was archived.
You can only restore an entire instance on a new server.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Fri, Feb 26, 2010 at 10:45 AM, pow43 <faber_38@yahoo.no> wrote:
> Hi,
>
> I have started testing revovery of a singe dbspace or all. The senario
> is that the server that the IDS was running on is completely gone and
> we have to restore a backup from the backupsystem (we use Veritas
> NetBackup) to a new server/host running the same IDS version (for time
> being 11.50.FC5 64-bits). On this new server I wanted to restore the
> db_tables dbspace after creating it with same size. I created the
> dbspace and started a ontape -r db_tables using the fullbackup (ontape
> -s -L 0) from the old "gone" instance, but it failed with error :
>
> Spaces to restore:1
> [db_tables
> ]
> Physical restore failed - DBspace db_tables can not be restored; not
> in DBspace table.
>
> A full resore of all the dbspaces failed also with error:
>
> Spaces to restore:1
> [db_rootdbs
> ]
> 2
> [db_loglog
> ]
> 3
> [db_physlog
> ]
> 4
> [db_temp
> ]
> 5
> [db_tables
> ]
> 6
> [db_indices
> ]
> Physical restore failed -
> [db_rootdbs
> ]
> Invalid DBspace list
>
>
> Program over.
>
> After a bit of research I understod that the dbspaces has to be made
> excatly with the not only the same names, but also the dbspace number.
> So I reInitialized the rootdbs (it was named something else on the new
> server) and all the abow dbspaces in the same order. Still it failes:
>
> -bash-3.00$ ontape -r -D db_tables>
> Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
> Return to continue ...
>
> Archive Tape Information
>
> Tape type: Archive Backup Tape
> Online version: IBM Informix Dynamic Server Version 11.50.FC5
> Archive date: Tue Feb 23 22:00:29 2010
> User id: informix
> Terminal id: ?
> Archive level: 0
> Tape device: /backup/informix/backup_device
> Tape blocksize (in k): 64
> Tape size (in k): 10000000
> Tape number in series: 1
> Continue restore? (y/n)y
>
> Spaces to restore:1
> [db_tables
> ]
> Physical restore failed - Archived 'db_tables' is a different space
> from the
> current 'db_tables'. Only physical restores of
> existing spaces are allowed.
>
>
> Program over.
>
> ... and a full resore of all dbspaces ...
>
> -bash-3.00$ ontape -r>
> Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
> Return to continue ...
>
> Archive Tape Information
>
> Tape type: Archive Backup Tape
> Online version: IBM Informix Dynamic Server Version 11.50.FC5
> Archive date: Tue Feb 23 22:00:29 2010
> User id: informix
> Terminal id: ?
> Archive level: 0
> Tape device: /backup/informix/backup_device
> Tape blocksize (in k): 64
> Tape size (in k): 10000000
> Tape number in series: 1
> Continue restore? (y/n)y
>
> Spaces to restore:1
> [db_rootdbs
> ]
> 2
> [db_loglog
> ]
> 3
> [db_physlog
> ]
> 4
> [db_temp
> ]
> 5
> [db_tables
> ]
> 6
> [db_indices
> ]
> Physical restore failed -
> [db_temp
> ]
> Invalid DBspace list
>
>
> Program over.
>
> I then ran archecker on the fullbackup device/file (archecker -t -d -v
> -s /opt/informix/data/LEVEL_0_backup), and all looked ok.
>
> The difference between old server/instance and the new one is that the
> rawdevices used have differnt paths and names, the DBSERVERNAME is
> different and of course the hostname.
>
> Does these 3 differences also be the same as the old "gone" host and
> IDSinstance or what am I doing wrong?
>
> Regards!
>
> -POW
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
On 26 Feb, 19:02, theBP <th...@Usenet-News.Net> wrote:
> On 26/02/2010 16:07, Fernando Nunes wrote:
>
>
>
>
>
> > I got a bit confused. You mention you use NetBackup, but then your
> > commands use ontape. I assume NetBackup is used for filesystem and
> > ontape for Informix.
> > Anyway... The PATHNAMEs of the chunks in a "simple" ontape -r must match.
> > But if you need to change them you can use the -rename or -f filename
> > syntax.
>
> > Note that in case a server is lost you will need a full cold restore.
> > Warm restores (with the engine up) can be used for non-critical
> > dbspaces, but they assume you have a backup of the same server. They'll
> > need logical restores to bring the system into a consistent state, and
> > they're used to recover chunks/dbspaces where you had physical disk
> > problems.
>
> > Hope this helps.
> > Regards.
>
> Also, you cannot just plug a dbspace from an instance into another instance– Skjul sitert tekst –
>
> – Vis sitert tekst –
Hi Fernando,
Sorry the confusion. We use NetBackup for filebackups (in the past we
used ontar against NetBackup) and ontape for Informix backups. I'll
try the rename option. As Art says the new location must use the same
INFORMIXSERVER name as the original.
Thanks!
-Per Otto Westheim
On 26 Feb, 19:26, Art Kagel <art.ka...@gmail.com> wrote:
> You cannot restore a single dbspace to a new location. You can only restore
> a single dbspace to the same existing instance from which it was archived.
> You can only restore an entire instance on a new server.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> IIUG Board of Directors (a...@iiug.org)
>
> See you at the 2010 IIUG Informix Conference
> April 25-28, 2010
> Overland Park (Kansas City), KSwww.iiug.org/conf
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions and
> do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
> organization with which I am associated either explicitly, implicitly, or by
> inference. Neither do those opinions reflect those of other individuals
> affiliated with any entity with which I am affiliated nor those of the
> entities themselves.
>
>
>
> On Fri, Feb 26, 2010 at 10:45 AM, pow43 <faber...@yahoo.no> wrote:
> > Hi,
>
> > I have started testing revovery of a singe dbspace or all. The senario
> > is that the server that the IDS was running on is completely gone and
> > we have to restore a backup from the backupsystem (we use Veritas
> > NetBackup) to a new server/host running the same IDS version (for time
> > being 11.50.FC5 64-bits). On this new server I wanted to restore the
> > db_tables dbspace after creating it with same size. I created the
> > dbspace and started a ontape -r db_tables using the fullbackup (ontape
> > -s -L 0) from the old "gone" instance, but it failed with error :
>
> > Spaces to restore:1
> > [db_tables
> > ]
> > Physical restore failed - DBspace db_tables can not be restored; not
> > in DBspace table.
>
> > A full resore of all the dbspaces failed also with error:
>
> > Spaces to restore:1
> > [db_rootdbs
> > ]
> > 2
> > [db_loglog
> > ]
> > 3
> > [db_physlog
> > ]
> > 4
> > [db_temp
> > ]
> > 5
> > [db_tables
> > ]
> > 6
> > [db_indices
> > ]
> > Physical restore failed -
> > [db_rootdbs
> > ]
> > Invalid DBspace list
>
> > Program over.
>
> > After a bit of research I understod that the dbspaces has to be made
> > excatly with the not only the same names, but also the dbspace number.
> > So I reInitialized the rootdbs (it was named something else on the new
> > server) and all the abow dbspaces in the same order. Still it failes:
>
> > -bash-3.00$ ontape -r -D db_tables>
> > Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
> > Return to continue ...
>
> > Archive Tape Information
>
> > Tape type: Archive Backup Tape
> > Online version: IBM Informix Dynamic Server Version 11.50.FC5
> > Archive date: Tue Feb 23 22:00:29 2010
> > User id: informix
> > Terminal id: ?
> > Archive level: 0
> > Tape device: /backup/informix/backup_device
> > Tape blocksize (in k): 64
> > Tape size (in k): 10000000
> > Tape number in series: 1
> > Continue restore? (y/n)y
>
> > Spaces to restore:1
> > [db_tables
> > ]
> > Physical restore failed - Archived 'db_tables' is a different space
> > from the
> > current 'db_tables'. Only physical restores of
> > existing spaces are allowed.
>
> > Program over.
>
> > ... and a full resore of all dbspaces ...
>
> > -bash-3.00$ ontape -r>
> > Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
> > Return to continue ...
>
> > Archive Tape Information
>
> > Tape type: Archive Backup Tape
> > Online version: IBM Informix Dynamic Server Version 11.50.FC5
> > Archive date: Tue Feb 23 22:00:29 2010
> > User id: informix
> > Terminal id: ?
> > Archive level: 0
> > Tape device: /backup/informix/backup_device
> > Tape blocksize (in k): 64
> > Tape size (in k): 10000000
> > Tape number in series: 1
> > Continue restore? (y/n)y
>
> > Spaces to restore:1
> > [db_rootdbs
> > ]
> > 2
> > [db_loglog
> > ]
> > 3
> > [db_physlog
> > ]
> > 4
> > [db_temp
> > ]
> > 5
> > [db_tables
> > ]
> > 6
> > [db_indices
> > ]
> > Physical restore failed -
> > [db_temp
> > ]
> > Invalid DBspace list
>
> > Program over.
>
> > I then ran archecker on the fullbackup device/file (archecker -t -d -v
> > -s /opt/informix/data/LEVEL_0_backup), and all looked ok.
>
> > The difference between old server/instance and the new one is that the
> > rawdevices used have differnt paths and names, the DBSERVERNAME is
> > different and of course the hostname.
>
> > Does these 3 differences also be the same as the old "gone" host and
> > IDSinstance or what am I doing wrong?
>
> > Regards!
>
> > -POW
> > _______________________________________________
> > Informix-list mailing list
> > Informix-l...@iiug.org
> >http://www.iiug.org/mailman/listinfo/informix-list– Skjul sitert tekst –
>
> – Vis sitert tekst –
Hi Art,
Sounds logical I admit. So ... the INFORMIXSERVER must be the same
(name) and the dbspaces in the same order (dbspacenumber) as the
original instance .. right? What about the size of the dbspaces, can
they be larger than the original or must they have the exact size as
the originals? What about chuncks added to the dbspaces, same story
here with order/number and size?
Thanks!
-Per Otto Westheim
NO! the INFORMIXSERVER name is completely irrelevant. Ok here are the
important points:
- In order to restore a single dbspace other than the ROOTDB space,
called a warm restore, the ROOTDB space must exist.
- If you are restoring a no-ROOTDB dbspace to the same machine/instance,
say after a few chunks' disks failed that belong to that one dbspace (or a
few dbspaces for that matter), then the ROOTDB dbspace is already in place
(assuming that the ROOTDB dbspace's chunks did not fail of course) and you
ONLY have to restore the non-ROOTDB dbspace(s) that you need to restore.
- If, on the other hand, you want to restore just one dbspace to another
machine so that you can, for example, try to extract rows that some fumble
fingered DBA "accidentally" deleted, you CAN do that, but first you have to
perform a cold restore of the ROOTDB dbspace. Once that's accomplished you
can perform a warm restore any other single dbspace(s).
Note that if you intent is to recover deleted data or a dropped table, it is
probably faster to use the archecker utility's ability to extract the
table's data directly from the archive and insert it into any table you want
- the original table or a structural copy of the table you can use to stage
the data and filter it for rows you want to recover.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Sat, Feb 27, 2010 at 1:26 PM, pow43 <faber_38@yahoo.no> wrote:
> On 26 Feb, 19:26, Art Kagel <art.ka...@gmail.com> wrote:
> > You cannot restore a single dbspace to a new location. You can only
> restore
> > a single dbspace to the same existing instance from which it was
> archived.
> > You can only restore an entire instance on a new server.
> >
> > Art
> >
> > Art S. Kagel
> > Advanced DataTools (www.advancedatatools.com)
> > IIUG Board of Directors (a...@iiug.org)
> >
> > See you at the 2010 IIUG Informix Conference
> > April 25-28, 2010
> > Overland Park (Kansas City), KSwww.iiug.org/conf
> >
> > Disclaimer: Please keep in mind that my own opinions are my own opinions
> and
> > do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> other
> > organization with which I am associated either explicitly, implicitly, or
> by
> > inference. Neither do those opinions reflect those of other individuals
> > affiliated with any entity with which I am affiliated nor those of the
> > entities themselves.
> >
> >
> >
> > On Fri, Feb 26, 2010 at 10:45 AM, pow43 <faber...@yahoo.no> wrote:
> > > Hi,
> >
> > > I have started testing revovery of a singe dbspace or all. The senario
> > > is that the server that the IDS was running on is completely gone and
> > > we have to restore a backup from the backupsystem (we use Veritas
> > > NetBackup) to a new server/host running the same IDS version (for time
> > > being 11.50.FC5 64-bits). On this new server I wanted to restore the
> > > db_tables dbspace after creating it with same size. I created the
> > > dbspace and started a ontape -r db_tables using the fullbackup (ontape
> > > -s -L 0) from the old "gone" instance, but it failed with error :
> >
> > > Spaces to restore:1
> > > [db_tables
> > > ]
> > > Physical restore failed - DBspace db_tables can not be restored; not
> > > in DBspace table.
> >
> > > A full resore of all the dbspaces failed also with error:
> >
> > > Spaces to restore:1
> > > [db_rootdbs
> > > ]
> > > 2
> > > [db_loglog
> > > ]
> > > 3
> > > [db_physlog
> > > ]
> > > 4
> > > [db_temp
> > > ]
> > > 5
> > > [db_tables
> > > ]
> > > 6
> > > [db_indices
> > > ]
> > > Physical restore failed -
> > > [db_rootdbs
> > > ]
> > > Invalid DBspace list
> >
> > > Program over.
> >
> > > After a bit of research I understod that the dbspaces has to be made
> > > excatly with the not only the same names, but also the dbspace number.
> > > So I reInitialized the rootdbs (it was named something else on the new
> > > server) and all the abow dbspaces in the same order. Still it failes:
> >
> > > -bash-3.00$ ontape -r -D db_tables> >
> > > Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
> > > Return to continue ...
> >
> > > Archive Tape Information
> >
> > > Tape type: Archive Backup Tape
> > > Online version: IBM Informix Dynamic Server Version 11.50.FC5
> > > Archive date: Tue Feb 23 22:00:29 2010
> > > User id: informix
> > > Terminal id: ?
> > > Archive level: 0
> > > Tape device: /backup/informix/backup_device
> > > Tape blocksize (in k): 64
> > > Tape size (in k): 10000000
> > > Tape number in series: 1
> > > Continue restore? (y/n)y
> >
> > > Spaces to restore:1
> > > [db_tables
> > > ]
> > > Physical restore failed - Archived 'db_tables' is a different space
> > > from the
> > > current 'db_tables'. Only physical restores of
> > > existing spaces are allowed.
> >
> > > Program over.
> >
> > > ... and a full resore of all dbspaces ...
> >
> > > -bash-3.00$ ontape -r> >
> > > Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
> > > Return to continue ...
> >
> > > Archive Tape Information
> >
> > > Tape type: Archive Backup Tape
> > > Online version: IBM Informix Dynamic Server Version 11.50.FC5
> > > Archive date: Tue Feb 23 22:00:29 2010
> > > User id: informix
> > > Terminal id: ?
> > > Archive level: 0
> > > Tape device: /backup/informix/backup_device
> > > Tape blocksize (in k): 64
> > > Tape size (in k): 10000000
> > > Tape number in series: 1
> > > Continue restore? (y/n)y
> >
> > > Spaces to restore:1
> > > [db_rootdbs
> > > ]
> > > 2
> > > [db_loglog
> > > ]
> > > 3
> > > [db_physlog
> > > ]
> > > 4
> > > [db_temp
> > > ]
> > > 5
> > > [db_tables
> > >