There are very good reasons to do compression in software on the client.
Fundamentally it is a tradeoff between ADSM client CPU cycles and I/O ops on
ADSM client, intervening network, and ADSM server. Your priorities and
circumstances will dictate your solution.
The CPU time is spent (usually only) once when you compress it on the client
(you restore and thus decompress only a fraction of what you compress).
The compressed data can save many I/O operations in its travels, especially
with ADSM:
1) over the network from ADSM client to ADSM server
2) to a primary disk pool on the ADSM server
3) backed up from primary disk to copy tape
4) migrated from primary disk to primary tape
Although the compression cycles by the tape drive are "free" relative to the
compression cycles on the client, you have to take into account all the extra
I/O operations performed by your ADSM server moving non-compressed data. More
often than not ADSM servers become I/O bound first. Also, clients often have
free CPU cycles available at backup time.
Of course, situations must be evaluated on their details. I just wanted to
point out other issues involved in making the client compression decision.
Here's a concrete example:
BACKINT getting 2.9:1 compression (decreasing to 2.5:1 as data loads take
place) on a 90 GB SAP Oracle DB using only a empty block compression that is
useful for databases. Tape drives get a further 1.5:1 compression on the
remaining non-zero data (30 GB on 20 GB tapes). Daily fulls producing only
30-35 GB worth of I/O's in each of the above 1-4 operations instead of 90 GB.
Number of streams of backup (BACKINT allows N streams with a multiplicity of M
files per stream for a total of (N x M) DB files being backed up into N ADSM
client sessions concurrently)
were adjusted so that CPU time on client (8-way SMP) was just brought to 100%
busy. N=14 and M=3 (or N=16 as well) achieved this on an S7A to local ADSM
server using TCP/IP (not SHM). Lower N and M left CPU's not busy on an
otherwise idle system (SAP/Oracle are down cold for backup).
Cheers...
Bruce
P.S. wrt the drive images of ADSM DR for Intel IDE hard drives, it is very
possible that the image is very compressible; however, those backups are
'cold' wrt O/S being up so downtime to compress may become an overriding
factor.
Joshua Bassi wrote:
> Hardware compression would be your best bet.
>
> --------------------------------------------------------------------------
> Joshua Bassi E-mail: jbassi AT gloryworks DOT
> com
> Storage Management Team Lead Cellular/VM: (408) 836-7147
> Dickens Services Group Internet: www.TeamDSG.com
> --------------------------------------------------------------------------
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Edouard Lauer
> Sent: Wednesday, April 21, 1999 11:50 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: DRM backup image - Compression?
>
> Hello,
>
> If we use DRM for our Windows NT machines the size of the image backed
> up on our server is the same size as the physical partition size of the
> disk. I
> understand that this is normal but isn't there the possibility to use
> compression
> because we have other disks which have 20Gbytes on which only 2Gbytes
> are useable.
>
> Thanks for you help,
> Edi Lauer
> elauer AT pt DOT lu
--
Bruce Elrick, Ph.D.
Bruce Elrick, Ph.D.
mailto:belrick AT home DOT com
http://members.home.net/belrick/
|
