ADSM-L

Re: Co-location

2002-10-22 10:27:28
Subject: Re: Co-location
From: Jane Bamberger <jane.bamberger AT BASSETT DOT ORG>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 22 Oct 2002 10:05:04 -0400
HI,

I think your problem might be the NOLIMIT option - it saves a copy of all
files - whether or not they are deleted - it doesn't clear space off your
disks during expiration - we had the same problem - until I removed NOLIMIT
off our Novell policy.

Jane
%%%%%%%%%%%%%%%%%%%%%%
Jane Bamberger
IS Department
Bassett Healthcare
607-547-4750
----- Original Message -----
From: "Matt Simpson" <msimpson AT UKY DOT EDU>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Tuesday, October 22, 2002 9:46 AM
Subject: Re: Co-location


> At 3:53 PM -0400 10/21/02, Thach, Kevin said:
> >The person that installed our environment basically set up 6 Policy
Domains:
> >Colodom, Exchange, Lanfree, MSSQL, Nocodom, and Oracle.
> >
> >99% of the clients are in the Nocodom (non-collocated) domain, which has
one
> >policy set, and one management class which has one backup copy group with
> >retention policies set to NOLIMIT, 3, 60, 60.
>
> This is away from the topic of Kevin's question, but his background
> info led to a question that we're looking at right now.
>
> We currently have one big disk pool for all our backups, which
> migrates to one tape pool, which we copy to another tape pool for
> offsite.
>
> We turned on co-location on the onsite tape pool a couple of weeks
> ago, because we just started using the SQL TDP, and the doc
> recommended colocation.  We turned it back off this morning, because
> we were running out of tapes and had a lot of them that were only 5%
> full.
>
> We would like to do what Kevin says he's doing: specify colocation
> for a small number of our clients and leave it off for a bunch of
> them.  But, if I understand correctly, colocation isn't specified
> directly in the management  class.  It's specified on the tape
> storage pool definition. So specifying colocation for some  clients
> but not all would require multiple tape storage pools, which wouldn't
> really be a problem.  But it looks like that would also require
> multiple disk storage pools, because, as far as I can tell, the only
> way to get a client into a different tape pool is to have it in a
> different disk pool.
>
> We'd really like to avoid carving up our disk space into more smaller
> pools.  But, as far as I can tell, that's the only way to use
> colocation selectively.  Am I missing something, or is that the way
> it works?
> --
>
>
> Matt Simpson --  OS/390 Support
> 219 McVey Hall  -- (859) 257-2900 x300
> University Of Kentucky, Lexington, KY 40506
> <mailto:msimpson AT uky DOT edu>
> mainframe --   An obsolete device still used by thousands of obsolete
> companies serving billions of obsolete customers and making huge obsolete
> profits for their obsolete shareholders.  And this year's run twice as
fast
> as last year's.
>

<Prev in Thread] Current Thread [Next in Thread>