Several folks suggested not compressing on tape. As my LTO2 devclass was
format: ULTRIUM2C, I created another devclass that was just ULTRIUM2.
Then created new primary and copy tape pools and pointed to them.
(This one client was in a Domain by itself, so I had more freedom to do
this.)
Results were little different, still takes twice as long to backup (or
do tape to tape copy) of a 62 GB compressed file as same size uncompressed
file. Main thing I noticed, was that the few uncompressed files, some 5-7
GB I could see they took longer than on compressed tape, that seems logical
and I think proves Andy's point here.
Now, maybe I had it wrong, I would have thought it took as
long to backup as certain size file whether compressed or not,
as long as you are not trying to compress it more?
So, I changed everything back to original devclass, etc.
Some folks at my site tried to discuss things to change on the client.
I told them if tape to tape is taking that long, no need to spend
time on the client side, it's just the way it is with these compressed files.
I will say that this new method is better than before, we went from 11-12 hours
to backup this client with 1.2 TB of data to about 4 hours to backup 250 GB of
data.
Most people would be delighted with that improvement! We just thought
we could get it down to 2 hours.
This also I think proves a suspicion I have had about a few other clients.
They have compressed files normally, many on the size of a few GB or more, not
as
big as current issue. Now, I realize they have the same problem, not as fast,
even
with tape to tape copy, as I would expect. Totally different application and
compression of files on disk by the application. I believe they are taking
twice
as long as they should.
If anybody figures out how to speed up backing up files not compressed by
TSM, let me know!
Thanks,
David Longo
>>> "Huebner,Andy,FORT WORTH,IT" <andy.hueb...@alconlabs.com> 4/28/2010 6:25 PM
>>> >>>
LTO2 writes to tape at maximum of 40MB/sec. If the data compresses 3.5:1 then
your server will need to feed the tape drive at 140MB/sec to keep up with the
write speed. If the data compresses 1:1 then you only need to send data at
40MB/sec.
This kind of thing used to drive me nuts until I figured out it takes about 1
hour to fill one of my tapes, regardless of the amount of data written. If it
takes longer then there is a problem. In your case 85 minutes is the minimum,
probably a little under 2 hours is a realistic time.
Andy Huebner
"You have to think 4th dimensionally."
Emmitt L. Brown
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of David
Longo
Sent: Tuesday, April 27, 2010 1:44 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Backing up Light Speed compressed files
I have never been concerned with compressed files, never used
compression on TSM - except on my LTO tapes.
Now, we have a new situation. We have had a client with SQL DB and
the DBA's do the dumps to disk and I pick up. (Can't use TDP SQL,
long story.) The dumps were lately (6) 200 GB files, total 1.2 TB and
growing daily. Took about 11 hours to backup directly to LTO2 tapes.
DBA's just implemented using Quest's Light Speed using their Level 4
compression - whatever that is. The dumps are now (4) 62 GB files,
so about a 5 to 1 compression.
The TSM backup took much less time, but not as much less as expected.
When the offsite copy was made, LTO2 to LTO2, I found out why.
For a certain file size, it takes twice as long to back it up for a
compressed file as an uncompressed file.
For more info, on the LTO2 tapes, before we would get just over 700 GB
on them, now just over 200 GB. (Using q vol stats). I kinew it would be
less obviously.
Anybody know why takes twice as long? Is there a way to speed it up?
Thanks,
David Longo
#####################################
This message is for the named person's use only. It may
contain private, proprietary, or legally privileged information.
No privilege is waived or lost by any mistransmission. If you
receive this message in error, please immediately delete it and
all copies of it from your system, destroy any hard copies of it,
and notify the sender. You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient. Health First reserves the right to
monitor all e-mail communications through its networks. Any views
or opinions expressed in this message are solely those of the
individual sender, except (1) where the message states such views
or opinions are on behalf of a particular entity; and (2) the sender
is authorized by the entity to give such views or opinions.
#####################################
This e-mail (including any attachments) is confidential and may be legally
privileged. If you are not an intended recipient or an authorized
representative of an intended recipient, you are prohibited from using, copying
or distributing the information in this e-mail or its attachments. If you have
received this e-mail in error, please notify the sender immediately by return
e-mail and delete all copies of this message and any attachments.
Thank you.
