DSM

NAVIGATION
CATEGORIES
REFERRENCE
LINKS
  • Lots of newbie questions

    0 answers - 4980 bytes - related search similar search Add To My Delicious Add To My Stumble Upon Add To My Google Mark Add To My Facebook Add To My Digg Add To My Reddit

    Fri, Aug 11, 2006 at 09:29:26AM -0400, Allen S. Rout wrote:
    Said from another direction, TSM doesn't worry about selecting only
    backed-up data from a stgpool when it's migrating, it takes whatever
    is there.
    Thanks for the clarification.
    Best practice-wise, do you try to define different private groups
    and tape labels for onsite, archive and offsite storage? do
    Your recordkeeping problem is too complex to do by casual inspection,
    You will inevitably end up needing more "Primary" tapes when all
    you've got on hand will be labeled for "Reverse thudpucker" use or
    some such; Then you'll cross your own lines, and after the first time
    it gets easier and easier
    I've been running purposedly labeled tapes/pools for quite a while in
    the leveled backup world of Networker. Jumping to a 'just the system
    pick it' mentality is one of the hurdles (and appeals) of TSM. I fully
    understand your point on the media labels, and will learn to live with
    it. :)
    Having an extra drive outside a library isn't exactly a _bad_ idea,
    but unless you're trying to write a different format I'd expect you to
    get more value out of adding it to the library.
    I don't think I can convert an external drive to run in the library.
    You make good arguments for having internal drives, and I don't
    disagree. But given that I have an external tape drive, it shouldn't be
    an either/or for me to use it or the library.
    If you really, really want to do this, I'd suggest:
    - Define all of the drives to be "in" the library. set the one which
    is physically outside to usually be offline.
    - When you want to use the external drive, set the interior drives
    offline, the exterior online. Run the job, mount, dismount, etc.
    - When you're done, re-set to normal operations.
    I suspect that by itself wouldn't work because the SCSI library would
    want to do something to checkin/mount the drive, and I wouldn't want to
    reconfigure switching the library to manual or not.
    I'm thinking more along the lines of defining the SCSI library and
    manual library, and switching the devclass between them as needed.
    That's just a stopgap - it doesn't really make it usable, unless I
    define an entirely new devclass and use it for relatively few things
    (like backupsets or db backups to tape.)
    No one else has dealt with transitioning between both manual and
    automatic libraries?
    Personally, I'd much prefer checkin and checkout of desired volumes to
    this. And get a quote on how much the next bigger step of library is,
    and count the amount of time you spend screwing around with inadequate
    library space. That way you can demonstrate to the folks who are
    hoarding the beans when they start losing money because they didn't
    cough up a library at the outset.
    TSM is tremendously economical with tape and drive resources compared
    to other backup products. Feed it well; feed it hardware instead of
    your time.
    That point is muddied when a drive configuration that worked just fine
    with other backup products is either unusable or inadequate for TSM.
    I'm sticking with my current hardware/specs for this first year and have
    already warned the bean counters that odds are I'll need something near
    the start of year two -- be it more drives, more library space, more
    staging disk, beefier or multiple servers, etc.
    Now, if you were me, you'd try to develop a theory of copystg
    utilization workflow, and solve it for a minimum. But I suggest you
    just twirl the knob to the other end, and see if you like that
    tradeoff better.
    Good point. I'll try some variations and see how it goes.
    You should consider data which has expired to be Gone, except for
    heroic measures.
    If you Really Need data which expired out of the database in the last
    week or so (a common period for retention of DB backups) then yes, you
    can do a complete DR scenario, and consult the as-yet unreused tape
    volumes for the data. Icky squicky.
    Thanks, that's the definition I was looking for. As for "Really Need,"
    it depends who asks :)
    It's usually an answer like 'You messed this up last month, overwrote
    it every week and didn't notice until the first of this month, and
    have waited until NW to ask me to get it back? No, it's gone.".
    My backups will probably be augmented with regular archives (or
    backupsets) for the important systems, so the provision of 'losing'
    anything (at least for the people who "Really Need" it) should be pretty
    low.
    Any opinion on archives vs. backupsets for a monthly snapshot kept for 6
    months?
    Thanks for humoring me,
    Dave

Re: Lots of newbie questions


max 4000 letters.
Your nickname that display:
In order to stop the spam: 0 + 9 =
QUESTION ON "DSM"

EMSDN.COM