Recover DB after complete rebuild

[mshulman1980]

Does anyone have any advice on restoring a database from tape onto a new system?



My organization has experienced a cataclysmic crash. Pretty much everything you can think of has happened to this sever, and we ended up rebuilding it from the ground up --

Currently running AIX 5.3ML3 on an IBM P series 9111-520.

Installed TSM Server 5.2.2 and patched it to 5.2.8.



The problem is that all of our data -- including the recovery plan and the volume groups themselves were completely destroyed. What we're left with is our tape library.

I had no way to even approximate what was in place before -- the people who implemented the TSM environment are long gone and we have NO documentation.

I'm trying to restore our DB to what is essentially a brand new system from tape. I've recreated all of the volume groups from scratch.

I tried going through each tape in the library with the command:

dsmserv restore db devclass=ltoclass volume=AXXXXX commit=yes (where X is the tape that I just loaded into DRIVE 1). the results I'm interested in (I suspect DB Backups) were:

ANR9999D icrest.c(2091): ThreadId<0> Rc=30 reading header record.

Callchain of

previous message: 0x0000000100017e90 outDiagf <- 0x00000001004d0cec ReadHeader

<- 0x00000001004d1cac IcRestoreDbData <- 0x00000001004ce678 icRestoreOneImageC opy <- 0x00000001004c2344 AdmRestoreDb <- 0x00000001002314c4 admRestoreDatabase

<- 0x0000000100004cc8 RestoreDb <- 0x0000000100002b3c main <- ANR2032E RESTORE DB: Command failed - internal server error detected.

ANR8468I LTO volume A00006 dismounted from drive DRIVE1 (/dev/rmt3) in library 3584.



Further analysis from the command:

dsmserv display dbbackupvolume devclass=ltoclass vol=AXXXXX

ANR4444W DSMSERV DISPLAY DBBACKUPVOLUME: Input volume A00006 cannot be

processed.



on the plus(?) side, it did completely screw up our existing empty database from the base TSM install. I suspect it be failing to restore the DB because it's essentially going into a completely new system.



Does anyone have any advice on how to do this?

 

[sgabriel62]

Q1: Are there tapes coming and going off-site?

Q2: Is there an FTP session via cron or a script in place that you know of?

Q3: Are the volser ranges of the library different in any sort of way where you might be able to distinguish a clue to what the DB volumes would be?

Q4: Has the UNIX team created an image of the TSM server before it crashed? Is so - you may be in luck because I would expect the old TSM admins used default settings on devconfig and volhistory.



Best of Luck to you - let us know ASAP



Steven

 

[chad_small]

First off ALWAYS send the volhist in e-mail daily to multiple mailboxes. Why? So it's retrievable by mulitple people. This also keeps a system failure from wiping out the only file that can help you bring the server back up. Did the previous admins send anything to an email box? Were tapes being sent off daily? If so it might be easier to find a db backup if you work with the offsite people and use the last known list of tapes sent offsite since one of them is likely a DB backup or Snapshot. Also the way I have done it when I lose a system to a RAID failure (happened to me more than once due to inattentive System Admins) was to reinstall TSM, initialize TSM (start it up), create all the devices, then bring it down and commence restoration. The key is that the DB must be same size of bigger. Other than finding a good DBBackup or volhist your out of luck.