Hi folk!
I'm trying to see if you all have any tips or thoughts on what is going on with
my VSS based backups or debugging VSS in this situation.
To quickly set the stage, we have a Bareos 16.2.4 server, storing on a tape
library, connection to a mix of Linux and Windows server based Bareos 16.2.4
clients. The client that is having issues is a Windows Server 2012 R2 based
file server. The bulk of it's storage is B: on the server itself.
So with that said, when a backup job is triggered from Bareos I'm seeing a very
long seemingly odd delay. Here are a few of the key log entries in reverse
order:
2017-04-23 20:17:27 tier2-fs-vip.chass.ncsu.edu-fd JobId 16464: VSS Writer
(BackupComplete): "Shadow Copy Optimization Writer", State: 0x1 (VSS_WS_STABLE)
2017-04-22 16:04:30 tier2-fs-vip.chass.ncsu.edu-fd JobId 16464:
VolumeMountpoints are not processed as onefs = yes.
2017-04-22 16:04:29 tier2-fs-vip.chass.ncsu.edu-fd JobId 16464: Generate
VSS snapshots. Driver="Win64 VSS", Drive(s)="B"
Notice that the VSS snapshot starts at 2017-04-22 at 16:04:29, and then nothing
until the next day at 20:17:27. The total backup size was 1.45GB with 183
files. (it's about 2.1TB of data all together, but that's the size of the
incremental)
One of the "waiting" jobs that followed now kicks off almost immediately and
ends up with:
2017-04-25 00:52:18 tier2-fs-vip.chass.ncsu.edu-fd JobId 16499: VSS Writer
(BackupComplete): "DFS Replication service writer", State: 0x1 (VSS_WS_STABLE)
2017-04-23 20:23:56 tier2-fs-vip.chass.ncsu.edu-fd JobId 16499: Generate
VSS snapshots. Driver="Win64 VSS", Drive(s)="B"
2017-04-23 20:23:56 tier2-fs-vip.chass.ncsu.edu-fd JobId 16499:
VolumeMountpoints are not processed as onefs = yes.
Now flash forward to the currently running job. It has the same kind of thing:
2017-04-26 05:20:38 tier2-fs-vip.chass.ncsu.edu-fd JobId 16685:
VolumeMountpoints are not processed as onefs = yes.
2017-04-26 05:20:37 tier2-fs-vip.chass.ncsu.edu-fd JobId 16685: Generate
VSS snapshots. Driver="Win64 VSS", Drive(s)="B"
And it hasn't proceeded past that yet -- a good 10-ish hours later. Now, the
file server (client) itself says (and i just noticed that the time zone is not
set right on the server .. sigh):
C:\Windows\system32>vssadmin list shadows
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.
Contents of shadow copy set ID: {897ad85b-6c48-414b-a8ac-282eeb2f4d2a}
Contained 1 shadow copies at creation time: 4/26/2017 2:21:08 AM
Shadow Copy ID: {0a7bee96-8973-4301-9671-ee62340757e7}
Original Volume: (B:)\\?\Volume{92fedd7b-5bda-11e1-9fd4-782bcb75a3de}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy40
Originating Machine: HSS10FS.chass.ncsu.edu
Service Machine: HSS10FS.chass.ncsu.edu
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: Backup
Attributes: Differential
Normalize the time zone and that puts it at 5:21:08AM, which is approximately a
minute after it told it to create the shadow copy. From my perspective, that
means that Windows created the shadow copy really quickly after it was told to
and that Bareos is, for whatever reason, continuing to wait for it to be
created -- like it hasn't picked up that it was successfully created? Does
that sound like a proper read to you all?
Two things:
1. Any ideas what's going on or tips for tracking it down?
2. Would Bareos be angry about the timezone mismatch?
Thanks all!
Daniel
--
You received this message because you are subscribed to the Google Groups
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
