在我的 Windows Server 2016 上，我使用 disk2vhd 进行备份，但由于某种原因，上次创建的 disk2vhd 上次备份无效。
磁盘工作正常，整个系统也可以。
所以我想用 VSS 进行备份，我创建了 vss 快照，将它挂载为磁盘 S: 并尝试通过xcopy /E /H /R
robocopy /xj /E /B
从中复制文件
但是在这两种方式中，我在某些文件、有时是系统文件、有时是用户文件上都得到了“拒绝访问”。
我使用 cmd 作为管理员。
在组策略中禁用管理员批准模式。
但我仍然收到“拒绝访问”错误
如何在不出现 Access is Denied 错误的情况下备份完整磁盘？
也许有人可以建议我更简单的方法。
我们有一个使用 Windows Server 2016 域控制器的客户。这是一家小型企业，因此他们的服务器基础架构由 Hyper-V 主机和此 DC 组成。DC 托管文件共享和 Azure AD Connect，用于将身份与 Office 365 同步。
我们监控事件 ID 4625 并设置警报阈值，以帮助我们识别针对网络的潜在暴力攻击。
去年 10 月，我们开始收到超出登录失败警报阈值的警报。经调查，我们对问题的描述如下：
vssadmin list writers过去几个月的故障排除清单很长。这不是一个完整的列表：
rundll32 keymgr.dll,KRShowKeyMgr- 没有缓存凭证）在所有这些过程中学到的有用的东西
vssadmin list writers在安装过程中持续运行，错误在安装SQL 组件后立即开始，甚至在安装程序完成运行之前。该问题显然与 AADC 有关，因为我可以停止 AAD 同步服务或卸载 AADC，并且所有失败的登录事件都会消失。但是卸载 AADC 并删除 AADC 文件夹并清除 AADC 用户帐户并清除 AADC 注册表项以尝试获得真正的全新安装没有任何效果，当我重新安装 AADC 时错误会立即返回。
在这一点上，我束手无策，我不知道还能做什么，甚至不知道还能去哪里看。我希望以太中的某个人比我知道的更多（可能），或者以前经历过这种情况并找到了解决办法。
最后一点 - 服务器的 DNS 名称长度为 9 个字符，这意味着它与其 NETBIOS 名称不匹配。我不认为这是原因，但如有必要，我可以重命名服务器。对于生产中的 DC 和文件服务器来说，这只是一件令人头疼的事情。
我一直在从 Microsoft 到博客文章的各个站点上阅读大量有关 Diskshadow 的文档，他们都建议这样做：
# diskshadow script commands
set verbose on
set context persistent
begin backup
add volume D: alias DataVol
create
expose %DataVol% Z:
exec <somebackupscripthere.cmd>
end backup
delete shadows exposed Z:
exit
我想将 Diskshadow 合并到我拥有的现有 Powershell 备份脚本中，长话短说，如果我可以围绕exec命令分解这些命令，那将是最简单的。像这样的东西：
# Powershell script
diskshadow -s diskshadowStartScript.dsh
# some backup commands here...
diskshadow -s diskshadowEndScript.dsh
以下是每个 diskshadow 脚本将包含的内容：
diskshadow 启动脚本：
#diskshadowStartScript.dsh
set verbose on
set context persistent
begin backup
add volume d: alias DataVol
create
expose %DataVol% Z:
diskshadow 结束脚本：
#diskshadowEndScript.dsh
end backup
delete shadows exposed Z:
exit
在阅读了所有文档之后，仍然有点不清楚是否Begin backup并且End backup必须从同一个 diskshadow 脚本中调用，或者它们是否可以分成单独的脚本。我知道当我留下一个脚本时，我会留下上下文或会话，并且我无法访问为卷别名创建的环境变量，但类似的事情是否也适用于Begin backupandEnd backup命令？或者那些备份命令就像Delete shadows可以在不同地方调用的命令一样？
服务器 2012 R2 集群。集群的存储是 EMC VNXe 3200（SMB3 共享，不是 ISCSI）。Veeam 用于备份。
Veeam 使用“VNX2e VSS Provider”在 EMC 上创建了 VSS 快照。
这些快照中有五个，可以追溯到几个月前。
我已向 Veeam 和 EMC 立案。双方都没有给出答案。
每日备份继续工作，创建快照，使用它们，然后按预期销毁它们。当备份运行时，快照会暴露给 Hyper-V 主机上的“vssadmin”或“diskshadow”命令。
这些孤立的快照不会显示在“vssadmin”或“diskshadow”中。
我希望有一个可以从 HyperV 主机运行的命令，该命令可以访问和删除孤立的快照（阴影）。
以下是在其中一台 HyperV 主机上运行的命令。另一台主机上的结果相似。
C:\vssadmin list shadows
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
No items found that satisfy the query.
=================================================================
C:>vssadmin list providers
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
Provider name: 'Microsoft CSV Shadow Copy Helper Provider'
Provider type: Software
Provider Id: {26d02d81-6aac-4275-8504-b9c6edc5261d}
Version: 1.0.0.1
Provider name: 'Microsoft CSV Shadow Copy Provider'
Provider type: Software
Provider Id: {400a2ff4-5eb1-44b0-8a05-1fcac0bcf9ff}
Version: 1.0.0.1
Provider name: 'VNX2e VSS Provider'
Provider type: Hardware
Provider Id: {58c4151c-7bfa-4fb9-aca3-e8afcde763a9}
Version: 6.2.9200.20557
Provider name: 'Microsoft File Share Shadow Copy provider'
Provider type: Fileshare
Provider Id: {89300202-3cec-4981-9171-19f59559e0f2}
Version: 1.0.0.1
Provider name: 'Microsoft Software Shadow Copy provider 1.0'
Provider type: System
Provider Id: {b5946137-7b9f-4925-af80-51abd60b20d5} Version: 1.0.0.7
Version: 1.0.0.7
=================================================================
C:\Windows\system32>vssadmin delete shadows /all
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
No items found that satisfy the query.
我经常在 Windows 文件服务器上使用集成的 VSS 功能，让用户自己恢复一些文件。这也允许 IT 团队在涉及很少文件时快速完成工作，这是最常见的问题。
例如，我每工作小时服用一个 VSS（每天 10 个），并在 4 周内保留它们（每周 5 个工作日）-> 总计 = 200 VSS 4 周
我想使用一些“灵活”的保留策略：
例如，在 3 个工作日内保持每小时 VSS，然后在接下来的 7 个工作日内每天保持 4 VSS，然后在接下来的 10 个工作日内每天保持 2 VSS -->总计 = 78 VSS，持续 4 周
两种情况下 VSS 占用的空间应该是相似的。
我的意思不是节省空间。这是为了延长 VSS 期间保留的周数。但由于 NTFS 最多可以有 512 个 VSS，因此每小时 VSS 不能持续超过 10 周。这是一个巨大的数字。
问题：您认为我应该编写一个 PowerShell 脚本来管理 VSS 保留策略吗？或者我可以使用已经完成的东西（脚本或软件）吗？
症状是大约每周一次 DFSR（分布式文件系统复制）停止复制并且 Windows 备份 (wbengine.exe) 停止响应。当我分析他们的等待链时，他们正在等待 dfsrs.exe 线程：4664 和线程：4680。dfsrs.exe 正在等待线程：4664。
我杀死 dfsrs.exe 并且 wbengine 开始响应。日志显示备份失败，因为创建卷影副本已超时。
重新启动 dfsrs.exe，我们重新开始工作。
此问题发生在两台新的 Server 2012 R2 机器（完全更新）上，彼此共享 DFS。在计算机上禁用 Windows 备份似乎可以阻止它导致问题（即使我们有其他软件可以创建多个每日卷影副本）。两台服务器上几乎没有非微软软件。
我获取了处于卡住状态的进程的转储文件，但我猜 VSSVC.dmp 将成为重要的文件。我不知道如何很好地使用 WinDbg，但这是我得到的结果：
0:000> !analyze -hang
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
Probably caused by : dfsrs.exe ( dfsrs!RunTaskCallback+17 )
Followup: MachineOwner
-------------------------------------
0:000> !dml_proc
DbgId PID Image file name
0 8c8 C:\Windows\System32\dfsrs.exe
0:000> !dml_proc 0x0
DbgId PID Image file name
0 8c8 C:\Windows\System32\dfsrs.exe
Browse module list
Threads:
DbgId TID Name (if available)
0 8cc "<No name>"
1 8e8 "<No name>"
2 1a70 "<No name>"
3 1a94 "<No name>"
4 1af0 "<No name>"
5 306c "<No name>"
6 5d4 "<No name>"
7 2648 "<No name>"
8 2654 "<No name>"
9 204c "<No name>"
a 2cd0 "<No name>"
b 304c "<No name>"
c 784 "<No name>"
d eec "<No name>"
e 3220 "<No name>"
f 298c "<No name>"
10 1238 "<No name>"
11 2b80 "<No name>"
12 1248 "<No name>"
13 3464 "<No name>"
14 2cf0 "<No name>"
15 31ac "<No name>"
16 3100 "<No name>"
17 308c "<No name>"
18 2a74 "<No name>"
19 18e0 "<No name>"
-------------------
0:000> ~[0x10]s;kM
ntdll!NtWaitForSingleObject+0xa:
00007ffc`27e606fa c3 ret
# Child-SP RetAddr Call Site
00 0000008e`4af1c348 00007ffc`25111118 ntdll!NtWaitForSingleObject+0xa
01 0000008e`4af1c350 00007ff7`0540754f KERNELBASE!WaitForSingleObjectEx+0x94
02 0000008e`4af1c3f0 00007ff7`0537d78c dfsrs!Task::ShutDown+0x283
03 0000008e`4af1c490 00007ff7`053e0656 dfsrs!UpdateDistributionTask::RemoveUpdateTask+0x2c
04 0000008e`4af1c540 00007ff7`053b845c dfsrs!UpdateManager::FinalizeUpdateManager+0x152
05 0000008e`4af1c5d0 00007ff7`053ab007 dfsrs!InConnection::InConnectionContentSetContext::FinalizeInConnectionContentSetContext+0x2e4
06 0000008e`4af1c740 00007ff7`053752e2 dfsrs!InConnection::DeleteContentSetFromInConnection+0x2a3
07 0000008e`4af1c870 00007ff7`0534f1b4 dfsrs!ReplicaSetManager::DeleteContentSetFromReplicaSetManager+0x1e2
08 0000008e`4af1c950 00007ff7`05338e89 dfsrs!ContentSetManager::InternalFinalizeContentSetManager+0x310
09 0000008e`4af1cbe0 00007ff7`053362c5 dfsrs!VolumeManager::FinalizeVolumeManager+0x265
0a 0000008e`4af1ccd0 00007ff7`05323b1a dfsrs!VolumeManager::ShutdownVolume+0x265
0b 0000008e`4af1ce20 00007ff7`05227034 dfsrs!FrsReplicator::FinalizeReplicator+0x182
0c 0000008e`4af1cef0 00007ff7`05239c0f dfsrs!FrsService::InternalShutdown+0x1f4
0d 0000008e`4af1d030 00007ffc`23896e83 dfsrs!VssWriter::OnPrepareSnapshot+0x12f
0e 0000008e`4af1d0a0 00007ffc`2389d145 vssapi!CVssWriterImpl::OnPrepareSnapshotGuard+0x2b
0f 0000008e`4af1d0d0 00007ffc`2389c470 vssapi!CVssWriterImpl::PrepareForSnapshotInternal+0xc71
10 0000008e`4af1e150 00007ffc`270e20f3 vssapi!CVssWriterImpl::PrepareForSnapshot+0x50
11 0000008e`4af1e1a0 00007ffc`270e6fad rpcrt4!Invoke+0x73
12 0000008e`4af1e200 00007ffc`2757d58a rpcrt4!NdrStubCall2+0x35e
13 0000008e`4af1e870 00007ffc`272522b3 combase!CStdStubBuffer_Invoke+0xa0
14 0000008e`4af1e8b0 00007ffc`275786ad oleaut32!CUnivStubWrapper::Invoke+0x53
15 0000008e`4af1e900 00007ffc`27404f5a combase!SyncStubInvoke+0x205
16 (Inline Function) --------`-------- combase!StubInvoke+0xc0
17 0000008e`4af1eaa0 00007ffc`2757951f combase!CCtxComChnl::ContextInvoke+0x27a
18 (Inline Function) --------`-------- combase!DefaultInvokeInApartment+0x51
19 0000008e`4af1ecb0 00007ffc`27578fb0 combase!AppInvoke+0x1af
1a 0000008e`4af1eda0 00007ffc`27579b35 combase!ComInvokeWithLockAndIPID+0x676
1b 0000008e`4af1efe0 00007ffc`270e2467 combase!ThreadInvoke+0x48a
1c 0000008e`4af1f0b0 00007ffc`270e22c0 rpcrt4!DispatchToStubInCNoAvrf+0x33
1d 0000008e`4af1f100 00007ffc`270eaa88 rpcrt4!RPC_INTERFACE::DispatchToStubWorker+0x190
1e 0000008e`4af1f200 00007ffc`270e2d26 rpcrt4!LRPC_SCALL::DispatchRequest+0x4c9
1f 0000008e`4af1f310 00007ffc`270e2b78 rpcrt4!LRPC_SCALL::HandleRequest+0x291
20 0000008e`4af1f3c0 00007ffc`270e195d rpcrt4!LRPC_SASSOCIATION::HandleRequest+0x238
21 0000008e`4af1f450 00007ffc`270e175e rpcrt4!LRPC_ADDRESS::ProcessIO+0x444
22 0000008e`4af1f590 00007ffc`27e0af00 rpcrt4!LrpcIoComplete+0x144
23 0000008e`4af1f630 00007ffc`27e09238 ntdll!TppAlpcpExecuteCallback+0x210
24 0000008e`4af1f6a0 00007ffc`254d13d2 ntdll!TppWorkerThread+0x888
25 0000008e`4af1fa80 00007ffc`27de54e4 kernel32!BaseThreadInitThunk+0x22
26 0000008e`4af1fab0 00000000`00000000 ntdll!RtlUserThreadStart+0x34
有什么想法可以从这里开始吗？我没想过在服务被冻结时运行进程资源管理器，但如果我们想尝试的话，它会在下周再次冻结。
我有两个新的 3850 24 端口千兆交换机。我把一个放在我们仓库前面的接线柜里，另一个放在后面。
有没有办法让这些成为使用 VSS 的第 2 层/第 3 层虚拟交换机？
我正在考虑创建一个跨堆栈的以太通道。但不知道关于第 2 层/第 3 层冗余（如果有的话）的真正作用。我配置了 DHCP、几个 VLAN 和 VLAN 间路由。
希望有某种方法可以做到这一点，以便如果一台交换机发生故障，另一台仍将提供 VLAN 间路由。
假设我有 VLAN 2。我在 VLAN 2 中为 3850-1 分配了一个 IP 为 192.168.1.1 的端口。
假设我有 3850-2，我有一个以太通道。
如果 3850-1 出现故障，我希望 3850-2 仍然能够路由 VLAN 2 作为该 VLAN 的默认网关。
这几乎就像为每个 VLAN 的默认网关 IP 设置一个虚拟 IP，并让一个交换机在其上扮演主动角色，如果该交换机出现故障，则让另一台交换机接管该 VIP 并继续提供基本的 intervlan 路由。
也许换一种说法，我怎样才能让两台交换机提供 VLAN 间路由冗余？
是否有一些明显的方法我没有找到如何在没有 GUI 的情况下在运行 Windows 的系统上为给定驱动器设置定期创建卷影副本？
据我所知，转到磁盘属性的卷影副本选项卡并单击启用按钮基本上只会创建几个计划任务。这些计划任务似乎使用某种特定于每个卷的 GUID？所以这不是我可以通过组策略轻松完成的事情。
必须有一些简单的方法可以从命令行启用卷影副本，对吧？
从我正在阅读的内容来看，有很多声明表明 MySQL 至少部分支持 VSS（卷快照服务），但有警告等，但我可以在网上找到的所有与此相关的内容至少已有 2 年历史。
我希望有人能给我一个关于 MySQL 与 VSS 的当前状态的指示？是否完全支持？如果不是，它会永远是吗？如果不是，那么，我们的替代方案是什么？我们正在尝试对生产数据库进行间歇性备份，但是对于数 GB 的数据，一个简单的 mysqldump 并没有削减它。
感谢您提供任何提示、技巧、注释或建议。
使用 Acronis Disk Director 将 Windows 2003 安装从单个驱动器克隆到两个镜像驱动器后，VSS 不再起作用，在尝试使用备份工具时归档事件 12293 和 7001，并且在访问磁盘属性的卷影复制选项卡时另外给出错误 0x8004230f .
我已经对此进行了彻底的谷歌研究，并找到了建议的修复方法[1]：替换磁盘的 MBR 签名。这将导致 Windows 使旧的卷影副本信息无效，据说这会使它再次工作。但是，我对此有点紧张......是否有可能以某种方式搞砸这件事，因为 mbr 源自单个磁盘安装，现在驻留在 raid 镜像上？这里有人遇到过这个问题并解决了吗？这种方法还是另一种？
[1] http://kb.backupassist.com/articles.php?aid=2971（在标题分辨率 2 下）