ADSM-L

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
<Prev in Thread] Current Thread [Next in Thread>