Cannot restore after Veritas Netbackup restores

[africantract]

Hi There, We have an issue on our db2 restores. We do database dumps
every night, and restore them to development servers every morning.
This works fine with no errors. However if we backup those images to
tape using Veritas netbackup, and then restore those images and try to
restore them to the database, we get "The backup image is corrupt". If
we run db2ckbkp against that image we get "Unable to decompress image
from different platform".

This is really urgent as our backups are currently useless to us if we
cannot restore them properly. If anyone has even a small amount of
information on how to solve this problem, we would be very grateful.

Thanks

[Ian]

af**********@gmail.com wrote:

Hi There, We have an issue on our db2 restores. We do database dumps
every night, and restore them to development servers every morning.
This works fine with no errors. However if we backup those images to
tape using Veritas netbackup, and then restore those images and try to
restore them to the database, we get "The backup image is corrupt". If
we run db2ckbkp against that image we get "Unable to decompress image
from different platform".

Need a lot more information.

1) DB2 Level, Operating System and level on source system
2) DB2 Level, Operating System and level on target system
3) Specific command you use to back up the database to NetBackup
4) Specific command you use to try and restore database (as well as
db2ckbkp command)

[africantract]

Thanks Ian

1) The Source OS is Sun Solaris 9, level is
DB21085I Instance "prdinst1" uses "64" bits and DB2 code release
"SQL08023"
with level identifier "03040106".
Informational tokens are "DB2 v8.1.0.96", "s050811", "U803921", and
FixPak
"10".
Product is installed at "/opt/IBM/db2/V8.1".

2) The Destination OS is Sun Solaris 9, level is
DB21085I Instance "stginst1" uses "64" bits and DB2 code release
"SQL08023"
with level identifier "03040106".
Informational tokens are "DB2 v8.1.0.96", "s050811", "U803921", and
FixPak
"10".
Product is installed at "/opt/IBM/db2/V8.1".

3) Our backups are outsourced so I am not sure of the command used to
perform the backup. I do know that they image it to Hard Disk and then
take it to tape. I will ask the guys what the command is that they use.

4)Here is an extract from the logs

RESTORE DATABASE prdagm01 FROM /spare/backups/stginst1/daily/stgagmst
TAKEN AT 20060822180001 TO /db2/stginst1 INTO stgAGMst WITH 2 BUFFERS
BUFFER 2048 REDIRECT PARALLELISM 16 WITHOUT PROMPTING
SQL1277N Restore has detected that one or more table space containers
are
inaccessible, or has set their state to 'storage must be defined'.
DB20000I The RESTORE DATABASE command completed successfully.

SET TABLESPACE CONTAINERS FOR 0 IGNORE ROLLFORWARD CONTAINER OPERATIONS
USING (PATH /db2/stgagmst/SYSCATSPACE)
DB20000I The SET TABLESPACE CONTAINERS command completed successfully.

<snipped various other tablespace commands same as above for other
tablespaces>

RESTORE DATABASE prdagm01 CONTINUE
SQL2054N The backup or copy image is corrupted.

Here is the db2ckbkp command with output

db2ckbkp -a
/spare/backups/stginst1/daily/stgagmst/PRDAGM01.0.prdinst1.NODE0000.CATN0000.200608221800 01.001

=====================
MEDIA HEADER REACHED:
=====================
Server Database Name -- PRDAGM01
Server Database Alias -- PRDAGM01
Client Database Alias -- PRDAGM01
Timestamp -- 20060822180001
Database Partition Number -- 0
Instance -- prdinst1
Sequence Number -- 1
Release ID -- A00
Database Seed -- 5024EA4A
DB Comment's Codepage (Volume) -- 0
DB Comment (Volume) --

DB Comment's Codepage (System) -- 0
DB Comment (System) --

Authentication Value -- -1
Backup Mode -- 1
Includes Logs -- 0
Compression -- 1
Backup Type -- 0
Backup Gran. -- 0
Status Flags -- 20
System Cats inc -- 1
Catalog Partition Number -- 0
DB Codeset -- ISO8859-1
DB Territory --
LogID -- 1156260632
LogPath --
/db2/prdinst1/prdinst1/NODE0000/SQL00003/SQLOGDIR/
Backup Buffer Size -- 4194304
Number of Sessions -- 1
Platform -- 15

The proper image file name would be:
PRDAGM01.0.prdinst1.NODE0000.CATN0000.200608221800 01.001


==================
BUFFER 0
==================
BufAddr PoolID Token Type Offset FileSize ObjectSize OrigSize
Object Name
-------- ------ ----- ---- ---------- ---------- ---------- ----------
-----------
00000000: 0 0 19 0 12 12 0
"BACKUP.START.RECORD.MARKER"
extNum: 40161
extCID: 1156257821 44eb181d
prevCID: 1156257041 44eb1511

BufAddr PoolID Token Type Offset FileSize ObjectSize OrigSize
Object Name
-------- ------ ----- ---- ---------- ---------- ---------- ----------
-----------
0000020C: 0 0 27 0 15552 15552 0
"libdb2compr.so"
WARNING: Unable to decompress image from different platform.

Thanks

Ian wrote:

af**********@gmail.com wrote:

Hi There, We have an issue on our db2 restores. We do database dumps
every night, and restore them to development servers every morning.
This works fine with no errors. However if we backup those images to
tape using Veritas netbackup, and then restore those images and try to
restore them to the database, we get "The backup image is corrupt". If
we run db2ckbkp against that image we get "Unable to decompress image
from different platform".

Need a lot more information.

1) DB2 Level, Operating System and level on source system
2) DB2 Level, Operating System and level on target system
3) Specific command you use to back up the database to NetBackup
4) Specific command you use to try and restore database (as well as
db2ckbkp command)

[Ian]

Veritas doesn't really enter into the equation since it sounds like
you're backing DB2 up to disk and then letting the "normal" file
system backups take the image off to tape.

Both servers are Solaris 9, but are they both SPARC machines? It
it possible that one is an Opteron (i.e. Solaris x86-64), but the
other is SPARC?

[africantract]

Hi Ian,
Both machines are Fujitsu servers with SPARC processors. I made a
listake on the OS it's actually Solaris 8. What I also forgot to
mention is that we take a DB dump then restore that dump to another
server every morning. That same dump file goes to tape then comes back
to us in an unuseable state.
You pose an interesting question, Maybe the Backup server is an x86
machine running Solaris. In this case it might slightly modify the
compression algorithm. I am seeing the backup guys today and ask them
that question.

Thanks

Ian wrote:

Veritas doesn't really enter into the equation since it sounds like
you're backing DB2 up to disk and then letting the "normal" file
system backups take the image off to tape.

Both servers are Solaris 9, but are they both SPARC machines? It
it possible that one is an Opteron (i.e. Solaris x86-64), but the
other is SPARC?