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:AlexPaschal AT FREIGHTLINER DOT COM]
Gesendet: Mittwoch, 1. Oktober 2003 21:02
An: ADSM-L AT VM.MARIST DOT EDU
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:Michael.Wheelock AT INTEGRIS-HEALTH DOT COM]
Sent: Wednesday, October 01, 2003 8:07 AM
To: ADSM-L AT VM.MARIST DOT EDU
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: 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).
|
