I've done it just like that in the past (Unix host lost its root disk) it does work. On 28 Jan 2015 07:07, "Remco Post" <r.p...@plcs.nl> wrote:
> > Op 28 jan. 2015, om 00:25 heeft Andrew Ferris <afer...@mrl.ubc.ca> het > volgende geschreven: > > > > Thanks for the reply Rick. > > > > Pointing the new TSM server at the old db and log files didn't work so > Skylar was correct. Got messages saying that they belonged to another TSM > server. So I will pull back my one DB tape and double check that the server > can talk to our 3584/TS3500 and IBM drives. > > > > I’m convinced that if you replace your ‘new’ DB files by the old ones and > remove this one line that doesn’t contain a path to a file from the > dsmserv.dsk that you should be fine. > > > Andrew > > > > > >>>> Rick Adamson <rickadam...@biloholdings.com> 1/27/2015 11:32 AM >>> > > Andrew, > > Been there, done that. > > Here's how I handled it: > > > > -Get the server operational. Like others have said it is advantageous to > have several files from the TSM instance directory (volhist, devconfig, and > optionally dsmserv.opt). On 5.x it is possible to recover without them, but > the situation gets a bit more complicated. > > - Assure the system has access to the tape library, (real or virtual), > and update the devconfig file to reflect any changes needed. > > - Install the TSM server software and perform a minimal configuration. > This can be done via the management console wizards. > > - Place/replace the volhist, devconfig, and dsmserv files in the > instance directory. > > - Use the "dsmserv restore db" command to restore the latest data base > copy. (If the library is physical tape you may have to manually load the > tapes as requested.) > > - Bring the TSM Server online and inspect for proper operation. > > -Unless you determine it is needed I would forego the volume auditing, > the time it takes per volume to complete is extensive. Be critically > selective here. > > > > If you perform a point-in-time database restore (versus a roll forward) > I strongly recommend that once the server is up you review the original > volhist file and resolve any potential issues, such as volumes > created/deleted in between the time of the database backup used for the > restore and the time the server crashed. > > > > > > Rick Adamson > > Jacksonville,Fl. > > > > > > -----Original Message----- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > Of Andrew Ferris > > Sent: Tuesday, January 27, 2015 12:16 PM > > To: ADSM-L@VM.MARIST.EDU > > Subject: [ADSM-L] basic DR questions > > > > Hello ADSM-ers, > > > > Our ancient 5.5 (EOL I know) TSM server on windows just corrupted it's > C: drive (so OS + Server Program Files) but everything else is fine - the > diskpools, the logs, the db files, the library, etc. I even have copies of > dsmserv.opt, devconfig.out, and volhist.out. I have a plan file but I would > prefer to pull back as few tapes as possible from offsite. > > > > What would be the quickest way to restore TSM given the large amount of > non-destroyed material I have? > > > > Sorry my DRM skills are so rusty. > > > > thanks, > > Andrew Ferris > > Network & System Management > > UBC Centre for Heart & Lung Innovation > > St. Paul's Hospital, Vancouver > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.hli.ubc.ca&d=AwIFAg&c=AzgFQeXLLKhxSQaoFCm29A&r=eqh5PzQPIsPArLoI_uV1mKvhIpcNP1MsClDPSJjFfxw&m=tOvkkg88gL_qIi-t-hizMiMh4elw6_Vx6ZomA3sqQE8&s=bYWNR0zk8MR7W8DusALKHG319cUGFjDFjE_IVZx0rQE&e= > > -- > > Met vriendelijke groeten/Kind Regards, > > Remco Post > r.p...@plcs.nl > +31 6 248 21 622 >
