Re: weird backup
2000-12-15 13:17:12
Subject: |
Re: weird backup |
From: |
Richard Sims <rbs AT BU DOT EDU> |
Date: |
Fri, 15 Dec 2000 13:14:28 -0500 |
>I seem to have a weird backup situation here
>
>I am running backups in a test environment. I'm testing large arrays for file
>servers.
>The 1st sel backup took around 9hrs (80GB), subsequent sel backups are taking
>around 19hrs to complete.
>
>As I am only running sel backups I figure the ADSM database should not be
>processed for the next backup to run. Even if it was it shouldn't take 19hrs.
>The weird thing is that if I change the drive letter so that ADSM thinks the
>data is from a new file system the backup time is back to around 9hrs.
>
>This is quite puzzling.
>Can anyone out there shed some light on this.
Toni - Interesting numbers. Your second Selective Backup will necessarily
take longer because all your Copy Group definitions have to be observed
and processed: the previous Active files have to become Inactive files, the
number of Versions have to be checked and Retentions checked. I would not,
however, expect that additional work to add as much as 10 hours to the backup.
The number suggests a problem with the TSM database...
Database performance - Locate the database on disks which are
separate from other operating system
services, and choose fast disks and
connection methods (like Ultra SCSI).
- Spread over multiple physical volumes
rather than consolidating on a single
large volume: TSM gives a process
thread to each volume, so performance
can improve through parallelism.
- Do 'Query DB F=D' and look at the
Cache Hit Pct. The value should be up
around 98%. If less, consider boosting
the server BUFPoolsize option.
More files (as in backing up a disk containing myriad small files) naturally
aggravates database work.
I presume you are running this large backup from the command line client,
rather than the GUI, to maximize speed.
Richard Sims, BU
|
|
|