ADSM-L

Re: Issues with Win2K SYSTEM OBJECT/SYSTEM FILES backup

2001-06-01 16:50:35
Subject: Re: Issues with Win2K SYSTEM OBJECT/SYSTEM FILES backup
From: Robin Sharpe <Robin_Sharpe AT BERLEX DOT COM>
Date: Fri, 1 Jun 2001 16:51:02 -0400
Question: Are these files unique on each node?
If no, then why not make just one ( or a couple) backups from a "reference"
machine, and exclude them from all other nodes.
If yes, then include them to a retain-forever management class the first
time only, then exclude them in the future.  The first time copies will
become inactive, but will be retained forever due to the special management
class.

Just some off-the-cuff suggestions.... we're still on NT4, and we only
backup servers, not desktops.  But I agree this seems like a serious
problem that you should not have to "work around".  Hope it gets fixed
before we go to Win2K next year...

Robin Sharpe
Berlex Laboratories




                    "Prather, Wanda"
                    <Wanda.Prather@J
                    HUAPL.EDU>       To:    ADSM-L AT VM.MARIST DOT EDU
                                     cc:    (bcc: Robin Sharpe/WA/USR/SHG)
                    06/01/01 04:23   Subject:
                    PM                      Issues with Win2K SYSTEM 
OBJECT/SYSTEM FILES backup
                    Please respond
                    to "ADSM: Dist
                    Stor Manager"







I have run into some ugly issues with the Win2K backup of the "SYSTEM
OBJECT".

I'm throwing the information out here to warn other people what to expect,
and hopefully to get the developers to reconsider the current
implementation.

The SYSTEM FILES component of the "SYSTEM OBJECT"  on Win2K consists of
over
1500 .dll and .exe and .obj files from (mostly) the WinNT/system32
directory.  These files are backed up EVERY TIME an incremental is run,
even
though THE DATA HAS NOT CHANGED.

We have converted over 200 NT desktops to WIn2K PRO.  For each of our Win2K
PRO systems, this adds 1586 files to the backup every night.

This has had an enormous impact on the TSM server.  The additional data is
only about 20 GB per night, and that's not a big problem.  But each of the
SYSTEM FILES still has it's own entry in the TSM data base.

You do the math:  That's over 300,000 additional objects that get added AND
deactivated each day, which for me means an additional 2.5 HOURS of EXPIRE
INVENTORY time is needed DAILY.  And all for data THAT HAS NOT CHANGED.

TSM's strength has always been that it DOESN"T back up unchanged data.
Well, at least it didn't used to...

My problem here is we have another 250 machines to convert from NT to
WIn2K.
They aren't about to buy me a second TSM server to handle the load, when
the
current one worked fine for backing up the same number of NT systems with
the same amount of user data.  Instead they are looking at some
Windows-only
software to back up the WIndows side of the house.

It appears to me the current TSM implementation is flawed, and will inhibit
other people's ability to support large Windows environments as well as
ours.

I put this information into the Requirements for the Oxford Symposium,
hopefully it will give some additional visibility to the issue.

Any suggestions welcome ....but don't suggest we give up our ability to do
full bare-metal restores.
Management will change the backup software first.

************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************