Wanda,

in general I am on your side but some of the arguments are weak:
1. stgpool backups
If the DB is reverted back newly created copypool tapes will be listed as
scratch and primary pools' objects will have no copies. Next backup to
this copypool will fix the things and probably will use same scratches.
2. tape reclaims
Similar as above for reclamation destination tapes and reuse delay
protects reclamation source tapes
3. expiration
It can be performed again without data loss. Yes, for large DBs time for
expiration is an issue but the only penalty will be larger first
expiration *after* recovery.
4. HSM client bringing a file from TSM back to host
Again no data loss. Option to backup the file *before* migration ensures
we will have a copy to restore from.

Now other arguments. Besides some remarks I prefer roll-forward mode :)
you already pointed hundreds of desktops backing up around the clock.
Sites which *do* backup desktops very often cannot have all of them
available at night. And you cannot predict when a mobile user will be
online or in the office.
RDBMS servers perform backups during normal window but transaction logs
are coming throughout the day regularly.
archives - user archived a set of files, got successful completion
result and does not care further.
some applications use TSM as *the only* storage, example IBM CommonStore
loss of last minute TSM DB updates will lead to loss of created/revised
documents.
After data came in TSM our task is to protect it. Even with new
functionality of v5.1 loss of DB updates will lose track of both copies.

Zlatko Krastev
IT Consultant




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: DB backups

For some environments, yes.  But not for all.

Even people who backup once overnight, still have to do

(1) backup stgpool to create copypool tapes.
(2) tape reclaims
(3) inventory expiration

All those things change the TSM DB.

And some environments are really 24 x 7:

One of our TSM servers does desktop backups of 500+ clients.  Backups are
spread over 24 hours a day, so for that environment, the TSM db is
changing
EVERY MINUTE.  Really.

And consider also the people who have implemented the HSM client - in that
environment, just having a user "touch" a file is enough to bring it back
from TSM storage to client storage, and the TSM DB is changed.

In either of those environments, losing 12 hours, on average, of DB
changes
can be devastating.

************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************