Quote from Admin's Ref. for BAckup STGpool :
"If a file already exists in the copy storage pool, the file is not backed
up unless ..."

TSM implements incremental-forever to storage pool backup same as for
client backups. A list of "objects" to be backed up is created comparing
contents of the primary pool and existence of copy in the copy pool. If
the copy does exist the object is not included in the run. Each file
version is treated as separate object within the TSM server DB and is
tracked by internal ObjectID not by name.
You can find the proof yourself:
1. create small diskpool and backup some data there
2. backup diskpool contents to a copy pool
3. create a tape pool and migrate test diskpool data there
4. invoke backup of tape pool to the same copy pool
The tape pool backup will finish in less than a second with result 0 files
backed up - all data already has copies and incremental algorithm has
nothing to do.

Zlatko Krastev
IT Consultant






Kai Hintze <kai.hintze AT ALBERTSONS DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04.04.2003 21:12
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        How many copies in copypool?


Greetings oh wise and varied *SM'ers!

I have an internals question.

I have a primary disk pool BACKUP_DISK, with a collocated primary tape
pool
BACKUP_TAPE that BACKUP_DISK spools to when it gets full (or at 16:30,
whichever comes first :). I have enough disk that I seldom need to migrate
data out of BACKUP_DISK during the night, but occasionally we have a
really
heavy day, and BACKUP_DISK goes over its threshold and migrates before its
schedule. For disaster recovery I have a non-collocated tape copypool
BACKUP_OFF. During the day our DRM script does a "backup stg BACKUP_DISK
BACKUP_OFF" then "backup stg BACKUP_TAPE BACKUP_OFF", in case we had a
migration in the night. So far that is fairly straightforward, but now
comes
the tricky part....

If a long-running backup pushes BACKUP_DISK over its threshold after some
of
the files are sent from BACKUP_DISK to BACKUP_OFF, but before the backup
from BACKUP_TAPE to BACKUP_OFF starts, then the files are there to be
backed
up to BACKUP_OFF *again* from BACKUP_TAPE. So the question is: Does TSM
recognize that the files are already in BACKUP_OFF, or does it make
another
copy?

The reason I am asking is that we are using LOTS of tapes, and management
wants me to see if I can cut back on the burn rate. I know that tape to
tape
copy would be slower because I would have multiple input mounts per output
tape, but I don't do the disk to offsite backup, but instead migrate, then
tape to offsite backup then I know that the offsite pool only has one copy
of all the files.

Thanks for any insights.

- Kai.