![]() | |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
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 (AT) iiug (DOT) org http://www.iiug.org/mailman/listinfo/informix-list |
#3
| |||
| |||
|
|
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. |
#4
| |||
| |||
|
|
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 (AT) iiug (DOT) org http://www.iiug.org/mailman/listinfo/informix-list |
#5
| |||
| |||
|
|
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 – |
#6
| |||
| |||
|
|
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... (AT) iiug (DOT) 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, orby 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... (AT) yahoo (DOT) 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... (AT) iiug (DOT) org http://www.iiug.org/mailman/listinfo/informix-list– Skjul sitert tekst– – Vis sitert tekst – |
#7
| |||
| |||
|
|
On 26 Feb, 19:26, Art Kagel <art.ka... (AT) gmail (DOT) 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... (AT) iiug (DOT) 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... (AT) yahoo (DOT) 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... (AT) iiug (DOT) 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 _______________________________________________ Informix-list mailing list Informix-list (AT) iiug (DOT) org http://www.iiug.org/mailman/listinfo/informix-list |
#8
| |||
| |||
|
|
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 thatsome fumble fingered DBA "accidentally" deleted, you CAN do that, but firstyou 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 (AT) iiug (DOT) 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 (AT) yahoo (DOT) no> wrote: On 26 Feb, 19:26, Art Kagel <art.ka... (AT) gmail (DOT) 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... (AT) iiug (DOT) 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... (AT) yahoo (DOT) 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... (AT) iiug (DOT) 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 _______________________________________________ Informix-list mailing list Informix-list (AT) iiug (DOT) org http://www.iiug.org/mailman/listinfo/informix-list |
#9
| |||
| |||
|
|
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, itis 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 (a... (AT) iiug (DOT) 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, orby 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... (AT) yahoo (DOT) no> wrote: On 26 Feb, 19:26, Art Kagel <art.ka... (AT) gmail (DOT) 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... (AT) iiug (DOT) 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... (AT) yahoo (DOT) 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... (AT) iiug (DOT) org http://www.iiug.org/mailman/listinfo...mix-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 _______________________________________________ Informix-list mailing list Informix-l... (AT) iiug (DOT) org http://www.iiug.org/mailman/listinfo/informix-list– Skjul sitert tekst– – Vis sitert tekst – |
#10
| |||
| |||
|
|
Hi Art/Fernando, I have now tried som recovery attempts both warm restore of one dbspace and a could one with all dbspaces inc. rootdbs. I also have tried the rename option, but it have failed every time. Do you see what I'm doeing wrong?: WARM RESTORE: snip |
![]() |
| Thread Tools | |
| Display Modes | |
| |