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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] Im > > Auftrag von Steve Stackwick > > Gesendet: Donnerstag, 6. Dezember 2007 16:41 > > An: [email protected] > > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] Im > > > > Auftrag von Haberstroh, Debbie (IT) > > > > Gesendet: Donnerstag, 6. Dezember 2007 14:55 > > > > An: [email protected] > > > > 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 > > [EMAIL PROTECTED] > > >
