We are not calling them exactly Class 1, Class 2 and Class 3 but are using
the same rules for collocation. There is a slight modification - you can
"manually" collocate by creating Class 3a, Class 3b, etc. So the tape pool
for Class 3<something> would not be too big and on restore you will need
less tapes. And Class 3z may become Class 4 with
all-those-absolutely-non-critical-nodes and unlimited number of tapes in
it.

I also enjoy debates. And many threads on this list are about *proper* TSM
(now ISM) setup. I have seen a customer using Oracle database through ODBC
as plain dBase files with own relations logic on top of this. Guess what
was the performace. From this I cannot say Oracle is abnormally slow
database, right? Weird setup does not mean the product is bad.
That's why for example Incremental-forever does not work with TDP (now ISM
for ...) products. If MS Exchange had adopted this nice backup technique
and APIs allow some kind of mapping of IS to filespace name, Mailboxes to
directories and folders to files ... We could have incremental-forever
with restore granularity down to a folder and subfile backup can help us
to transfer only new/deleted messages. Or something even better. Same for
Oracle for example - instances may be same type of object as filespaces,
tablespaces - directories and tables vs files.
BTW: explaining to customer I prefer to use term "object" pointing that
for B/A client this is an ordinary file but for TDP is application
dependant. And from this point of view I explain why many good sides of
"Progressive Backup" go away.

Zlatko Krastev
IT Consultant

P.S. And completely new things demand from us to change our way of
thinking. Same as a century ago there was speed limit for cars of 5 km/h
and a man with red sign ought to walk in front of the car to warn the
public and prevent horses to panic!!! I am not kidding.

Zlatko




Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        Re: Monthly Backups, ...again!: The Real Issues

I enjoy TSM debates, but one that has not sold me yet is this particular
one.  Yes, I come from a different environment (than Incremental-forever).
One of the biggest drawbacks of the old ADSM was the abnormal slow
restores
and this has been notified by a collegue of mine of why his previous job
did not get ADSM back in the early 90's.  My suspicion was this
Incremental-forever and here I see why.  It all relies on the collocate
issue.  If you have numerous tapes and numerous drives than collocate will
make Incremental-forever a quck restore.  I started with 2 drives 80
clients and 500 tapes leading to no-collocate.  When restoring 2 GB+
restores that were spread out over 70-100 tapes this took almost 8 hours
(note this took about 1 year to get to 70-100 tapes).  At our DR test we
noticed a diffence of 6 times a normal restore for no-collocate versus a
backupset.  But on the other hand I brought that restore time down when
splitting the restore into 5 separate restores for 5 tape drives (I
currently have 6 drives).  So the no-collocate will work if the right
amount of tape drives are available (our 3570 are pretty expensive).  Now
in the real world you usually have 1-2 tape drives for restores
(dedicated)
and you cannot afford to send 80 tapes off every night for collocate, so
what we are gravitating to is a class1, class2, and class3 system.  class1
will be our DRM critical restore with collocate onsite and offsite, class2
our noncritical but high restore class with collocate onsite and
noncollocate offsite.  and then the good class3 with nocollocate onsite or
offsite.  The monthlys or Absolutes will be used to stop the spreading of
info over 70 -100 tapes.  It may not be true, but I seem to see the more
reclamation the more spreading of info.  and I would have thought that the
reclamation would bring info closer together.  All it takes is one time of
getting burned with the 70-100 tape restore spread.  We have presently
moved data from one server to another 7 GB and used TSM to do this. If the
manual full had not be done the night before (which has happened) then I
still be restoring as we speak.  There are more good things about fulls
than meets the eye.  Now I know not all restores are 2 GB+ but I do see
more and more and we will all have to deal with it in our own ways.  Just
1
way of dealing with it.  Not the only but a way is better than no way.



                    "Seay, Paul"
                    <seay_pd@NAPTH       To:     ADSM-L AT VM.MARIST DOT EDU
                    EON.COM>             cc:
                    Sent by:             Subject:     Re: Monthly Backups,
...again!: The Real Issues
                    "ADSM: Dist
                    Stor Manager"
                    <ADSM-L AT VM DOT MAR
                    IST.EDU>


                    04/10/02 01:14
                    AM
                    Please respond
                    to "ADSM: Dist
                    Stor Manager"






I would like to find the first customer out there with 20 clients (80+GB
servers) that does not lose a full backup at least once a week and exceeds
the backup window time and has no backup of that server.  Or similarly on
the incremental that is not restartable.

TSM does checkpointing and completes a backup after restarting at the
backup
point.  Heck, I have HALTed my TSM server in the middle of backups and
watched them restart at were they left off.  I did it to see what would
happen.  My Windows folks lost 1 backup that was in a unrecoverable
initialization state at the time of the halt.  And, that was easily
restarted.  There is no other viable product in the market that can do
this.

The argument is you cannot restore the incremental because it takes too
long
is bogus.  I never could realize what I was missing in the conversation
until I read Zlatko's explanation below.  I forget that the Weekly FULL
paradigm INCREMENTAL daily makes people think they have to restore each
file
to make up the incremental many times.  When TSM just restores the right
one
to the point in time that you need recovery.

There is an issue that concerns me that most folks forget about.  Your DR
offsite set may span a long period of time.  After so long the tapes may
not
be readable because the DR site people dropped them a couple of times and
you not know it.  Two sets pose the same threat, but less so.  So, if a
tape
is bad, you lose a lot of data, possibly a lot of servers if many are in
the
same storage pool and you do not have any collocation turned on.  There
are
two solutions to this problem.  If we had reclaim a tape if it was created
more than x days ago, that would force reclamation on a tape no matter
what.
The other is a duplicate offsite pool.  Neither of these capabilities are
automatic today.  To get the tapes to reclaim you have to do your own MOVE
DATA RECONSTRUCT=YES for any tape last written to over x days (it would be
nice to have an optional value to specify in the storage pool for this).
The duplicate offsite requires you to run the BACKUP STG for each copy (it
would be nice to specify multiple outs if that makes sense and is
possible).
The other thought that I have had is to have multiple copy pools and
rotate
through them updating each on on a cyclic basis.  So, if you had 6 and you
sent an update offsite weekly you would have 6 intact storage pools.  But,
the server overhead to do this is significant.

Other FULL Backup tools have a way around this by accepting a week older
backup of the data.  Essentially, they have 6 copies of the data offsite.
Just a matter of how much data they want to lose.

The point here is plan your TSM environment to meet your business recovery
needs and you will have a vastly superior solution than any other product
can offer.