Thank you, this is good info. A lot to absorb.
For the D: drive, we still have the D: on the server, but I took the mssql
entry to mean that one of the volumes affected by that D: mssql component was
the f: that doesn't exist. So I'm assuming VSS is looking for something like
\\?\Volume{d48384d0-d2ae-4041-8483-f6e9c9f7e613}\ for the mssql component but
on the f:.
But I will only add F:\truecrypt-x64.sys first then see what happens as
suggested.
I did the * WRITER, they belong with the "System Writer"
Thanks.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Andrew Raibeck
Sent: Monday, June 10, 2013 4:56 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] System State Backup Error
Hello Jeanne,
System state backup is not at all related to backup of individual drives like
C: or F:. It is an entity unto itself.
System state is a construct defined by Microsoft. From the MSDN: "System state
is 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."
This is why, with certain situational exceptions, TSM will not consider a
system state backup to be successful if the operation does not meet this "all
or nothing" criterion.
The "operating system elements" cited in the above definition are the VSS
Writers that comprise system state, e.g., "System Writer", "WMI Writer",
"Registry Writer", "COM+ REGDB Writer", and so on. Not all writers enumerated
by the diskshadow utility or by the "vssadmin list writers"
command are part of system state, but many of them are.
Each of the VSS Writers is an application or service that stores data in files
on disk. A given VSS Writer is responsible for "knowing" what files belong to
it. When a "requester" (like the diskshadow utility or TSM) asks a VSS Writer
for its files, the VSS Writer is responsible for enumerating those files for
the requester. During backup operations, each VSS Writer ensures that its data
is in a stable state and ready for backup via shadow copy operations.
TSM utilizes the Microsoft Volume Shadowcopy Service (VSS) APIs to identify
each VSS Writer that is part of the system state, and for each VSS Writer,
which files belong to it.
In sum, TSM asks Windows "what files do I need to back up as part of system
state" and it is up to VSS and its associated components to provide an accurate
inventory. Then TSM takes this list and attempts to back it up.The vast
majority of the files typically reside on the boot drive (usually C:), but as
you have seen this is not a strict rule. Therefore during system state backup,
TSM will attempt to back up the file regardless of what disk it resides on. It
is completely irrespective of what other drives or files you have listed or
excluded in your DOMAIN or EXCLUDE statements.
Based on what you wrote below, I don't *think* the absence of the F: drive will
have other impact on the system state backup, but I cannot be sure. To which
VSS Writer does that information for the SQL stuff belong? If you locate that
entry in the disksh.out file then do a backward find for
* WRITER
(that is, an asterisk followed by a blank space followed by the word
WRITER)
you can see which VSS Writer it is that the SQL server entry belongs to. If it
is the SQL Writer, then this should be of no consequence to the system state
backup. If it is the System Writer then I don't *think* it will do any harm,
but I don't know for sure.
About the D: drive entry: are you saying there is no D: drive either? If that
entry is part of system state then it might present a problem. But for now, I
suggest making the change only for the F:\truecrypt-x64.sys file, and see how
it goes. One change at a time. :-)
- Andy
____________________________________________________________________________
Andrew Raibeck | Tivoli Storage Manager Level 3 Technical Lead | storman AT
us.ibm DOT com
IBM Tivoli Storage Manager links:
Product support:
http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager
Online documentation:
https://www.ibm.com/developerworks/mydeveloperworks/wikis/home/wiki/Tivoli
Documentation Central/page/Tivoli Storage Manager Product Wiki:
https://www.ibm.com/developerworks/mydeveloperworks/wikis/home/wiki/Tivoli
+Storage+Manager/page/Home
"ADSM: Dist Stor Manager" <ADSM-L AT vm.marist DOT edu> wrote on 2013-06-10
16:11:41:
> From: Jeanne Bruno <JBruno AT CENHUD DOT COM>
> To: ADSM-L AT vm.marist DOT edu,
> Date: 2013-06-10 16:12
> Subject: Re: System State Backup Error Sent by: "ADSM: Dist Stor
> Manager" <ADSM-L AT vm.marist DOT edu>
>
> Hello. I ran the list writer detailed command and yes, I found
> thisfor
the f:
>
> - File List: Path = f:, Filespec = truecrypt-x64.sys
>
>
> - d:\program files\microsoft sql server\mssql10_50.mssqlserver\mssql\binn
> - f:
> - Volumes affected by this component:
> - \\?\Volume{ae712515-6c71-484d-9e58-4d7ae60568a0}\ [C:\]
> - \\?\Volume{d48384d0-d2ae-4041-8483-f6e9c9f7e613}\ [D:\]
> - f: [Does not exist]
>
> So it would appear at one point we did have an F: for mssql and it was
> no longer needed.
>
> But even when we are excluding all the drives on our options on the
> TSM schedule that backs up this server, the SystemStateBackup still
> looks for the f: drive? I'm confused as to what the disksh.out
> file is telling me about the file: d:\program files\microsoft sql
> server\mssql10_50.mssqlserver\mssql\binn
>
> (The section in disksh.out where I found it, is hard to read, even
> with word wrap on)
>
> I would include both truecrypt-x64.sys and d:\program files
> \microsoft sql server\mssql10_50.mssqlserver\mssql\binn in the
> registry after the hotfix is installed, correct.
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Andrew Raibeck
> Sent: Monday, June 10, 2013 2:59 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] System State Backup Error
>
> Hello,
>
> Do you know what happened to the F: drive? It must have been there at
> one time (or so it would seem) and some installed product used it to
> store a driver file (perhaps some kind of drive encryption software?).
>
> You can confirm that VSS knows about this file by using the diskshadow
> utility to list the detailed writer information.
> "vssadmin list writers" is not sufficient for this.
>
> 1. Open a Windows command prompt (cmd.exe).
>
> 2. Type the following command and press <ENTER>:
>
> diskshadow /L disksh.out
>
> 3. You will now see the diskshadow command prompt. Type this command
> and press <ENTER>:
>
> list writers detailed
>
> 4. You will see a bunch of info fly by, it will take several seconds.
> Then you will see the diskshadow command prompt again. Type this
> command and press <ENTER>:
>
> exit
>
> 5. You will now be back at the C: prompt in the Windows command shell.
> Use notepad to view the disksh.out file:
>
> notepad disksh.out
>
> Search for truecrypt-x64.sys. You should be able to see the entry on
> the
F:
> drive. While you are in there, check for any other entries on the F:
drive.
>
> To work around this:
>
> Go to http://support.microsoft.com and search for KB article 980794.
> There you can find a hotfix you can install on Windows 2008 R2. The
> basic remediating steps are:
>
> 1. Install the hotfix (will require a reboot).
>
> 2. In registry key HKLM\SYSTEM\Control\SystemWriter, set value
> ExcludedBinaryPaths to the missing file (f:\truecrypt-x64.sys). You
> might need to add additional files if there were any others on F:
> (from the diskshadow output above).
>
> Once you have done this, perform the first set of steps 1-5 above.
> This time you should no longer see the truecrypt-x64.sys file. Then
> try the system state backup again.
>
> Note that the above is really only a circumvention to a symptom; the
> real problem is related to whatever application owns that file and is
> probably an uninstall issue. Besides the above action, you should try
> to find out the origin of this file, how it was installed, and how it
> was removed. It could be that this problem stems from an incomplete
> removal of the application that owns that file. The application vendor
> might also be able to help you do a complete clean-up of the
> application.
>
> - Andy
>
>
____________________________________________________________________________
>
> Andrew Raibeck | Tivoli Storage Manager Level 3 Technical Lead |
> storman AT us.ibm DOT com
>
> IBM Tivoli Storage Manager links:
> Product support:
> http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/
> Tivoli_Storage_Manager
>
> Online documentation:
>
https://www.ibm.com/developerworks/mydeveloperworks/wikis/home/wiki/Tivoli
> Documentation Central/page/Tivoli Storage Manager Product Wiki:
>
https://www.ibm.com/developerworks/mydeveloperworks/wikis/home/wiki/Tivoli
> +Storage+Manager/page/Home
>
> "ADSM: Dist Stor Manager" <ADSM-L AT vm.marist DOT edu> wrote on 2013-06-10
> 13:39:42:
>
> > From: Jeanne Bruno <JBruno AT CENHUD DOT COM>
> > To: ADSM-L AT vm.marist DOT edu,
> > Date: 2013-06-10 13:42
> > Subject: System State Backup Error
> > Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT vm.marist DOT edu>
> >
> > Hello. has anyone come across this error for a drive that doesn't
> exist?
> >
> > We have a server (Windows 2008 R2). Not a Cluster.
> > We do a SystemState backup on Sundays on it via TSM.
> > And it fails with this error:
> >
> > DSMError.log
> > 06/09/2013 18:01:19 ANS5250E An unexpected error was encountered.
> > TSM function name : AddFileToRequest
> > TSM function : GetVolumeNameForVolumeMountPoint() for drive
> > 'f:\' returned 2
> > TSM return code : 109
> > TSM file : vssreq.cpp (5144)
> > 06/09/2013 18:01:45 ANS5250E An unexpected error was encountered.
> > TSM function name : objEnumAuditFileSub
> > TSM function : GetBestVolumeMatch() for file '\\finland\f$
> > \truecrypt-x64.sys
> > ' failed.
> > TSM return code : 105
> > TSM file : objenum.cpp (1557)
> > 06/09/2013 18:01:45 ANS5250E An unexpected error was encountered.
> > TSM function name : BaHandleSystemPostSnapshotCmd
> > TSM function : objEnumAuditFileSub() failed
> > TSM return code : 105
> > TSM file : backsnap.cpp (3264)
> > 06/09/2013 18:01:45 ANS5250E An unexpected error was encountered.
> > TSM function name : baHandleSnapshot
> > TSM function : BaHandleSystemPostSnapshotCmd() failed.
> > TSM return code : 105
> > TSM file : backsnap.cpp (4167)
> > 06/09/2013 18:01:45 ANS1327W The snapshot operation for 'FINLAND
> > \SystemState\NULL\System State\SystemState' failed with error code:
105.
> > 06/09/2013 18:01:45 ANS1228E Sending of object '' failed
> > 06/09/2013 18:01:45 ANS4006E Error processing '': directory path not
> found
> > 06/09/2013 18:01:50 ANS1512E Scheduled event 'SQLDB_SUN_2K9' failed.
> > Return code = 12.
> >
> > DSMSched.log:
> > 06/09/2013 18:00:42 --- SCHEDULEREC QUERY BEGIN
> > 06/09/2013 18:00:42 --- SCHEDULEREC QUERY END
> > 06/09/2013 18:00:42 Next operation scheduled:
> > 06/09/2013 18:00:42
> > ------------------------------------------------------------
> > 06/09/2013 18:00:42 Schedule Name: SQLDB_SUN_2K9
> > 06/09/2013 18:00:42 Action: Incremental
> > 06/09/2013 18:00:42 Objects:
> > 06/09/2013 18:00:42 Options: -domain="all-local -c: -
> > d: -e: -g: -h: -q:"
> > 06/09/2013 18:00:42 Server Window Start: 18:00:00 on 06/09/2013
> > 06/09/2013 18:00:42
> > ------------------------------------------------------------
> > 06/09/2013 18:00:42
> > Executing scheduled command now.
> > 06/09/2013 18:00:43
> > Executing Operating System command or script:
> > svcstop > svcstop.log
> > 06/09/2013 18:00:57 --- SCHEDULEREC OBJECT BEGIN SQLDB_SUN_2K9 06/
> > 09/2013 18:00:00
> > 06/09/2013 18:00:57 Incremental backup of volume 'SYSTEMSTATE'
> > 06/09/2013 18:01:22 ANS1959I Removing previous incomplete group
> > '\System State\0\SystemState' Id:0-970590733
> > 06/09/2013 18:01:23 Backing up object 'COM+ REGDB Writer' component
> > 'COM+ REGDB' using shadow copy.
> > 06/09/2013 18:01:23 Backing up object 'Performance Counters Writer'
> > component 'Performance Counters' using shadow copy.
> > 06/09/2013 18:01:23 Backing up object 'Registry Writer' component
> > 'Registry' using shadow copy.
> > 06/09/2013 18:01:23 Backing up object 'System Writer' component
> > 'System Files' using shadow copy.
> > 06/09/2013 18:01:24 Backing up object 'Task Scheduler Writer'
> > component 'Tasks Store' using shadow copy.
> > 06/09/2013 18:01:24 Backing up object 'VSS Metadata Store Writer'
> > component 'VSS Express Writer Metadata Store' using shadow copy.
> > 06/09/2013 18:01:24 Backing up object 'WMI Writer' component
> > 'Windows Managment Instrumentation' using shadow copy.
> > 06/09/2013 18:01:45 ANS1228E Sending of object '' failed
> > 06/09/2013 18:01:45 ANS4006E Error processing '': directory path not
> found
> > 06/09/2013 18:01:50 --- SCHEDULEREC STATUS BEGIN
> > 06/09/2013 18:01:50 --- SCHEDULEREC OBJECT END SQLDB_SUN_2K9 06/09/
> > 2013 18:00:00
> > 06/09/2013 18:01:50
> > Executing Operating System command or script:
> > svcstart > svcstart.log
> > 06/09/2013 18:01:50 ANS1512E Scheduled event 'SQLDB_SUN_2K9' failed.
> > Return code = 12.
> > 06/09/2013 18:01:50 Sending results for scheduled event
'SQLDB_SUN_2K9'.
> > 06/09/2013 18:01:50 Results sent to server for scheduled event
> > 'SQLDB_SUN_2K9'.
> >
> > First, there is no F:\ on the server.
> > When I do the 'vssadmin list writers'.....none of the writers show
> > an
> error.
> > When I google: TSM function :
> > GetVolumeNameForVolumeMountPoint() for drive 'f:\' returned 2 It
> > talks about Cluster and the active/passive node. This server is not
> > a cluster.
> >
> > Any help is much appreciated. Thanks.
> > ____________________
> > Jeannie Bruno
> > Senior Systems Analyst
> > jbruno AT cenhud DOT com<mailto:jbruno AT cenhud DOT com>
> > Central Hudson Gas & Electric
> > (845) 486-5780
> >
>
|
