Zoltan,
I would suggest the problem is nothing but the amount of files that
need to be processed. I have one client with 3 million + files set that
file system to do incrbydate instead of incremental. The results were
definitely worth it. The only loophole I can see with this solution is as
follows. If a file is added to the file system with a previous date then
incrbydate will not pick it up. For example if you untar files into the
filesystem the files will maintain their original date and not be backed
up. To catch these exceptions you would need to do a regular incremental
once a week or as you see fit.
The only other option I have seen on this board is to tar the files
up first and then backup them up. This however might require a large amount
of disk space.
As far as no data being transferred for the first eight hours I find
that surprising. I would assume that the first file system to be looked at
is / and there would definitely be files there that need to be backed up.
The only explanation I can think of is if your backup is looking at the
filesystem with the large number of files first.
IMHO
Jon Martin
-----Original Message-----
From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 24, 2001 11:25 AM
To: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
voice: 804-828-4807
