ADSM-L

Re: [ADSM-L] Good or bad idea?...offsite disk.

2007-04-02 12:41:00
Subject: Re: [ADSM-L] Good or bad idea?...offsite disk.
From: Kelly Lipp <lipp AT STORSERVER DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 2 Apr 2007 10:40:30 -0600
Lots of thoughts here and in no particular order.

1. Define the volumes rather than using scratch volumes for your file
device class pools.  No point allowing the system to do this:

Define volume stgpool e:\of formatsize=5000 numberofvols=256

This command will format and define 256 volumes of size 5GB to your
storage pool.  Repeat until your drive is filled up.  This will
eliminate all the errors you are seeing and eliminate fragmentation on
the disk.  You might want to make the volumes larger (remember the size
is also a function of maxcap on the devclass parameter).

2. Aggressively reclaim the storage pool.  Perhaps set reclaim to 30
rather than the standard 60.  This will have lots of data movement, but
will tend to keep as much space as possible available in the pool.

3. As for mirroring primary pool volumes.  Hmmm.  Why not? You will
still want to have a dr copy in case something happens to the primary
volumes.  This could be tape or it could be disk.

I've attached two Oxford 2005 presentations that discuss this in more
detail.  First is Dave Cannon's feature overview and then my practical
implementation of these features.  I believe both are still relevant.

Additional questions: fire away.  I've done a good bit of work on
this... 


Kelly J. Lipp
VP Manufacturing & CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777
lipp AT storserver DOT com

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Andrew Meadows
Sent: Monday, April 02, 2007 10:04 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Good or bad idea?...offsite disk.

You wouldnt be able to set up a copypool for the offsite copy it would
have to be another onsite pool. You could always try using the devcl
type of file and going that route.

I would also look at doing the dbbackups as devcl=file. That is what we
are looking at doing to reduce the waste of gigs of tape for a rather
small db.

On Mon, 2007-04-02 at 11:55 -0400, Lawrence Clark wrote:
> We have two sites. The 2nd site has primary storage, the primary 
> copypools. Both are currently in tape libaries.
>
> We do plan to move the primary storage pools to SATA drives on a 
> DS4800.
>
> We did try migrateing the copypools to SATA drives but I found the 
> setup very awkward. Primary pools can be random storage, copypools can

> only be disk based if they simulate drives.
>
> What I found was when it reached the end of the disk 'volume' it 
> generated a write error on the 'volume' and then allocated another 
> volume and continued. However, this meant reseting the volumes that 
> reached the maximum volume size each morning.
>
> The problem with mirroring primary storage pool is a delete on one is 
> an immediate delete on the mirror.
>
> >>> jlea AT DIS.UMSMED DOT EDU 04/02/07 12:31 PM >>>
> One of my TSM servers is using disk only for onsite pools and tape for

> offsite.  I am considering putting a SAN offsite to mirror my onsite 
> diskpools thereby doing away with tape all together.  This server has 
> about 12TB of storage.  I have a dedicated fiber link to my offsite 
> location.
> Is this a good or bad idea?  I understand that DRM won't be in effect 
> any longer.  Client restores would be more readily available if needed

> but what about the database?  Any considerations or recommendations 
> there or elsewhere?
>
> Thanks,
> Johnny
>
>
> The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
addressee(s) and may contain information that is confidential,
privileged, and/or otherwise exempt from disclosure under applicable
law.  If this electronic message is from an attorney or someone in the
Legal Department, it may also contain confidential attorney-client
communications which may be privileged and protected from disclosure.
If you are not the intended recipient, be advised that you have received
this message in error and that any use, dissemination, forwarding,
printing, or copying is strictly prohibited.  Please notify the New York
State Thruway Authority immediately by either responding to this e-mail
or calling (518) 436-2700, and destroy all copies of this message and
any attachments.

********************************************
This message is intended only for the use of the Addressee and may
contain information that is PRIVILEGED and CONFIDENTIAL.

If you are not the intended recipient, you are hereby notified that any
dissemination of this communication is strictly prohibited.

If you have received this communication in error, please erase all
copies of the message and its attachments and notify us immediately.

Thank you.
********************************************