Thanks Allen. I think the virtualmountpoint option will be the best way to go, as we have a pretty hearty SAN environment and I don't believe we have client disk contention. Are you aware of any limitations on the number of virtualmountpoints per client ?
Thanks, Mark. >>> [EMAIL PROTECTED] 10/01/03 10:57AM >>> => On Wed, 1 Oct 2003 09:27:41 -0400, Mark Trancygier <[EMAIL PROTECTED]> 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
