Tim, we recently ran a bunch of tests on client side compression.  In every 
test the backup ran for 2 to 3 times longer.  In some cases this wouldn't be a 
big deal when you look at the backup alone being incremental and all.  However, 
we also believed that it would also cause the restore to run 2 to 3 times as 
long to uncompress the data.  As a result of these tests and thoughts we 
decided not to implement client side compression.

Have you run any tests to see how compression effects your backups and restores?

"Rushforth, Tim" <TRushforth AT WINNIPEG DOT CA> wrote:
We use 5 days for reuse delay. I did a quick comparison using 25GB and 4GB
volumes on our pilot with the following results:

Disk Volumes - 25 GB Volumes

Stored Data - 236 GB
# of Disk Vols - 14 (including 2 pending volumes)
Total allocation - 14 * 25GB = 350 GB
67% Utilization



Disk Volumes - 4 GB Volumes (TSM2)
Stored Data - 333 GB
# of Disk Vols - 100 (including 12 pending volumes)
Total allocation - 100 * 4GB = 400 GB

83% Utilization

Reclamation was set at 25% for both of these.

It would be interesting to see others peoples results.

Thanks,

Tim Rushforth
City of Winnipeg


-----Original Message-----
From: Johnson, Milton [mailto:milton.johnson AT CITIGROUP DOT COM]
Sent: Tuesday, September 21, 2004 1:04 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: D2D on AIX

What do use for a reuse delay? How many pending volumes do you
average?


H. Milton Johnson


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Rushforth, Tim
Sent: Tuesday, September 21, 2004 1:00 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: D2D on AIX

Eliza:

At the Disk only Backups Technical Exchange, IBM recommended 2-4 GB
volume size. (This was stated by the presenter, it was not written on
the PDF
presentation.) We started with 25 GB volumes and have now switched to 4
GB volumes.

Using smaller volume sizes allows a better utilization of space and
increases restore performance with multi-session restore. (Also helps
eliminate contention if multiple clients are restoring from the same
volume)


Tim Rushforth
City of Winnipeg

-----Original Message-----
From: Eliza Lau [mailto:lau AT VTCAT.CC.VT DOT EDU]
Sent: Tuesday, September 21, 2004 11:20 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: D2D on AIX

Eric,

What is the recommended volume size. I have seen someone mentioned 5G,
but then the number of volumes will explode from about 800 (current # of
3590 primary
tapes) to thousands.

How about keeping the staging space so clients backup to staging then
migrate to FILE volumes. Then every volume will be filled up.

Eliza

>
> Hi Eliza!
> You do want several smaller files, rather than a few very large files
> because each client session will allocate a volume. File volumes
> cannot be used concurrently by more than one session.
> Kindest regards,
> Eric van Loon
> KLM Royal Dutch Airlines
>
>
> -----Original Message-----
> From: Eliza Lau [mailto:lau AT VTCAT.CC.VT DOT EDU]
> Sent: Monday, September 20, 2004 19:11
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: D2D on AIX
>
>
> Our 3494 with 3590K tapes in 3 frames is getting full. Instead of
> adding another frame or upgrading to 3590H or 3592 tapes we are
> looking into setting up a bunch of cheap ATA disks as primary storage.
>
> The FILE devclass defines a directory as its destination and JFS2 has
> a max file system size of 1TB. Does it mean the largest stgpool I can

> define is 1TB?
>
> My Exchange stgpool alone has 8TB of data. Do I have to split it up
> into 8 pieces?
>
> server: TSM 5.2.2.5 on AIX 5.2
> database 90GB at 70%
> Total backup data - 22TB
>
> Eliza Lau
> Virginia Tech Computing Center
> lau AT vt DOT edu
>
>
> **********************************************************************
> For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee only. If
you are not the addressee, you are notified that no part of the e-mail
or any attachment may be disclosed, copied or distributed, and that any
other action related to this e-mail or attachment is strictly
prohibited, and may be unlawful. If you have received this e-mail by
error, please notify the sender immediately by return e-mail, and delete
this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its
subsidiaries and/or its employees shall not be liable for the incorrect
or incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
> **********************************************************************
>


---------------------------------
Do you Yahoo!?
vote.yahoo.com - Register online to vote today!