Whenever I've installed a STORServer at a customer site I've advocated
the following:
The next time a new piece of server hardware shows up in your site,
steal it for a couple of weeks. Use it as a test bed. Try some
restores, try some backups, get to know your environment.
Customers always want to test restores during a STORServer install.
Surprise, surprise, these always work very well and they are very fast!
But what happens over time? In Tom's case, his fileserver backups had
probably spanned many months if not longer. Data is all over the place:
disk pools, tape pools, etc. Is it any surprise there were issues? No.
The surprise was the surprise!
Next time that new hardware arrives, set it up in your office and try
restoring some big thing just to get a baseline. Be methodical. Note
what happened. Capture the activity log. Share with the list as Tom is
doing. We all learn from this.
Learning while somebody is standing over you asking when the restore
will be complete is not conducive to the process. Back to that old
adage:
"When you are up to your ass in alligators, it's hard to remember that
your job was to clear the swamp."
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: Wednesday, August 29, 2007 9:41 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Looking for suggestions to speed up restore for a
Windows server
I'm just looking at the image backup now. This may well be the way to
go.
Would you believe -- we are JUST getting a Windows test environment set
up here. We've had several rounds of admins who couldn't see the value
and weren't interested in doing the work, just to have a test-bed.
Current staff actually has a clue!
I want to see some test runs -- the 'engineering' drive, with all those
files and directories, is only 48 GB. Should process nicely on image
backup/restore.
Also, we're moving to a vmware esx environment, and I'm suggesting a
separate 'server' for each of these file systems.
Thanks, all.
Tom
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Wanda Prather
Sent: Wednesday, August 29, 2007 10:56 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Looking for suggestions to speed up restore for a Windows
server
Always test first, but:
1) Since the 5.3 (or maybe it was 5.2, don't remember) Windows client,
you can do online image backups. The MS VSS facility (if it's having a
good
day) is used to snapshot the volume.
2) I don't think there is a problem with restoring an image to a
different host, if you aren't messing with the C: drive.
ANybody have different results?
> 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.
>
>
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.
|
