My little input to your miracle: Maybe switching to an domainuser alters the kind the tsm client uses to save the data. As an administrator he should use the backup api. As an domain usser he can only use cifs access.
Kind Regards, Stefan Holzwarth -----Ursprüngliche Nachricht----- Von: Alex Paschal [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 1. Oktober 2003 21:02 An: [EMAIL PROTECTED] Betreff: Re: Incremental backups on file systems that contain a large numb er of files Michael, that's weird. I believe you, but I just had to say that it's weird. Mark, for AIX, since there's no journaled backups there, have you considered -incrbydate's during the week, then a regular incremental on the weekend? This greatly sped up the backup of one of our very large file systems on AIX. Alex Paschal Freightliner, LLC (503) 745-6850 phone/vmail -----Original Message----- From: Wheelock, Michael D [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 8:07 AM To: [EMAIL PROTECTED] Subject: Re: Incremental backups on file systems that contain a large numb er of files 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 9:57 AM To: [EMAIL PROTECTED] 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 <[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 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).