Re: Collocation and Disaster Recovery

I'd love to collocate my copy pools.  It's unfortunate that it doesn't
work.  Consider why you can't really use collocation in any useful way
in a storage pool where you take tapes offsite:

To pick a simple, but reasonable, case, let's say you have 100 nodes
being backed up; each node's data can fit on one tape; and the nightly
backup traffic will fit on three tapes.

How many tapes do you take offsite, each day, if your copy pool ...
  A) is not collocated:  three (3)
  B) is collocated:  one hundred (100)

The reason collocation can work is that ADSM can keep appending more
data to tapes that are partially full.  If you take the tapes offsite,
then it can't do that, so it'll make a new batch of sparsely populated
tapes.  Thus, collocating the offsite pools is fundamentally useless.

I guess it wouldn't be disastrous as it sounds at first; true, you'd be
taking 100 tapes offsite each day, and it seems like you'd have one tape
for eacy day, forever.  But with ADSM's offsite copy pool reclamation,
you could limit the number of tapes each node would occupy to a sane
number (say, 10).  Still, it seems awful that you'd be moving around so
many tapes.  I can just see myself trying to pitch this to a client,
explaining "ADSM will save you time, and money, and bring you to
automation paradise!  Now, since you have 500 nodes that we're backing
up, we just have to move 500 tapes each day!"  Yeah, right!  :-)

Kelly, am I correct in understand what you are suggesting?  To go with
the simple example above, let's say only 10 have strict recovery time
requirements, and the other 90 don't matter; so put 90 of them in a
non-collocated pool, and 10 in a collocated pool?  This answer is
unsatisfying, since it amounts to "it can't be done, so the best you can
do is to micro-manage storage pools to kind of fake it."  What if all
100 have strict recovery requirements?

So the question still stands ... how do you make sure you have a
collocated storage pool (primary or copy, I don't care) available if
your primary pools are lost in a disaster?

--
John Dawson <jdawson AT tkg DOT com>
John Dawson <jdawson AT tkg DOT com>

On Sat, 13 Jun 1998, Automatic digest processor wrote:
> Date:    Fri, 12 Jun 1998 14:44:23 -0600
> From:    "Kelly J. Lipp" <lipp AT STORSOL DOT COM>
> Subject: Re: Collocation and Disaster Recovery
>
> Certainly collocate your copy stg pools, but only do that for data that
> really requires it.  If you do it for all of your data, you will have way
> too many copy stg pool tapes to move to the off-site on a daily basis.
>
> Kelly Lipp
> Storage Solutions Specialists, Inc.
> lipp AT storsol DOT com
> www.storsol.com
> (719) 531-5926
>
> -----Original Message-----
> From:   James SPORER [SMTP:james.sporer AT CCMAIL.ADP.WISC DOT EDU]
> Sent:   Friday, June 12, 1998 1:54 PM
> To:     ADSM-L AT VM.MARIST DOT EDU
> Subject:        Re: Collocation and Disaster Recovery
>
>      Colocate your copy storage pool.
>      Jim
>
> ________________________ Reply Separator ___________________________
> Subject: Collocation and Disaster Recovery
> Author:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>  at IPNET
> Date:    6/12/98 1:19 PM
>
> Collocation is wonderful for onsite primary pools. But what about during
a
> disaster where you lost your lovely collocated primary pools?
>
> The usual copy pool method, where you take tapes offsite each day, mixes
> your data from all machines each day on the tape, or tapes, you haul
> offsite. So that kind of storage pool will take forever to restore from
if
> you need to do full restores of a bunch of server; billions and billions
of
> tape mounts.
>
> I looked at using server-to-server copy pool backups, via the new ADSM V3
> "virtual volumes" feature. I had *HOPED* that the filespace name of the
> archive data that ends up in the remote server's storage pools would be
> something like "AdsmServerName,NodeName,FilespaceName,TimeStamp" -- for
> example,
> "ADSMSERV1.IBM.COM,ORACLE1.ITDEPT.IBM.COM,/u01,1998/06/12-16:34:42-001"
>  Then, you could just enable COLLOCATE=FILESPACE on the remote server's
> storage pools. Presto, you'd have collocated data, and restores would be
> wonderful.
>
> But unfortunately, I found that the real filespace name it uses is always
> (at least in the cases I've checked) "ADSM.SERVER".  It encodes the node
> name, timestamp, etc. in actual file names in its filespace which is of
> type ADSM_FS.
>
> Does anybody have any suggestions for how to have a disaster recovery
site
> that has a collocated storage pool for speedy recovery?
>
> --
> John Dawson <jdawson AT tkg DOT com>