Try 'q nodedata '
Jim Schneider
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Geoff
Gill
Sent: Friday, July 06, 2012 3:58 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] DR restore question
Hi Everyone,
I have a question about DR testing as
Eric,
Should have been update stg access=destroyed rather than unavailable. That's
one thing.
Why isn't the client seeing the TSM server at the new IP? H. The client
is pointing at the new source server, not the target, correct? The new
source/target combo may require updating as well
What if your DR PREPARE is generated using virtual volumes as its target?
- Original Message -
From: "William Boyer" <[EMAIL PROTECTED]>
To:
Sent: Thursday, September 27, 2007 9:16 AM
Subject: Re: [ADSM-L] DR restore of a virtual volume
You would rebuild the ServerA instance with a bla
Hi,
In case of the password being out-of-sync you need to do an update
server ServerA forcesync=yes on ServerB.
Regards,
Karel
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Nicholas Cassimatis
Sent: donderdag 27 september 2007 15:18
To: ADSM-L@
Thanks. I would have thought there would be a simpler way to retrieve it on
the target server.
- Original Message -
From: "William Boyer" <[EMAIL PROTECTED]>
To:
Sent: Thursday, September 27, 2007 9:16 AM
Subject: Re: [ADSM-L] DR restore of a virtual volume
You would rebuild the Server
Hi,
Issue command prepare and see in the output file the correct command.
All commands and steps for recovery your ITSM server should be in their.
Works only before the crash... ;-)
Regards,
Karel
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
La
You would rebuild the ServerA instance with a blank database of the same size
or larger as what ServerA had originally. Then you
would define the server-to-server communication to ServerB. Once that's done,
shutdown ServerA. All the configuration information is
now in the DEVCONFIG file(s). Now y
Hello,
The slot # seems high for 3583.. not sure if this is normal for Windows..
Have you double checked the correct slot # for the database tape.
Also I would check from OS that you can query the smc0 device and tape
drive devices.
Sung Y. Lee
"ADSM: Dist Stor Manager" wrote on 02/14/2005
0
>We just had a disaster recovery drill recently and the issue of slow
>restores/retrieves was brought up. It seems that there are so many tape
>mounts because the offsite copy storage pools aren't collocated since we
>send these tapes offsite every morning at 8AM. To collocate would be a
>waste o
On Mon, 14 Jul 2003 09:47:21 -0400
Joni Moyer <[EMAIL PROTECTED]> wrote:
> Hello everyone,
>
> We just had a disaster recovery drill recently and the issue of slow
> restores/retrieves was brought up. It seems that there are so many tape
> mounts because the offsite copy storage pools aren't coll
10 matches
Mail list logo
