Daniel / Bill,
I do appreciate you both taking the time to share your expert opinion.
My scenario is correctly represented by Bill's response: I don't want to create
copy (COPYPOOL) of the primary tapes (TAPEPOOL).
My daily backups, for both sites, are currently occurring centrally at one
site. This totals to less than 100G a day. My plan is to split and reciprocally
backup each site to the other as I indicated in my original email. My restore
time would not be worse than it is now even during business hours, considering
that I already restore from one central location today. In case of DR at one
site, I am assuming that, disaster, site is out of the picture, and therefore
the restores are going to be local to the DR servers at the other, recovery,
site.
I wanted to confirm whether my idea is NOT out of the ordinary or against the
best practices and you both helped a great deal towards that.
Thanks again to both of you!
Khalid Khan
-----Original Message---
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Daniel Sparrman
Sent: Tuesday, November 11, 2003 10:06 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Server-Server DRM Configuration ...
Hi
Well, had some problems figuring out exactly what they wanted to do... :)
I dont know how large this installation is, but sending > 100 clients over
a 45Mbs link suggests to me that rebuilding one site after a total
disaster will probably take more than a few days...
However, if Khalids installation is small(counting less than 100 clients,
and a total amount of data at 5-10TB) perhaps this method could be used.
Also, as I understand it from Khalids description, hes not going to
utilize dr copies(or, copypool volumes), as he considers the data to be
off-site. However, normally, the TSM server contains alot of data that is
no longer on the host system(archives, HSM data, versioning and so on).
Therefore, loosing the TSM server and it's data, without having copypool
volumes offsite, could cost you alot in terms of lost data...
I'd suggest either getting a FC connection between the two sites and
utilize library sharing, or partitioning. Or, consider using iSCSI or FC
over IP to copy the data to the remote library. iSCSI and FC over IP is
alot faster and more tuned in handling theese kind of data transfers than
IP is...
Best Regards
Daniel Sparrman
-----------------------------------
Daniel Sparrman
Exist i Stockholm AB
Propellervägen 6B
183 62 TÄBY
Växel: 08 - 754 98 00
Mobil: 070 - 399 27 51
Bill Boyer <bill.boyer AT VERIZON DOT NET>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
2003-11-11 16:55
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: Server-Server DRM Configuration ...
It doesn't sound like they are talking about the same thing. The
consultant
sounds like he wants to backup SITE-A servers to the local TSM and then
send
the copypool over to the other server via virtual volumes. Khalid wants to
backup SITE-A servers over the link directly to SITE-B TSM server. That
way
when the backup is complete, the backup data is offsite to the original
server. If either site goes down, you'll still be rebuilding a TSM server,
but the clients can immediately start recovery because the data is on the
TSM server at the other site.
I've recently set up this configuration for a client. Each TSM server
creates copypool tapes that also go offsite (more for redundancy), but I
also have each server do a DBSnapshot across server-to-server in addition
to
the DBBackup that goes offsite. Lots of redundancy....it's a government
agency!
The only issue is the recoveries or just restores going across that link
during business hours.
Bill Boyer
DSS, Inc.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Daniel Sparrman
Sent: Tuesday, November 11, 2003 10:39 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Server-Server DRM Configuration ...
Hi Khalid
You and you're consultant are talking about the same procedure....
To backup your primary site to the second site, you'll need to use
server-to-server virtual volumes(if you cant get a FC connection to your
library on your secondary site). You then define a devclass and a copypool
based on that devclass. After that, you'll just have to start the process
of backup stgpool primarypool copypool.
I cant see any other way of backing up the two servers to eachother rather
than using server-to-server communication. This method is also called
"Electronic Vaulting" and is a part of TSM Disaster Recovery Manager. You
cannot use any form of TSM backup/archive client procedure to backup the
server data, as the client wont have access to the information stored on
your tapes.
Best Regards
Daniel Sparrman
-----------------------------------
Daniel Sparrman
Exist i Stockholm AB
Propellervdgen 6B
183 62 TDBY
Vdxel: 08 - 754 98 00
Mobil: 070 - 399 27 51
"Khan, Khalid B." <kkhan AT ATCLLC DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
2003-11-11 16:16
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Server-Server DRM Configuration ...
I have a humble question regarding the benefits of Server-Server
communication. I have two sites 60 miles apart with 45MB pipe in between,
and each of them has a TSM server and a library. I was proposed by a TSM
consultant to establish server-server DRM configuration to enable quick
recovery in case of disaster. My humble proposal in response is to NOT do
that but rather backup each site to the other location. That way the DB is
offsite as well as the primary copy, therefore DR copy of the primary is
NOT needed either. I would do this reciprocally for the other site. In
case of DR, data is locally available at the other site.
Is this not a better solution than configuring server-server communication
and send a copy of the primary pool as well as the DB tape offsite.
Please help me understand what I may be missing in my proposal, or what
benefits I don't see in the traditional DRM using Server-Server
configuration.
Please advise!
Thank you,
Khalid Khan
|
