ADSM-L

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

2007-12-09 05:31:11
Subject: [ADSM-L] AW: AW: AW: NetApp backup takes too long
From: Stefan Holzwarth <stefan.holzwarth AT ADAC DOT DE>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sun, 9 Dec 2007 11:30:32 +0100
The actual tsm journaling agent watches for local disk io. So it has to be run 
on the system, that does the io - the nas device.
Since EMC or Netapp do not open their appliances to run agents for watching io 
there is no way.
Both provide an api (I believe its named content api) that provides external 
virus scanners with informations about what should be checked in realtime. If 
TSM journaling agent would support that api, it should work. You could even 
implement a kind of cdp (continuous data protection).
Regards
Stefan Holzwarth

> -----Ursprüngliche Nachricht-----
> Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im 
> Auftrag von Wanda Prather
> Gesendet: Samstag, 8. Dezember 2007 20:41
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: Re: AW: AW: NetApp backup takes too long
> 
> Yes, but in this case the TSM backup client is actually 
> running on a Windows
> host, yes?
> Can journaling be implemented in this case?
> 
> 
> 
> On 12/7/07, Stefan Holzwarth <stefan.holzwarth AT adac DOT de> wrote:
> >
> > Netapp (or EMC NAS) devices do not allow to run journaling agents.
> > Regards
> > Stefan Holzwarth
> > > -----Ursprüngliche Nachricht-----
> > > Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im
> > > Auftrag von Steve Stackwick
> > > Gesendet: Donnerstag, 6. Dezember 2007 16:41
> > > An: ADSM-L AT VM.MARIST DOT EDU
> > > Betreff: Re: AW: NetApp backup takes too long
> > >
> > > You could also investigate journaling on the Windows 
> server. If the
> > > number of files changing daily is small, journaling could 
> cut down on
> > > the "noodle through the filesystem" delay that you're seeing.
> > >
> > > Steve
> > >
> > > On 12/6/07, Stefan Holzwarth <stefan.holzwarth AT adac DOT de> wrote:
> > > > We had a similiar setup and used 5 backupjobs for each
> > > volume at the same time.
> > > > For every volume of the nas server we split the work logicaly.
> > > > So batch 1 took all directories starting with a-e, bath 2
> > > all from f to h,....
> > > > We could backup our nas device in about 12 hours with 
> 11mio files.
> > > >
> > > > Regards
> > > > Spex
> > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im
> > > > > Auftrag von Haberstroh, Debbie (IT)
> > > > > Gesendet: Donnerstag, 6. Dezember 2007 14:55
> > > > > An: ADSM-L AT VM.MARIST DOT EDU
> > > > > Betreff: 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
> > > > >
> > > >
> > >
> > >
> > > --
> > > Stephen Stackwick
> > > Jacob & Sundstrom, Inc.
> > > 401 East Pratt St., Suite 2214
> > > Baltimore, MD 21202-3003
> > > (410) 539-1135 * (866) 539-1135
> > > sstackwick AT jasi DOT com
> > >
> >
>