Hi,
I would think that collocation would be the solution, but I would
caution that collocation by node with "a couple hundred" nodes equals "a
couple hundred" tape mounts each morning for migration. I would suggest
that you look closely at two things:
1) Is there a subset of servers that are of critical importance. We
have a rating scale that basically defines SLA's including a restore
time SLA (which no one asked the backup admin about before they
defined). If there is a subset, then put the critical servers into
another pool and use collocation on that pool.
2) Upgrade to 5.3 and use collocation 5.3 and use collocation by groups.
Basically you create collocation groups which says that this group of
nodes can be on a set of tapes together. This greatly reduces the tape
creep, but also requires more tapes that #1 above. In this case, you
would have tape mounts equaling at least the number of collocation
groups you have.
Either way you will have to migrate that data from the current tape pool
to a new one to reorg it. Additionally, collocation is largely not
useful on copy pools unless you have a remote library or something of
that nature.
IMHO, the holy grail for all of this is disk based virtual tape
libraries. None of us would care about the number of tape mounts if
they tool 5 ms instead of 30-60 seconds. Granted, tape will always have
its place (can anyone say oracle backups), but for windows servers with
tens to hundreds of thousands of small files, tape can be difficult even
at its best.
My $0.02
Michael Wheelock
Integris Health of Oklahoma
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Jones, Eric J
Sent: Monday, November 14, 2005 9:05 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Backup question - Full and Incremental
Thanks. The problem I have is the backup policies where set long before
I arrived. I'm working to correct what we have so it's more efficient.
My thought initially was to do a full backup on some of the key servers
to get the data on a single tape so it is not on so many tapes then work
on a long term solution. Collocation was something I was considering
but needed to do more homework to understand what affect it would have.
We have a few hundred servers that backup and I wanted to understand the
full effects of collocation before implementing. A full backup would
give us a short term solution while working on the long term solution.
Thanks
Eric
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Monday, November 14, 2005 7:42 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Backup question - Full and Incremental
On Nov 14, 2005, at 3:19 PM, Jones, Eric J wrote:
> ...We normally just run incremental for all our machines and over the
> years
> the data gets scattered every where(number of tapes and in some cases
> 30+) so restores can be very slow. ...
Eric -
The magic word "collocation" does not appear in your posting. It is the
standard means by which data, related by node or filespace, is kept
together. That, plus reclamation, minimizes the number of tapes needed
to
perform a restoral.
Being a full-featured product, TSM provides a host of capabilities by
which
one may satisfy enterprise data recovery needs. A storage pool hierarchy
involving frontal disk, migration, caching, and copy storage pools will
allow quick restoral of most recent data. Full backups can be done, but
are
often testimony to an ill-thought-out backup/restore architecture.
Review redbook "IBM Tivoli Storage Management Concepts" and the
Administration
Guide manual for methods by which client-sent data may be managed. This
topic is also
heavily represented in the List archives. A good data recovery design
focuses first on
restoral methodologies and performance, then looks at realistic
approaches to backup
to facilitate restoral.
Richard Sims
|
