Consider using the 4.2 client's journal backup feature, which is intended
to eliminate the need to scan the file system for changed files.

The elapsed time represents the total time from the beginning of the
operation to the end. Elapsed time should have been in the neighborhood of
15 hours, but if you are running 4.1.2.0, then the elapsed time is
erroneous (APAR IC29212, fixed in 4.1.3 and up).

Regards,

Andy

Andy Raibeck
IBM Tivoli Systems
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: araibeck AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
08/24/2001 08:24
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        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