ADSM-L

Re: [ADSM-L] Do you perform Windows SYSTEMSTATE backups?

2012-07-26 03:06:49
Subject: Re: [ADSM-L] Do you perform Windows SYSTEMSTATE backups?
From: Grigori Solonovitch <Grigori.Solonovitch AT AHLIUNITED DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 26 Jul 2012 09:54:13 +0300
I am very sorry, but I am a little bit confused by discussion about SYSTEMSTATE 
backup. We are backing up SYSTEMSTATE for Windows 2003 (all editions) and 
Windows 2008 (all editions) with the latest patches and VSS hot fixes without 
any problems (TSM Client 6.2.4.0 and TSM Server 5.5.6). We have restored 
successfully a few servers after real Windows disaster. In addition, we are 
testing Windows image restores periodically. As a small problem I can declare 
only huge number of files in Windows 2008 SYSTEMSTATE. It delays incremental 
backups checking all files without backing up them (finally must of the files 
are re-assigned with message like " ANS4085I Assigned '82817' objects from 
previous systemstate backup to the new systemstate backup.")

Grigori G. Solonovitch
Senior Technical Architect  Ahli United Bank Kuwait  www.ahliunited.com.kw

Please consider the environment before printing this E-mail


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Roger Deschner
Sent: 26 07 2012 8:54 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Do you perform Windows SYSTEMSTATE backups?

We do not back up the Windows System State, and I run a program to find them, 
delete them, and change the cloptset for offending nodes to one that forbids 
it. The problem started with Vista, and it hit us real hard. It's a problem 
that keeps on giving, as people gradually upgrade from XP to Win7 and from 
Server 2003 to Server 2008.

A pet peeve of mine in this regard is that XP calls it "System Object", and TSM 
very inflexibly enforces this semantic detail. If you assign a
Vista+ node to a cloptset that contains DOMAIN -SYSTEMOBJECT you get a
fatal error and no backup. If you assign an XP node to a cloptset that contains 
DOMAIN -SYSTEMSTATE you also get a fatal error. TSM should accept SYSTEMSTATE 
and SYSTEMOBJECT as aliases for one another. This would save me a 
***___HUGE___*** amount of time and effort.

The difference in whether or not you can handle it, is the TSM server version, 
as well as the client version. In general, neither V5 servers nor V5 clients 
can handle System State backup, while V6.2.3+ servers can deal with it 
reasonably well if the client is also V6.2.3+. This is IBM's recommendation.

We have never found the System Object/State backup to be useful for a desktop 
node restore. OTOH if the node is a server, we have started to back up the 
System State to our new V6.2.3 server using V6.2.4+ clients.
We continue to absolutely forbid System State backups on our old V5.5 servers. 
They simply cannot handle it.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
"My business, is to teach my aspirations to conform themselves to fact, not to 
try and make facts harmonize with my aspirations."
-- Thomas Huxley, 1860


On Wed, 25 Jul 2012, Zoltan Forray wrote:

>We are constantly seeing problems with Windows VSS and systemstate
>backups.  The recent "black Tuesday" updates has causes numerous
>Windows servers to start having backup problem where they previously
>worked just fine.
>
>In most cases they require the VSS hotfixes/fixpacks, etc.  The
>quickest fix is to simply stop systemstate backups since VSS patches
>usually require reboots.
>
>I bought up the issue of "have we ever restored the systemstate or any
>objects within" and the response was "No, Never".
>
>So I am wondering, how many folks here who backup Windows servers,
>include SYSTEMSTATE backups and why?
>
>--
>*Zoltan Forray*
>TSM Software & Hardware Administrator
>Virginia Commonwealth University
>UCC/Office of Technology Services
>zforray AT vcu DOT edu - 804-828-4807
>Don't be a phishing victim - VCU and other reputable organizations will
>never use email to request that you reply with your password, social
>security number or confidential personal information. For more details
>visit http://infosecurity.vcu.edu/phishing.html
>


Please consider the environment before printing this Email.

CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail 
message and any attachments hereto may be legally privileged and confidential. 
The information is intended only for the recipient(s) named in this message. If 
you are not the intended recipient you are notified that any use, disclosure, 
copying or distribution is prohibited. If you have received this in error 
please contact the sender and delete this message and any attachments from your 
computer system. We do not guarantee that this message or any attachment to it 
is secure or free from errors, computer viruses or other conditions that may 
damage or interfere with data, hardware or software.