ADSM-L

Re: [ADSM-L] Server DB restore from offsite TSM server SNAPSHOT

2012-02-21 14:47:59
Subject: Re: [ADSM-L] Server DB restore from offsite TSM server SNAPSHOT
From: Xav Paice <xpaice AT OSS.CO DOT NZ>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 22 Feb 2012 08:40:25 +1300
On Tue, 2012-02-21 at 09:44 -0500, Zoltan Forray/AC/VCU wrote:

> I am trying to experiment with doing a V5 to V6 conversion by first
> restoring the V5 server to a test server.
>
> We have very little experience doing DB restores and none involving an
> offsite TSM server.  My first attempts failed.  I think I know how to fix
> it but the docs on how to perform a DB restore are a little contradictory
> to what I want to do.
>
> SERVER-A performs DB SNAPSHOT backups to SERVER-B via server-to-server
> definitions.
>
> Installed a same-level TSM server onto a test machine.
> Did "dsmserv format" to prepare DB space to the equivalent of  SERVER-A.
> Replaced the test server volhist, devconfig and dsmserv.opt files from
> copies of SERVER-A like-files.
>
> Tried to do a "dsmserv restore db volumenames=name.I.got.from.volhist
> devclass=SERVER-B"
>
> Since I tried this over a month ago, I don't recall the error but I think
> it has to do with the server-to-server definition being out of sync since
> this is not the original SERVER-A.
>
> My guess is to bring up the test server and manually do a "UPDATE SERVER
> SERVER-B FORCESYNCE=YES"
>
> However, when I go through the book scenarios on restoring a server DB, it
> says:
>
> "Attention: Do not start the server until after you restore the database
> (the next step). Starting the server before the restore would destroy any
> existing volume history files."
>
> So, how do I do this?  Do I bring up the test server first and correct the
> sync before replacing the volhist file?
>
> Am I wrong in how I  am trying to do this?  Is there a better/different
> way to do this?
>
> Looking for any suggestions/hints.....


A simple suggestion maybe, to try a different track and reduce the risk
of breaking server to server communications on your production
machines....  Since you're restoring to a test server rather than
recovering the prod one, how about you make a new, temporary, device
class of type FILE and store that somewhere both the prod and test
servers can access (NFS?).  Then make a dbsnapshot backup to the new
device class, backup volhist, and recover the test machine from the
temporary device class.  It's probably stating the obvious but you
probably don't want to have your test machine break the server to server
comms with the production machine.

<Prev in Thread] Current Thread [Next in Thread>