ADSM-L

Re: [ADSM-L] Internal compression?

2009-06-11 14:36:05
Subject: Re: [ADSM-L] Internal compression?
From: Kelly Lipp <lipp AT STORSERVER DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 11 Jun 2009 12:34:15 -0600
No, this isn't internal compression.  If you look at the sched log for the 
clients, do you see and failed messages?  For instance, let's say you have copy 
serialization set to one of the shared options (sharedynamic, sharestatic).  If 
the client starts to move the file, then it opens, then it closes and the 
client starts again, all the data that is moved (whether successful or not) is 
counted toward the GB transferred number.  I've seen this account for the 
difference between what you think was backed up based on session roll up stats 
and what's migrated or copied during daily processing.

Just an idea.

Kelly Lipp
CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777 x7105
www.storserver.com


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Shawn Drew
Sent: Thursday, June 11, 2009 12:14 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Internal compression?

I noticed some strange data.  I never paid attention to it before, but now
that I noticed it, I find it is the same across all of our TSM instances.
Is there any reason that STGPOOL backups and Migrations would only process
about half the quantity of data that is reported to be backed up?

They are all AIX/TSM 5.4.4 and ALL nodes have "Compression = no" at the
server level


- Quantity of data backed up last night on one small system was 140 GB. (I
manually confirmed this by adding up all the "Total number of bytes
transferred" numbers from the actlog)
select sum(bytes) from summary where activity='BACKUP' and
cast((current_timestamp-END_TIME)days as integer)<1

- Storage pool backups, which run after the client backups only
transferred 68GB (confirmed from adding up the ANR0986I messages from the
actlog)
select sum(bytes) from summary where activity='STGPOOL BACKUP' and
cast((current_timestamp-END_TIME)days as integer)<1

(And yes, I did verify we are backing up all the primary pools that the
backup data could have possibly landed)

- Migration also only transferred 68GB
select sum(bytes) from summary where activity='MIGRATION' and
cast((current_timestamp-END_TIME)days as integer)<1


Run these select statements on your server and see if you see the same
thing.


Regards,
Shawn
________________________________________________
Shawn Drew


This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.