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.post AT plcs DOT nl> wrote:
> > Op 28 jan. 2015, om 00:25 heeft Andrew Ferris <AFerris AT MRL.UBC DOT 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 <RickAdamson AT BILOHOLDINGS DOT 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 AT VM.MARIST DOT EDU] On Behalf
> Of Andrew Ferris
> > Sent: Tuesday, January 27, 2015 12:16 PM
> > To: ADSM-L AT VM.MARIST DOT 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.post AT plcs DOT nl
> +31 6 248 21 622
>
|
