ADSM-L

Re: [ADSM-L] Some advice about compression=yes to perform IMAGE backup

2009-09-20 08:25:35
Subject: Re: [ADSM-L] Some advice about compression=yes to perform IMAGE backup
From: Hans Christian Riksheim <HCR AT STERIA DOT NO>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sun, 20 Sep 2009 14:23:56 +0200
In my experience client side compression on W2K/Intel is quite fast but on AIX 
it is very slow. I have no idea why the difference is so huge.

This poses a problem on AIX when we do client side encryption since compression 
must be done before encryption.

Oracle RMAN has two alternate compression algorithms, the usual one(gzip I 
think) and zlib. The latter is much faster but the compressibility ratio is a 
little lower. I would like to see the TSM client offer an algorithm that takes 
less toll on CPU at the expense of compressibility.

Hans Chr.


________________________________

Fra: ADSM: Dist Stor Manager på vegne av Stefan Holzwarth
Sendt: sø 2009-09-20 13:43
Til: ADSM-L AT VM.MARIST DOT EDU
Emne: AW: Some advice about compression=yes to perform IMAGE backup



I'm a big fan of compression at the client side!

Compression at the client could even give you better performance.
It depends on the data and your environment.

Some pro's for client side compression:

Disk Storage pools at TSM server are more effective because there is more space
Only option if you have no tapes with hardware compression
Less IO at the TSM server (backup copypool, migration, reclamation)
Most CPUs in physical servers are underutilized and very powerful
Less network bandwidth needed (some of the possible bottlenecks)
We have very good experience with SQL TDP compression rates


Regards
Stefan Holzwarth

> -----Ursprüngliche Nachricht-----
> Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im
> Auftrag von Skylar Thompson
> Gesendet: Sonntag, 20. September 2009 06:25
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: Re: Some advice about compression=yes to perform IMAGE backup
>
> admbackup wrote:
> > Hi.
> >
> > I am need some advice about using compression=yes for image backups
> >
> >
> > I need to perform image backups of mulitple disks on a
> windows 2008 server.  Most of them have like 1.45T of size.
> >
> > We are running out of tapes and I was thinking in using
> compression.  I know that it is recommended to set
> compressalways=yes on the TSM server when using compression,
> but I am not using compression for all the backups.  Is this
> parameter transparent for the client servers that dont use
> compression=yes?
> >
> > Also, how recommended is using compression for image
> backups??  I know that it is going to increasse the time that
> the backup takes but I have a lot of time windows to perform
> those image backups (All the weekend)
> >
>
> What kind of tapes do you use? You should probably stick with hardware
> compression if you can. Remember to not only think of the
> amount of time
> the backup takes, but the amount of time the restore is going to take.
> Hardware compression is going to take buy you performance,
> but software
> compression is going to lose you performance.
>
> --
> -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> -- Genome Sciences Department, System Administrator
> -- Foege Building S048, (206)-685-7354
> -- University of Washington School of Medicine
>



This email originates from Steria AS, Biskop Gunnerus' gate 14a, N-0051 OSLO, 
http://www.steria.no. This email and any attachments may contain 
confidential/intellectual property/copyright information and is only for the 
use of the addressee(s). You are prohibited from copying, forwarding, 
disclosing, saving or otherwise using it in any way if you are not the 
addressee(s) or responsible for delivery. If you receive this email by mistake, 
please advise the sender and cancel it immediately. Steria may monitor the 
content of emails within its network to ensure compliance with its policies and 
procedures. Any email is susceptible to alteration and its integrity cannot be 
assured. Steria shall not be liable if the message is altered, modified, 
falsified, or even edited.