What do you mean saing "full backup"?
If you check "dsmc query systemstate -inactive -detail", you will see that all
backups are full. But full has relationship with VSS writes in Windows and it
has no relationship with TSM full/incremental terms. If you will check sizes in
the same report for new server (backup implemeted recently) , you will see
quite big first backup and much smaller following backups.
Of course, you will see full backup in case of any changes in SYSTEMSTATE (SP
installation and etc).
Note, that it is true for TSM Client 5.x, but TSM Client 6.1.0.X has problem
with SYSTEMSTATE backups - they are alaways full in TSM. I have opened case
with TSM support and development team confirmed a bug and fix has been provided
in TSM 6.1.2.0 for Windows annonced recently. The same fix will be in future
TSM 6.1.3 planned for the end of this year.
________________________________________
From: ADSM: Dist Stor Manager [ADSM-L AT VM.MARIST DOT EDU] On Behalf Of Wanda
Prather [wanda.prather AT JASI DOT COM]
Sent: Thursday, November 05, 2009 10:29 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Win2008 System State
Yes, systemstate backups have always been fulls. (I believe there was some
mumbling about Win2K3 changing something to make it possible to do
incrementals instead of fulls, but I've never seen any difference, and no
further mumbling has ensued...sort of like the mumbling that told us Vista
would be better than those XP annoyances...)
What you have NOT mentioned is the impact of SystemState backups on the TSM
DB, because in WIn2K the systemstate backup is at least 2000 objects. Per
systemstate backup, meaning per day. Couple thousand more for 2003.
Anybody figured out the number for 2008?
I've had customers where I've found a SUBSTANTIAL percentage of their TSM DB
taken up with (pretty useless) system state backups, with just WIn2K and
Win2K3. Win2008 will blow up a lot of TSM data bases, looks like.
And I've recently run into customers that have put WIndows on the C: drive,
installed their Apps (including TSM) on the D: drive. But adsm.sys always
goes on the boot (C:) drive, which then frequently runs out of disk space,
causing the backup schedule to fail.
The only defences I've come up with:
1) turn off the systemstate backup with DOMAIN -systemstate, and add
preschedulecmd to invoke ntbackup of systemstate to a flat file, which can
be directed to any drive, not just C: ALso has the advantage that
systemstate becomes ONE object, not thousands
2) bind systemstate backups to a mgmt class that keeps only a limited number
of versions, especially if in a client domain with otherwise long retention
times.
It should be getting obvious to development that this architecture is
doomed, and not gonna work for folks in the long term. Benefits we pick up
with the DB performance improvements in 6.1 (yes, it does run really really
fast!), will be immediately swallowed up by Win2008 system state....
W
On Thu, Nov 5, 2009 at 1:10 PM, Ben Bullock <BBullock AT bcidaho DOT com> wrote:
> So, we all seem to agree that the Windows 2008 SystemState is very large
> (seems to be about 6GB on a fresh 2008 R2 installation), but is there
> anything we can do about it?
>
> It looks like it does a FULL copy of everything in the SystemState every
> night. I've never really paid attention to the SystemState backups, is that
> the way it's always worked? A FULL every night? No TSM incremental-forever
> magic?
>
> OK, so if we are saying "that's just how it's going to be" what are folks
> doing about it? There seems to be a few possible issues:
> - Bandwidth issues to clients with slow connections.
> - The size in the storagepools of those larger SystemStates.
> - The lengthening of the backup windows on all hosts because of the
> time needed to check/backup the systemstate.
>
> Changing the retention policy or dedupe can help with the large size
> they will take on disk/tape, but I'm not sure what can be done about the
> other 2 issues?
>
> We are rolling out a bunch of 2008 servers and as each host is
> upgraded, the backup goes from 5 minutes to ~1 hour to backup. My TSM server
> is going to get hammered: number of serviced connections are going to go way
> up as connections linger longer, the amount of data sent from the TSM server
> to the client to compare is now ~400MB, hitting the TSM DB pretty hard,
> overall TSM server performance is going to suffer and I might have to buy
> more horsepower/storage just to support the 2008 SystemState.
>
> Options? Anyone? Anyone? Buhler?
>
> Does TSM have some magic up it's sleeve in a future version that can help
> us? (I just started testing the 6.1.2 version that just came out, but it
> behaves the same with the systemstate).
>
> About all I can think of is not backing up the systemstate or perhaps only
> backing it up once a week, but neither of those are good options.
>
> Anybody else concerned about this or am I just being "the boy who cried
> ARMAGEDDON"?
>
> Ben
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Andrew Raibeck
> Sent: Wednesday, October 28, 2009 3:38 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Win2008 System State
>
> I am not aware of any links off-hand to any official Microsoft statements.
> Why would your customer doubt this? Alternatives that come to mind:
>
> - Take a look at the install footprint of a base Windows 2003 vs. Windows
> 2008:
> Windows 2003: C:\Windows has 16,000 files/3 GB
> Windows 2008: C:\Windows has 71,000 files/15 GB
>
> There are, of course, other files, but the size of C:\Windows alone is very
> telling.
>
> - If you do a google search on "windows 2008 system state size", you'll
> probably find some credible, albeit anecdotal evidence of the size.
>
> - If you run a TSM backup-archive client "backup systemstate" command,
> you'll see the size.
>
> - If you get the VSS SDK, it comes with the vshadow.exe tool that you can
> use to get a sense of the size:
>
> vshadow -p -wm2 > youroutputfile
>
> Then review the output. Run the same command on Windows 2003 and compare
> the sizes. There is clearly a lot more in the 2008 version.
>
> - If your customer needs to hear it from Microsoft, then perhaps this is a
> question to ask directly of Microsoft.
>
> Best regards,
>
> Andy
>
> Andy Raibeck
> IBM Software Group
> Tivoli Storage Manager Client Product Development
> Level 3 Team Lead
> Internal Notes e-mail: Andrew Raibeck/Hartford/IBM@IBMUS
> Internet e-mail: storman AT us.ibm DOT com
>
> IBM Tivoli Storage Manager support web page:
>
> http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html
>
>
> The only dumb question is the one that goes unasked.
> The command line is your friend.
> "Good enough" is the enemy of excellence.
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 10/28/2009
> 10:46:19 AM:
>
> > [image removed]
> >
> > Win2008 System State
> >
> > Christian Svensson
> >
> > to:
> >
> > ADSM-L
> >
> > 10/28/2009 10:47 AM
> >
> > Sent by:
> >
> > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> >
> > Please respond to "ADSM: Dist Stor Manager"
> >
> > Hi Guys,
> > Does anyone have a link to Microsoft where it says that Win2008
> > System State Backup is much bigger then Windows 2003 System State?
> > I need to prove for a customer that System State and System Services
> > is much bigger now with Windows Server 2008 and we need to setup
> > some policies for System State?
> >
> >
> > Best Regards
> > Christian Svensson
> >
> > Cell: +46-70-325 1577
> > E-mail: Christian.Svensson AT cristie DOT se
> > Skype: cristie.christian.svensson
>
Please consider the environment before printing this Email.
"This email message and any attachments transmitted with it may contain
confidential and proprietary information, intended only for the named
recipient(s). If you have received this message in error, or if you are not the
named recipient(s), please delete this email after notifying the sender
immediately. BKME cannot guarantee the integrity of this communication and
accepts no liability for any damage caused by this email or its attachments due
to viruses, any other defects, interception or unauthorized modification. The
information, views, opinions and comments of this message are those of the
individual and not necessarily endorsed by BKME."
|
