ADSM-L

Re: [ADSM-L] NetApp backup takes too long

2007-12-06 14:58:18
Subject: Re: [ADSM-L] NetApp backup takes too long
From: "Haberstroh, Debbie (IT)" <HABERDE AT VOUGHTAIRCRAFT DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 6 Dec 2007 13:57:42 -0600
Thanks Neil.  I had read about this in 5.4 but am still at 5.3.3 due to old 
Lan-free clients.  It would be a good reason to pursue the upgrade though.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Strand, Neil B.
Sent: Thursday, December 06, 2007 10:06 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] NetApp backup takes too long


Debbie,
   TSM V5.4 introduced NDMP backup via ethernet from the NetApp to the
TSM server, removing the need for a tape drive to be attached to the
NetApp.  It greatly simplifies the NDMP configuration and allows
significantly better TSM management of backup data than the previous
method.
   I am using this method of backing up LUN snapshots and it works very
well.  I am planning to move my NAS shares to this method.
   If you are allowed an ethernet connection to the filer, you may be
able to use this method to your advantage.

Cheers,
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Haberstroh, Debbie (IT)
Sent: Thursday, December 06, 2007 8:55 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] NetApp backup takes too long

Good morning,

I could use some suggestions for improving the backup time for our
Network Appliance.  Below is the write up that my Sys Admin submitted
describing the problem.  Thanks for the help.

Situation:  We have a Network Appliance (NAS) hosting approximately 8
million Windows files (CIFS).  Due to disk constraints, we are not able
to use snapshots and due to some other customer induced limitations, we
cannot use NDMP for backups.  We have implemented a "proxy"/redirection
server that backs up the CIFS files via a unc path name to a TSM 5.33
host running AIX.  Our issue is in walking through 8 million files per
night in a backup job.  The nightly backup delta is approximately 40GB.
However, just to access and check 8 million files to see if they meet
the backup criteria is taking too much time.  The CIFS backup is split
into 3 separate batch jobs that run simultaneously.  The longest job
(about 3 million files) takes almost 20 hours to run.  Would NIC teaming
gain us any time savings during the backup?  I feel the bottleneck may
be our AIX system since the Windows server has to get the meta data for
the CIFS file, check it against the TSM database, and determine if that
file needs to be backed up.  That is a lot of traffic between Windows
host, TSM server, and Network Appliance for every single file.  During
the backup time, the CPU is at about 70% on the Windows host, and the
NIC is rarely higher than 50%.

TSM Server Information:
We are running TSM 5.3.3 on AIX 5.3.  The server is an IBM 7026-6H1, 4
processors and only 2 Gb Ram.  The TSM database is almost 200 Gb with
300 clients.

Windows Server Information:
We are currently using the Windows TSM client version 5.33c under
Windows 2003 Server Standard Edition on an HP DL380 dual 2.8 GHz Xeon
processor with 2.5 GB of RAM.  We have three batch files running the
DSMC command line utility scheduled by the Windows scheduler.  We have a
dual port HP NC7781 NIC card.  We are using only one port connected at
1GB.


Debbie Haberstroh

IMPORTANT:  E-mail sent through the Internet is not secure. Legg Mason 
therefore recommends that you do not send any confidential or sensitive 
information to us via electronic mail, including social security numbers, 
account numbers, or personal identification numbers. Delivery, and or timely 
delivery of Internet mail is not guaranteed. Legg Mason therefore recommends 
that you do not send time sensitive 
or action-oriented messages to us via electronic mail.

This message is intended for the addressee only and may contain privileged or 
confidential information. Unless you are the intended recipient, you may not 
use, copy or disclose to anyone any information contained in this message. If 
you have received this message in error, please notify the author by replying 
to this message and then kindly delete the message. Thank you.