Usage of archive instead of backupsets gives you many benefits -
granularity down to a single file, copypool protection, etc.
You can control the archiving through several ways:
- archive copygroup may point to another storagepool hierarchy (which is
done by default in v4.x servers - BACKUPPOOL and ARCHIVEPOOL are
different). Storage policy in that hierarchy might be different from
stgpools used for backups.
- you cannot stop a sysadmin to use 'dsmc archive' on his/her discretion
but can track from the server what/when archives are done.
- you are messing the terms - there is no way to use archive copygroup for
any backup (selective or incremental)
- there is a way to block particular client from performing archives -
define separate domain + policyset without archive copygroups and move the
node to that domain. Lack of archive copygroups will lead to lack of
destination stgpool for archives - no archives will be possible.
Zlatko Krastev
IT Consultant
"Chetan H. Ravnikar" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
13.10.2002 02:31
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: archive services!
Hello all
thanks in advance for your valuable tips!
We are planning to introduce the archive feature within TSM on our new
install base., and I have a few issues and concerns on how to protect
in-accidental or deliberate use of this service.
Currently 90% of our client backups run via a central schedular with a
only a few clients who run it via CRON (client initiated)
We use * backupsets* feature as part of our service for long term audit
and legal requirements only, Now we are planning to use the archive
service for archiving source code or users (who have left the company)
private info etc for medium term rentention. via the archive group
feature,
The question is, Is there any way we can control this from the server
The reason being, once we open this feature. The moment we assign scratch
tapes to the archive copy group on the domains we want to open this
feature. There is no way one can stop a sys-admin who has
super user rights to run a *dsm arc* command on a file-system at
his discretion.
my uderstanding, there is no way I can stop a client which was doing an
incremental backup send its data to the *archive* copy group or I have it
wrong
many thanks
Chetan
