ADSM-L

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

2012-02-21 10:22:28
Subject: Re: [ADSM-L] Server DB restore from offsite TSM server SNAPSHOT
From: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 21 Feb 2012 10:13:49 -0500
Karel,

Thanks for the idea.

This would be fine/work if I was actually restoring/replacing a production
server.  I am only trying to restore the DB to a test server.  If I did
the "sync" from SERVER-B, it would sync the wrong, production, running
server,  not the test machine I am trying to restore the DB to,  which has
a different IP address than the production machine.


Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html



From:   "Bos, Karel" <Karel.Bos AT ATOS DOT NET>
To:     ADSM-L AT VM.MARIST DOT EDU
Date:   02/21/2012 10:07 AM
Subject:        Re: [ADSM-L] Server DB restore from offsite TSM server
SNAPSHOT
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



Hi,

>From memory one should do the upd server force sync=yes on the target
machine.

In this case ON server-B do upd server server-a forcesync=yes.

After restore of the DB server-server comm will be down again because
out-of-sync issues.

Regards,

Karel

-----Oorspronkelijk bericht-----
Van: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Namens Zoltan
Forray/AC/VCU
Verzonden: dinsdag 21 februari 2012 15:45
Aan: ADSM-L AT VM.MARIST DOT EDU
Onderwerp: [ADSM-L] Server DB restore from offsite TSM server SNAPSHOT

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.....


Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html






Dit bericht is vertrouwelijk en kan geheime informatie bevatten enkel
bestemd voor de geadresseerde. Indien dit bericht niet voor u is bestemd,
verzoeken wij u dit onmiddellijk aan ons te melden en het bericht te
vernietigen. Aangezien de integriteit van het bericht niet veilig gesteld
is middels verzending via internet, kan Atos Nederland B.V. niet
aansprakelijk worden gehouden voor de inhoud daarvan. Hoewel wij ons
inspannen een virusvrij netwerk te hanteren, geven wij geen enkele
garantie dat dit bericht virusvrij is, noch aanvaarden wij enige
aansprakelijkheid voor de mogelijke aanwezigheid van een virus in dit
bericht. Op al onze rechtsverhoudingen, aanbiedingen en overeenkomsten
waaronder Atos Nederland B.V. goederen en/of diensten levert zijn met
uitsluiting van alle andere voorwaarden de Leveringsvoorwaarden van Atos
Nederland B.V. van toepassing. Deze worden u op aanvraag direct kosteloos
toegezonden.

This e-mail and the documents attached are confidential and intended
solely for the addressee; it may also be privileged. If you receive this
e-mail in error, please notify the sender immediately and destroy it. As
its integrity cannot be secured on the Internet, the Atos Nederland B.V.
group liability cannot be triggered for the message content. Although the
sender endeavours to maintain a computer virus-free network, the sender
does not warrant that this transmission is virus-free and will not be
liable for any damages resulting from any virus transmitted. On all offers
and agreements under which Atos Nederland B.V. supplies goods and/or
services of whatever nature, the Terms of Delivery from Atos Nederland
B.V. exclusively apply. The Terms of Delivery shall be promptly submitted
to you on your request.

Atos Nederland B.V. / Utrecht
KvK Utrecht 30132762