Journal backup is only for NT right now, right? And he's on AIX...
When might the Journaled backup feature be available under AIX etc.?

> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Andrew Raibeck
> Sent: Friday, August 24, 2001 11:46 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Long, long, long backup sessions
>
>
> 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
>