=> 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