Tom,
It wasn't a study, but a series of observations based on some testing
that I did. I've maintained that one can create somewhere between 50K
and 100K files/hour on windows. Looking at your restore time of 60
hours, I'm thinking you're in the 50K range. I think that Windows 2003
R2 latest version may well run faster than that on fast hardware, but
have not really done enough new studying to know. But your example
furthers my assertion.
Image restore would help. You could probably get more than 2000000
files from the image and maybe 100K from traditional backup. And all
the directories (or at least most) will be created.
And we do know that the directory does not have to exist before a file
can be restored. If the client has a file to restore and the directory
does not exist, the client will create the directory. If there is any
specific directory information, such as an ACL, then that will get fixed
up when the client finds the backup for that directory entry.
Kelly J. Lipp
VP Manufacturing & CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777
lipp AT storserver DOT com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Kauffman, Tom
Sent: Tuesday, August 28, 2007 11:57 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Looking for suggestions to speed up restore for a
Windows server
Oh the bottleneck is definitely file create --
The top three directories (drive letters):
Z -- userhome -- 764,184 files, 60,281 directories Y -- 'data' --
636,514 files, 47,144 directories W -- 'engineering' -- 745,976 files,
134,863 files
The TSM server is spending all it's time in SENDW, except for the
roughly 2 hours (over the course of 60) that it was in mediaw waiting to
get to the directory structure on the other tape pool. And I've got some
ideas from Richard that will cut that right out.
I seem to recall someone actually running a study on restore performance
vs file count; I'm trying to find it in the mail archives.
Maybe an image backup would help -- this is an active/passive windows
cluster and 'offline' is not an available backup option. Can I get away
with an online image backup?
Also -- we restore to unlike hardware at the hot site (install Win2003
server, install TSM client, restore) -- would this be an issue for an
image restore?
Thanks --
Tom
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Kelly Lipp
Sent: Monday, August 27, 2007 5:40 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Looking for suggestions to speed up restore for a Windows
server
How about periodic Image backups of the file server volumes? Couple
that with daily traditional TSM backups and perhaps you have something
that works out better at the DR site.
The problem is as you described it: lots of files to create. Did you
observe that you were pecking through tapes, or was the bottleneck at
the file create level on the Windows box? Or could you really tell?
Even if you create another pool for the directory data (which is easy to
implement) you would still have that stuff on many different tapes.
What about a completely new storage pool hierarchy for that one client?
And then aggressively reclaim the DR pool to keep the number of tapes at
a very small number.
I'd really like to know where the bottleneck really was. If it's file
create time on the client itself, speeding up other things won't help.
If that's the case, then I like the image backup notion periodically.
Even if you did this once/month, the number of files that you would
restore would be fairly small compared to the overall file server. And
the TSM client does this for you automagically so the restore isn't
hard.
And this also brings up the fact that a restore of this nature in the a
non DR situation probably isn't much better!
Thanks,
Kelly
Kelly J. Lipp
VP Manufacturing & CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777
lipp AT storserver DOT com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Kauffman, Tom
Sent: Monday, August 27, 2007 12:40 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Looking for suggestions to speed up restore for a
Windows server
We had our fall D/R hotsite test last week and all went well -- except
for the recovery of our primary Windows 2003 file sharing system. It
just takes WAY too long.
Part of the problem is the sheer number of files/directories per drive
-- I'm working with the Intel/Windows admin group to try some changes
when we swap this system out in November.
Part of the problem is that the directory structure is scattered over a
mass of other backups. I'm looking for suggestions on this.
The system is co-located by drive, but only for five of the nine logical
drives on the system. I may have to bite the bullet and run all nine
logical drives through co-location.
Is there any way to force the directory structure for a given drive to
the same management class/storage pool as the data? I'm thinking I may
have finally come up with a use for a second domain, with the default
management class being the one that does co-location by drive. If I go
this route -- how do I migrate all of the current data? Export/Import?
How do I clean up the off-site copies? Delete volume/backup storage
pool?
I'm on TSM Server 5.3.2.0, with a 5.3 (not sure of exact level) client.
TIA
Tom Kauffman
NIBCO, Inc
CONFIDENTIALITY NOTICE: This email and any attachments are for the
exclusive and confidential use of the intended recipient. If you are
not the intended recipient, please do not read, distribute or take
action in reliance upon this message. If you have received this in
error, please notify us immediately by return email and promptly delete
this message and its attachments from your computer system. We do not
waive attorney-client or work product privilege by the transmission of
this message.
CONFIDENTIALITY NOTICE: This email and any attachments are for the
exclusive and confidential use of the intended recipient. If you are
not the intended recipient, please do not read, distribute or take
action in reliance upon this message. If you have received this in
error, please notify us immediately by return email and promptly delete
this message and its attachments from your computer system. We do not
waive attorney-client or work product privilege by the transmission of
this message.
|
