I am aware of the issues with collocating offsite storage pools. I have a few 
customers that choose to spend the money and do it that way.
   
  If it was a server disaster then they would have the multiple versions of the 
file in the primary pool.
   
  A few of my customers have a hybrid approach for DR where they only collocate 
their critical servers' copy pool tapes.
   
  Some of my customers choose to create backupsets for some of their critical 
servers.  Active only DR tapes may be another approach to this. Of course you 
can't use those tapes to restore locally like you can with backupsets, but you 
could choose to create a second storage pool where you copy your critical 
servers to in addition to the copy pool.
   
  No choice should ever be made without thought and consideration I agree.
   
  Being that your an IBM'er, what do you think was one of the driving reasons 
behind treating an active only storage pool like a copy pool?  Do you believe 
the intent was to only create a 2nd set of tapes to take to DR?  My bet is that 
this fell into one of the RPQs that were sent in.
   
  I'll tell you this, I've been involved with many real DR tests at both 
Sterling Forest and Sun Guard. I've see first hand the torture of trying to 
restore servers from non-collocated offsite tapes. The real irony is that it is 
in a full site DR where your restoring from copy tapes that you need each nodes 
data to be on separate tapes.  However, as great a need as this is only a few 
customers actually choose to collocate their copy storage pools due to the 
increased cost in tape and media in order to accomplish this.
   
  I think there are many possibilities here.
  

Nicholas Cassimatis <nickpc AT US.IBM DOT COM> wrote:
  You may want to search the list archives on the issues with collocating an
offsite pool - it's not as easy/clean as you may be thinking.

While the customer may be OK with a corrupted file at the DR recovery, how
happy will they be if that's the one file needed to bring up the key
application in the environment? What if the corruption of the file is the
reason for the disaster (not all DR's are because of environmental factors,
some are declared because of virus/malware/hacker activity, or other
unforeseen issues).

There are some corners that shouldn't be cut, and that one sounds a bit
risky to me.

Nick Cassimatis

----- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 02/15/2007 02:11 PM
-----

"ADSM: Dist Stor Manager" wrote on 02/15/2007
02:02:22 PM:

> For years I've been asked by my customers if they could have many
> versions for files in their primary pools while limiting the
> versions in their copy pools to 1 for disaster recovery.
>
> In reading up on the new TSM V5.4 feature "Active-Only Storage
> Pools" it looks like this is now a reality. I could create an
> Active-Only storage pool (limited to backup data, no archive data).
> This new pool would now become my new destination pool for my backup
> storage pool command. I could even go one step further and choose
> to collocate this data by node. The end result would be a set of
> tapes at DR that would not have to skip over any files when
> performing a restore.
>
> I realize great consideration has to be done before implementating
> something like this because if the active file is corrupt you
> wouldn't be able to recover a previous version. Still, in the case
> of DR I know I have many customers that would accept the risk in
> order to reduce the amount of data they have offsite and to speed up
> their restores.
>
> I know that you can set a tape in an active only storage pool to
> offsite so I'm assuming that it will be included with move drm. I
> still haven't completed testing myself yet though.
>
> I'm wondering if anyone out there is considering this as well?
>
>
> ---------------------------------
> Sucker-punch spam with award-winning protection.
> Try the free Yahoo! Mail Beta.

 
---------------------------------
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.