问题标签 [shadow-copy]

我正在开发一个需要从磁盘备份文件的 Windows 备份应用程序（混合 Go / C++）。

我的应用程序

1. 以“备份操作员”组中的用户身份运行，并且在“备份文件和目录”中明确启用secpol.msc
2. 调用OpenProcessToken()并AdjustTokenPrivileges()授予SeBackupPrivilege整个过程，成功
3. 成功获取磁盘的 VSS 快照

4. 遍历 VSS 快照中的所有文件，然后尝试按如下方式备份它们：

   CreateFile( path, GENERIC_READ, FILE_SHARE_READ, NULL, // SecurityAttributes OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS|FILE_FLAG_SEQUENTIAL_SCAN NULL // TemplateFile );

5. 调用BackupRead()读取文件流。

这通常工作正常，并且我可以成功读取我的用户帐户通常会被拒绝读取访问的文件（例如C:\Windows\System32\config\systemprofile）。

但尽管如此，一些“顽固”文件仍然会给出错误，来自CreateFile：0x5 ERROR_ACCESS_DENIED（“访问被拒绝”）。

我知道“顽固”文件不是重解析点。

这些文件存在于本地、内部连接的 SATA、NTFS 磁盘驱动器上——而不是网络驱动器或任何外来驱动器。

“顽固”文件都是文件，而不是目录。

它们是一系列文件类型（docx、fla、swf、.DS_Store、...）。

除了防病毒程序之外，没有安装任何特殊的安全软件。

竞争对手的备份软件能够正确备份这些文件。

为什么这可能会发生？

如果我想创建一个打开的 MS Word 文档的备份，我需要先关闭该文件，然后才能进行任何备份。使用卷影复制，我可以备份打开的文件，但未保存的更改是否会与 Word 文档的快照一起备份？

我正在尝试创建一个使用卷影复制 (VSS) 自动创建文件备份的程序。我已经安装了 Windows 任务计划程序，但需要批处理文件才能执行。但是，我似乎无法理解如何创建这样一个批处理文件，以便我可以通过将打开的文件影子复制到另一个驱动器来创建它的备份。

这是个人/基本使用。我无法掌握如何备份将“缓存”在打开的 MS Word 文档中的未保存信息。这甚至可能吗？

感谢您的时间。

这里是Powershell新手，所以如果以下问题很愚蠢，请多多包涵......

我想在 Powershell 中创建一个 VSS 快照，并找到了许多使用 WMI 函数来执行此操作的示例。常见的模式是

我看到的所有代码都是使用 Powershell 的 WMI cmdlet。但是，根据大量参考资料（例如此处），我的印象是我们不应再使用 WMI cmdlet 。

因此，我试图找出如何仅使用 CIM cmdlet 创建 VSS 快照，但没有成功。第一个想法是创建一个新Win32_ShadowCopy实例，根据需要设置它的属性并调用Create它的方法。这在第一步中失败了：

显然New-CimInstance没有为Win32_ShadowCopy.

在进一步研究期间，还发现（与 WMI cmdlet 相比）CIM cmdlet 不返回Create可以调用该方法的对象（我已从以下代码的输出中删除了一些空行）：

据我了解，以上显示返回的对象get-cimclass和get-wmiobject两者都应该公开相​​同的方法。但是，当我们尝试调用该Create方法时：

显然，我不能get-cimclass用来创建卷影副本。对于get-ciminstance;也是如此。后者失败并显示相同的错误消息，就get-cimclass好像至少一个快照已经存在，否则会抛出另一个错误，因为返回的对象是空的。

那么我需要做什么才能仅使用 CIM cmdlet 创建卷影副本？

我有一个 Windows 2019 FilServer 并且试图获得对影子副本的更多控制，但无法弄清楚如何微调我的影子副本的规则：

创建规则：在每个工作日的每个小时创建一个新的 ShadowCopy，其描述为“每小时 YYYY.MM.DD HH.MM.SS”。在每个工作日创建一个新的 ShadowCopy，其描述为“每日 YYYY.MM.DD HH.MM.SS”。每周六创建一个带有“每周 YYYY.MM.DD HH.MM.SS”描述的新 ShadowCopy。每月的第一天创建一个新的 ShadowCopy，描述为“每月 YYYY.MM.DD HH.MM.SS”。

删除规则：描述以“每小时”开头且超过 7 天的每个 ShadowCopy。描述以“每日”开头且超过 14 天的每个 ShadowCopy。描述以“每周”开头且超过 30 天的每个 ShadowCopy。描述以“每月”开头且超过 365 天的每个 ShadowCopy。

我可以创建和删除影子副本。我不能做的是按描述设置和过滤。这甚至可能吗？有没有人有办法管理这个？

我们维护一个 VSTO Office 加载项。在大多数机器上，我们的程序集都被复制到Shadow Copy文件夹，该文件夹通常默认位于C:\Users\{User}\AppData\Local\assembly\dl3. 我们使用的第三方依赖项必须使用 GZipCompress 解压缩一些程序集，他们通过使用 Assembly.Location 属性解析程序集的路径来完成此操作。此路径始终被解析为 Shadow Copy 文件夹，因为默认情况下 VSTO 似乎对程序集进行了影子复制。

然而，在特定用户的机器上，程序集被复制到C:\Users\{User}\AppData\Local\Packages\Microsoft.Office.Desktop_{ALPHANUM}\LocalCache\Local\assembly\dl3，但是 Assembly.Location 值仍然是C:\Users\{User}\AppData\Local\assembly\dl3，我已经将两个\assembly文件夹符号链接在一起，但是我想知道为什么 .NET 正在解析错误的影子复制路径，以及为什么在此用户的计算机上，程序集被影子复制到 Office 的 LocalCache。

我正在尝试在 IIS 中使用 EFCore 3.1.16 解决 ASP.Net Framework 4.8 站点的问题。Microsoft.Data.SqlClient 在 SNI.dll 上有一个进程锁定，这会导致 IIS 中的 xcopy 部署出现问题。

我尝试了将 SNI.dll 复制到与 Microsoft.Data.SqlClient 相同的卷影副本位置的策略，因此它不必尝试访问 bin 文件夹中的 DLL，如https://github.com/中所述lscorcia/sqlclient.snishadowcopy。

但是，它仍然会首先尝试访问 bin 位置，而不是位于同一文件夹位置的 sni.dll。

我已经通过删除 DLL 并确认抛出 FileNotFound 异常来检查影子位置中的 Microsoft.Data.SqlClient 是否被正确使用。我还尝试直接复制到同一个文件夹中，并复制到其中的 x64 子文件夹中阴影位置。

卷影复制和其他备份方法有什么区别？访问备份的不同方法是否只是遵循相似目标的不同路径？例如，如果使用 vssadmin 删除卷影副本，这意味着我们将不会在系统中进行任何备份？还是还有一些不同于卷影副本的备份？我们可以说所有这些命令都做同样的工作吗？