In our current environment, we've never had a requirement to restore a system 
state. However, there are engineers that requested the ability to have it 
available.

Instead of using TSM's systemstate backup option, I've excluded it in the 
dsm.opt and use Microsoft's preferred and recommended method for backing up 
system state.

If you haven't seen this before, this quote is good to note:

"When performing a VSS backup or restore, the Windows system state is defined 
as being a collection of several key operating system elements and their files. 
These elements should always be treated as a unit by backup and restore 
operations.

What this means it is all or nothing when it comes to System State backups and 
restores."


I found that using the built in Microsoft feature is the best, and most 
accurate method. (2008 Servers) I currently have it part of a scheduled job,  
but you can just as easily add it as a pre-task in the tsm client as well, this 
will allow the system state backup to be as close to the tsm disk backup.


To enable it in Windows you need to add these Add these features:

You will need to add under windows 2008 Features the "Windows Server Backup 
Features" which includes Windows Server Backup and Command Line Options.


The actual backup commands go something like this

:: Decide how many versions to keep
Wbadmin delete systemstatebackup -backuptarget:E: -keepversions:1 -quiet

:: Take a new system state backup
wbadmin start systemstatebackup -backupTarget:d: -quiet


The only catch is that is has to back up to a non OS drive. And it will take 
grow to approx. 12GB+


If you wish to restore a system state backup, you must first reboot the server 
into Directory Services Restore Mode (DSRM). Once in DSRM, you would open a 
command prompt with administrator rights and use the following commands to 
start the restore.

C:\Users\admin>WBADMIN GET VERSIONS

Once we have located the version identifier, we can initiate the restore by 
using the following command:

WBADMIN START SYSTEMSTATERECOVERY -version: <version id>


Hope that helps,
-Nick


Also check out this Technical Exchange from IBM on the subject.

http://www-01.ibm.com/support/docview.wss?uid=swg27023299



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Grigori Solonovitch
Sent: Friday, January 10, 2014 3:29 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] POLL: Backing up Windows Systemstate

We are backing up Systemstate on all Windows servers because of using TBMR for 
restoring system images in case of system crash. Sometimes it is painful due to 
big number of files, problems with VSS, etc.
Problems with VSS are resolved by installing hot fixes or involving MS support.

Grigori Solonovitch, Senior Systems Architect, IT, Ahli United Bank Kuwait, 
www.ahliunited.com.kw


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan 
Forray
Sent: 09 01 2014 9:12 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] POLL: Backing up Windows Systemstate

A question about backing up systemstate, which seems to give us numerous 
headaches.

Do you backup systemsstate on your Windows servers and WHY?

My Windows folks constantly contact me about errors backup up and getting 
failures related to the systemstate files/process or VSS.

For example, today's headache is a 2008 box failing with *"System Writers 
'system writer'  do not exist * and yes, doing a "vssadmin list writers"
does not list "system writers".  They have been fighting this since November, 
with no solution to fixing this problem.  All hits/suggested solutions from 
Google searches have been tried, to no avail. I don't thing the server owners 
are willing to do a complete rebuild.

The simple solution would be to NOT backups systemstate.   For a simple
2008 server, what do we lose by not backing up systemstate?

--
*Zoltan Forray*
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zfor...@vcu.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.

Reply via email to