As I said there are two ways to look at it. For full DR we all back up so that
if a site disaster were to happen we could keep the business running. If the
hot site were to be the one destroyed then you do need a plan because the next
backup will need to go somewhere. Remember the primary copy of everything
wasn't at the hotsite so the business is still running. If you truly have
legal or other requirements that dictate you need not only the primary copy of
data but also a backup copy at two locations then Wanda's idea of having two
libraries one at each location would be the best bet I think.
Sometimes you also have database servers that need to dump their logs every
hour. If the hot site were to go away then you might not be able to wait until
a new site or server is built. For this reason part of your plan may be to have
a 2nd TSM server sitting at your primary site. You could be running export
nodes filed=all to keep the node definition and password in sync. Then when a
disaster hits you just rename the instance to that of the one at the hot site
(instance not computer name). Then change the DNS alias for the hot site to
point to the local TSM server. Of course you have to create any schedules but
that can be scripted easy enough. The servers will just start backing up to
the new location.
End the end no matter what design you pick you have to make sure to dot your
"i's" and cross your "t's".
Roger Deschner <rogerd AT UIC DOT EDU> wrote:
Don't forget to consider the possibility that your disaster could happen
the other way around - the swarms of locusts may consume your hotsite,
leaving only your "primary site" functional. If the only copy of the
data is over there, you're in the same boat, up the same creek, without
the same paddle, as before you started all this DR planning.
OTOH, if you aren't doing archives, and if none of the systems being
backed up to TSM are at the hotsite, the "offsite backup" could be
considered to be the original client node machines back at the primary
site.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
======I have not lost my mind -- it is backed up on tape somewhere.=====
On Wed, 28 Jul 2004, TSM_User wrote:
>Just a different thought why not back everything up to the a TSM server at the
>DR hotsite. You should easily be able to backup 1.5 TB's of information in a
>night though a 1 Gb connection. If this is new Fibre then you may have a 2 Gb
>connection or more through DWDM (or what ever that acronym is).
>
>At the DR hotsite you don't need to make storage pool copies unless you want
>to protect yourself from media issues.
>
>IP slowing you down, well IP definitely has more overhead than SCSI but today
>you should be able to get at least 250 GB/hr though a 1 Gb NIC worse case. So
>if your backup window is from 8:00 PM to 6:00 AM you can send 2.5 TB's of
>information again assuming you are just running a 1 Gb Fibre connection.
>
>So no vaulting and no need for storage pool copies.
>
>I would also put a bunch of ATA disk at the other site as well and keep all
>small files on disk. This will also reduce the need for tapes and drives. Your
>local server could be used for fail over in case the link goes down.
>
>Don't flame me, this is just another idea. I'm sure there are many people out
>there who can't believe I would suggest not running storage pool copies even
>if the primary copy is offsite but we are looking at this approach ourselves.
>
>"Prather, Wanda" wrote:
>I would recommend using the second server only in the event of a disaster.
>
>Since you are connected by fibre, the primary server can send the data
>directly to the tape drives in the library at fibre speeds.
>
>You don't want to try and make the 2 servers talk to each other via
>server-to-server communications, 'cause that will just slow you down to
>TCP/IP speeds.
>
>-----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
>Thach, Kevin G
>Sent: Wednesday, July 28, 2004 9:39 AM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Infrastructure design questions -- I need input please
>
>
>My organization is developing a DR "hotsite" at one of our other
>facilities across town, and we are considering making some radical
>changes to our TSM environment. I know there are several folks on this
>list that are heavy into TSM "design" and I could use all the input I
>can get.
>
>Our current environment consists of the following:
>* TSM server running 5.1.7.3 on AIX. The server is a 6-processor
>6H1 w/ 8GB RAM and four 2Gb HBAs.
>* Approximately 350 clients, and backup 1.5 TB nightly
>* We use a SAN-attached 3584 with 12 LTO-1 tape drives. 60-day
>retention policy for everything, so we are maintaining ~90 TB in our
>local and offsite (copypool) tape pools.
>* Disk storage pools, DB, Log, are all on SAN-attached IBM Shark
>disk
>
>Our objective is to take advantage of the hotsite not only to improve
>our DR methods, but to improve TSM restore times. This is what we're
>considering:
>
>* Purchasing approximately 120-140 TB worth of SATA disk, which
>will live at our current site. All backup data will be retained on disk
>which should improve restore performance.
>* Move the tape library to the hotsite, and install a second TSM
>server there as well. We would no longer create two tape copies of our
>data, but we would create a single tape copy across town.
>* The two sites will be connected by dark fiber, so the speed at
>which we can deliver the data to the 3584 should not be a problem.
>
>Is anyone doing something similar to this? Are there any major flaws
>that I'm not considering? Any advice and input is appreciated.
>
>Also, I realize I need to go back and brush up on my TSM manuals, but
>since I don't run a two-TSM server environment, I have forgotten exactly
>how that will work in the kind of situation I describe. Would I only
>use the secondary server in the event of a disaster on the primary? Or
>would the secondary server at the hotsite manage the library? Etc? If
>someone can point me in the right direction on that aspect, I'd
>appreciate it.
>
>Thanks in advance,
>Kevin
>
>
>---------------------------------
>Do you Yahoo!?
>Yahoo! Mail - 50x more storage than other providers!
>
---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
|
