Hi,

I will throw this out there, though it is a wintel solution and will not
function as a solution under aix.  We had a system with about 3 million
files.  The disk was SAN attached and quite speedy.  The system was
gig-ethernet attached and had no cpu/memory bottlencks.  Journaling wasn't
an option as this was a clustered system.  The incremental backup (all 400MB
of it) took around 10 hours for these 3 million files.  I tried just about
everything, but at various points, the backup would slow to a crawl (just
from doing an analysis on the entries in the dsmsched.log (the timestampe --
### files processed entries)).  I eventually began trying off the wall
stuff.  The thing that fixed us up was running the scheduler as a domain
user.  The backup now takes 45 minutes.  I have no idea why, but this may
help someone else on a wintel platform deal with a very similar issue.

Michael Wheelock
Integris Health of Oklahoma



-----Original Message-----
From: asr AT UFL DOT EDU [mailto:asr AT UFL DOT EDU]
Sent: Wednesday, October 01, 2003 9:57 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Incremental backups on file systems that contain a large number
of files


=> On Wed, 1 Oct 2003 09:27:41 -0400, Mark Trancygier
<TrancygM AT TRINITY-HEALTH DOT ORG> said:


> We are currently having problems performing incremental backups on a
> file system that has a large amount of files. The daily changes to
> this file system are small so we are only sending approximately 5 - 10
> gig per backup however, since there are around 3,000,000 files to
> examine, the backup takes about 10 - 13 hours to complete.

> Does anyone have any suggestions on how to handle incremental backups
> of file systems that contain a large number of I-nodes ?


We've got several systems with lots of files, including 3 between 10 and 15
million files.

Key thing is to figure out where your bottleneck is; if you're having
problems with client disk contention, one set of things are useful.  If
you're having TSM database contention problems, another set is indicated.

I'll talk about the different strategies we've phased through.

We've got a large number of virtual mount points defined, so that our work
is chopped up into chunks of approximately 700,000 files each.  This lets us
run a large number of parallel sessions (e.g. resourceutilization=10, or
many heavyweight processes) at the same time.

If you have disk contention problems on your client system, however, this
will make your problem worse, not better.  Our disk architecture is such
that we weren't getting in our own way.

On the client, that is.

What we determined was that lots of actors interested in writing to the TSM
DB simultaneously was our big problem.  When we ran with a parallelism of
four or five, an incremental took seven to 15 hours.  When we ran with a
parallelism of two, it completed in 4.

Of course, for those 7-15 hours, it was also making life hell for anything
else that wanted to update the database (Expiration anyone?) so we're
currently backing those bits up in separate windows, with a server that's
mostly otherwise quiet.



- Allen S. Rout
This e-mail may contain identifiable health information that is subject to 
protection
under state and federal law. This information is intended to be for the use of 
the
individual named above. If you are not the intended recipient, be aware that any
disclosure, copying, distribution or use of the contents of this information is 
prohibited
and may be punishable by law. If you have received this electronic transmission 
in
error, please notify us immediately by electronic mail (reply).