Generally speaking, unless a backup is in process, or you have file history enabled, there shouldn't be any shadow copies.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kurt Buff Sent: Friday, March 31, 2017 4:56 PM To: ntsysadm Subject: Re: [NTSysADM] WTF? Way too many Volume/Disk GUIDs OK - per MBS' suggestion, I ran 'vssadmin list shadows'. Here's one stanza: Contents of shadow copy set ID: {facc10d3-818e-40e8-b7cd-65030507c7f9} Contained 1 shadow copies at creation time: 2017-03-30 04:00:05 Shadow Copy ID: {8f76f079-7ac6-4fc4-ba2a-61a0327b5b83} Original Volume: (U:)\\?\Volume{cc4e4794-f6ef-4141-980a-87a984c191b5}\ Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy151 Originating Machine: zUSFS01p.zetron.com Service Machine: zUSFS01p.zetron.com Provider: 'Microsoft Software Shadow Copy provider 1.0' Type: ClientAccessible Attributes: Persistent, Client-accessible, No auto release, No writers, Differential Only the original volume GUID {cc4e4794-f6ef-4141-980a-87a984c191b5} shows up, with this line: Information,2016-05-12 11:48:22,Microsoft-Windows-Ntfs,98,None,Volume \\?\Volume{cc4e4794-f6ef-4141-980a-87a984c191b5} (\Device\HarddiskVolume113) is healthy. No action is needed. The other GUIDs don't show ({facc10d3-818e-40e8-b7cd-65030507c7f9} and {8f76f079-7ac6-4fc4-ba2a-61a0327b5b83}) I'll take a look at the other entries in the output. Kurt On Fri, Mar 31, 2017 at 1:32 PM, Miller Bonnie L. <[email protected]> wrote: > Windows Volume Shadow Copies? > > -Bonnie > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Kurt Buff > Sent: Friday, March 31, 2017 1:19 PM > To: ntsysadm <[email protected]> > Subject: [NTSysADM] WTF? Way too many Volume/Disk GUIDs > > I've got a 2012R2 file server with some problems. It recently locked up, and > we had to force boot it through the VMware interface. > > It's got 13 drives with letters, plus the usual system reserved partition. > > Here are the volume GUIDs from PS: > # GWMI -namespace root\cimv2 -class win32_volume | select > driveletter, deviceid | sort deviceid | ft -auto > > driveletter deviceid > ----------- -------- > T: \\?\Volume{0b58699a-c6d4-11e5-80ef-005056b43cf4}\ > J: \\?\Volume{27499b01-b5b4-43d7-98ae-17dbd948607e}\ > G: \\?\Volume{3e50ec99-13b5-4d52-8091-2feeb695943f}\ > \\?\Volume{3ec25e24-a333-11e3-80b4-806e6f6e6963}\ > C: \\?\Volume{3ec25e25-a333-11e3-80b4-806e6f6e6963}\ > D: \\?\Volume{3ec25e29-a333-11e3-80b4-806e6f6e6963}\ > P: \\?\Volume{410169c9-33c3-11e6-80fb-005056b43cf4}\ > X: \\?\Volume{515ebcdb-5c2e-11e4-80d4-005056b43cf4}\ > K: \\?\Volume{79470a07-567a-11e4-80d3-005056b43cf4}\ > I: \\?\Volume{88aa852a-1610-4875-8265-bb3c0612e5ef}\ > W: \\?\Volume{a94520fe-16c6-11e6-80f7-005056b43cf4}\ > S: \\?\Volume{cba78efd-34cd-11e6-80fb-005056b43cf4}\ > U: \\?\Volume{cc4e4794-f6ef-4141-980a-87a984c191b5}\ > M: \\?\Volume{d1ddfc3d-fa04-11e6-8109-005056b43cf4}\ > > After the machine was back up and running, I started combing the system > eventlog, and noticed something weird - there were a lot of volume GUIDs that > didn't match my list above. > > I finally exported the system event log as a CSV file (it goes back as far as > January of 2016), and cut and sorted the output, and found 2891 unique volume > GUIDs! > > That's just insane, and I have no explanation for this. > > Does anyone here have a clue to what this is about? > > Kurt > >
