Look in the accounting log, dsmaccnt.log in your server/bin directory.  The
format is documented in the Admin Guide - look up dsmaccnt.log in the index.

This will show you whether the session had a lot of Idle wait (client slow -
compression? millions of files to walk?) , a lot of media wait(direct to
tape, and out of drives?), or a lot of communication wait (network slow?
confirm with ftp.).

Maybe the elapsed processing time subtracts the time-of-day without looking
at the date.  If this session really started at 06:12, that would fit. I
know we've had problems trying to use this number in our monitoring product.

The 8 million files is probably the problem, coupled with client-side
compression.
Solutions: find the huge directory and use exclude.dir if it's junk;
        Clean out old stuff so you don't have to walk the thing;
        Unmount the filesystem and use image backup;
        cpio or tar up the big directory into one file during the day, then just
backup that one file.




> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Zoltan Forray/AC/VCU
> Sent: Friday, August 24, 2001 11:25 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Long, long, long backup sessions
>
>
> Looking for some guidance to improve backup session times.
>
> The time it takes to backup our e-mail servers (4-way processor H70 AIX
> 4.3.3 with 2GB RAM. TSM client is 4.1.2.0) is becoming unacceptable and
> unworkable.
>
> Currently, backup sessions are sometimes taking more than 16-hours (as I
> send this, one session that started yesterday evening is still running),
> yet the total amount of data backed up is only around 2.5-4GB. The current
> session stats shows the first data transfer wasn't until around 3:45 this
> morning, yet the backup session started around 6PM, YESTERDAY.
>
> Yes, I understand the LARGE amount of OBJECTS INSPECTED is an issue. But,
> the current data tells me it took over 8-hours from the start of the
> schedule to when it actually transfered any data from the client to the
> server (OS390 TSM 4.1.3).
>
> Here is a end-of-schedule snippet from a previous days run. Note, it
> started at 6PM and finished at 9AM the next day. When it actually did any
> work, it went pretty fast:
>
> 08/23/01   09:00:37 --- SCHEDULEREC STATUS BEGIN
> 08/23/01   09:00:37 Total number of objects inspected: 8,521,197
> 08/23/01   09:00:37 Total number of objects backed up:  105,231
> 08/23/01   09:00:37 Total number of objects updated:          0
> 08/23/01   09:00:37 Total number of objects rebound:          0
> 08/23/01   09:00:37 Total number of objects deleted:          0
> 08/23/01   09:00:37 Total number of objects expired:     32,662
> 08/23/01   09:00:37 Total number of objects failed:           7
> 08/23/01   09:00:37 Total number of bytes transferred:     2.83 GB
> 08/23/01   09:00:37 Data transfer time:                5,685.47 sec
> 08/23/01   09:00:37 Network data transfer rate:          522.69 KB/sec
> 08/23/01   09:00:37 Aggregate data transfer rate:         55.16 KB/sec
> 08/23/01   09:00:37 Objects compressed by:                   51%
> 08/23/01   09:00:37 Elapsed processing time:           00:02:48
> 08/23/01   09:00:37 --- SCHEDULEREC STATUS END
> 08/23/01   09:00:37 --- SCHEDULEREC OBJECT END BACKUP.MAIL 08/22/01
> 18:00:00
>
> The "Elapsed processing time" is confusing. Is it trying to tell me it
> only took 3-minutes to actually transfer the 2.83GB ??
>
> What can we do to improve these times ?   Is INCRBYDATE going to make that
> much of a different, considering we will still have to do some kinda full
> backup, anyway ?
>
> Any and all suggestions will be seriously considered !
>
> ===========================
> Zoltan Forray
> Virginia Commonwealth University
> University Computing Center
> e-mail: zforray AT vcu DOT edu
> voice: 804-828-4807
>