ADSM-L

Re: Long Tern Storage - Backupsets/Archive/Other?

2000-08-21 12:20:08
Subject: Re: Long Tern Storage - Backupsets/Archive/Other?
From: Eric Lindbeck <elindbec AT SCTCORP DOT COM>
Date: Mon, 21 Aug 2000 12:18:56 -0400
Hi Terry,

Though we have considerably less data than you, I find myself asking
essentially the same question which I think you're asking (if I've
mis-interpreted anything, please correct me!)  -- How do I get a
'snapshot' of all data on a server such that the following
requirements are met?

1)  The process of creating the snapshot must not involve the clients
whose data is being 'snapshotted' (Is that a word?)  Reason:  Clients
need to be 24x7 and already have very large backup windows.  Besides,
all the data resides in TSM already.  Traditional archive is ruled out
by this requirement.  Copy pools and Instant Archive offer the best
satisfaction of this requirement.

2)  The tapes that comprise a snapshot must be easily identifiable.
Reason:  The data in the snapshots are intended for long-term storage
and we don't anticipate having to do restores very often.  Therefore,
we want to be able to store the snapshot tapes off-line, thus freeing
up valuable slots in the library for more recent data that will need
to be accessed quickly and often.  With multiple volumes in a
snapshot, we'll need to be able to identify which tapes to mount when
a restore is peformed.  As Terry points out, this requirement kills
Instant Archive.

3)  The snapshot must be subject to its own policy.  Only one version
of the client's files needs to exist in the snapshot, most likely
these will be the active objects.  Reason:  Like Archives, the
snapshot will need to live far past the longest retention of all other
storage pools (perhaps by years).  Extending the retention of
primary/copy pools to years is not practical.  This rules out copy
pools unless there's a feature that I don't know about.  Traditional
Archiving and Instant Archive give the best satisfaction of this
requirement.

The three possible solutions:  Copy Pools, Traditional Archiving, and
Instant Archive all fail on at least one requirement, leaving us with
apparently no TSM-supported method for doing what we need.  Copy Pools
would foot the bill very well, if only it were possible to completely
divorce the copy pool's policies from those of the primary pool that
gave birth to it (hmm... maybe I'm mixing too many metaphores here ;).

As a relatively new *SM administrator (<1 year), I'm hoping that
there's something I've overlooked or have misinterpreted.  Any
comments?

Thanks!
Eric S. Lindbeck
Data Storage Administrator
Network Infrastructure Services
SCT
"Science would be superfluous if the outward appearance and the
essence of things directly coincided."
--Karl Marx
                    "Barth, Terry V.
                    "Barth, Terry V.
                    (MBS)"                        To:     ADSM-L AT VM.MARIST 
DOT EDU
                    <Terry.Barth@MORTGAGEF        cc:
                    AMILY.COM>                    Subject:     Long Tern 
Storage - Backupsets/Archive/Other?
                    Sent by: "ADSM: Dist
                    Stor Manager"
                    <ADSM-L AT VM.MARIST DOT EDU>


                    08/20/00 01:43 PM
                    Please respond to
                    "ADSM: Dist Stor
                    Manager"





Hi fellow *MSrs -
I have a situation that I am trying to work out - we have
approximately 250
servers each with anywhere from 6 gigs to 250 gigs. The situation is
that we
have implemented an offsite copy storage pool - that works fine. What
we are
looking to do now is to create long term storage on our nodes.
I realize that there is the new thing called "Instant Archive" - but
this is
not automated as far as keeping track of which node went to which tape
and
when the tape could be brought back onsite - unless, there is someway
to do
it that I am not aware of - in addition, it does not appear to be very
easy
to retrieve the data.
I know that there is the standard archiving, however, this must go out
to
the server. This is a problem since our window for backups is 10pm to
8am
everyday including weekends. It would be difficult to do the backups
and the
archives during this time due to not wanting to bring down or slow
down
services.
Therefore, I was just wondering what alternatives are there - or if
anyone
had any suggestions on how this could be implemented. For example,
possibly
there is a way to have a longer retention period on copy pools????
<That
would be a nice feature - maybe it is available>
Or, has anyone found a way to keep track of the backupset
automatically - I
know I can run a script to see who and what tape - but I do not see
anything
in the tables to let me know exactly when the tape should be brought
back.
Most likely, this can be done in a script as well?
Any advice or help will be appreciated.
Thanks.
Terry
<Prev in Thread] Current Thread [Next in Thread>