我最近创build了一个2012 R2文件服务器集群，并试图启用卷影副本。 当我右键单击故障转移群集pipe理器中包含用户数据的驱动器并单击属性时，我可以转到“卷影副本”选项卡。 如果我从列表中select音量，点击启用，并设置一个时间表，似乎接受设置。 但是，即使我删除了默认计划并创build了自定义计划，但节点上的计划任务并未显示我的自定义计划，而是仅在周一触发器中显示默认上午7点和下午12点。 我想知道是否有群集pipe理器中的错误，比阻止我设置自定义时间表？ 我也想知道是否有人可以build议如何在故障转移期间处理卷影副本，因为计划任务似乎只在当前运行该angular色的节点上创build。
我很难理解用户能够从ShadowCopy恢复文件的条件。 以下是对问题的背景的简要描述： Windows Server 2012 R2作为文件共享服务器。 在托pipe文件的本地驱动器上激活卷影复制 非常不同的ACL超过数百个文件。 不断演变的ACL。 文件可以通过DFS共享访问最终用户。 pipe理员帐户位于AD的域pipe理员组中。 有时候，作为pipe理员，我们必须使用卷影副本来恢复文件。 通常情况下，pipe理员连接到该服务器后，无法通过浏览器UI查看任何可用的卷影副本（即使技术上他们可以访问该文件夹作为域pipe理员）。 如果您有权访问该文件夹，则仅可用于文件夹的卷影副本似乎是合乎逻辑的。 默认情况下，大多数文件夹的访问列表中都有“域pipe理员”。 但是，只有在访问资源pipe理器中的文件夹并在UAC提示pipe理员权限后，pipe理员才会被主名添加到ACL中。 然后，当pipe理员被主动添加到ACL中时，他可以从那时起看到更新的Shadow副本。 但显然不是之前创build的较旧的快照。 就好像在确定是否应为Admin-A帐户显示卷影副本时，域pipe理员组没有考虑在内。 显然，作为内置的本地pipe理员帐户连接时，我们可以在大多数文件夹中看到更多的卷影副本历史logging。 有没有一种简单可靠的方式作为pipe理员访问所有的影子副本？ 据我所知，作为域pipe理员，只要域pipe理员组在其ACL中具有对该文件夹的完全访问权限，我就能够查看文件夹的影子副本的完整历史logging。 我已经看到了可以手动安装卷影副本的方法，但看起来有些反效果。 另外，如果有任何有关如何查看/恢复ShadowCopies的权限的文档，我会很乐意深入研究。 谢谢你的帮助 ！
在做一些testing时，我们发现我们意外地能够使用一些调用VSS API的现有代码为FAT32卷创build卷影副本，但是，我无法使用wmic shadowcopy call create Volume='E:\'在同一卷上创build卷影副本wmic shadowcopy call create Volume='E:\' 我在网上看到的一切都说这不应该是可能的。 所以我的问题是： 是否有可能为FAT32卷创build卷影副本？ 如果不是，我在下面看到了什么？ 如果是这样，哪个Windows版本引入了这个function？ 谢谢你的帮助。 PS C:\Users\Cameron> 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: {88f553a3-b7fd-4bdc-8ab9-2c46a7c2ec5a} Contained 1 shadow copies at creation time: 04/09/2017 10:09:34 Shadow Copy ID: […]
我们正试图在NetBackup 6.5.3.1环境中实施Microsoft VSS进行快照。 客户端都是32位和64位Windows 2003 Server。 快照参数是： 即时恢复已启用 最大快照= 1 提供者types= 1（系统） 快照属性= 1（差异） 所有备份都已成功完成，并且为快照备份和打开的文件（卷影副本组件）都成功创build了VSS阴影。 问题： NetBackup不清除或覆盖每个连续备份的旧快照。 当我们列出阴影和阴影存储时，它正在增加和增加。 IT不遵守最大快照设置。 日志：除了我们没有使用的方法（VxVM，Flashsnap等）之外，bpfis日志实际上并没有显示任何错误。 一节如下： 11:54:10.744 [348.4724] <2> logparams: D:\Program Files\Veritas\NetBackup\bin\bpfis.exe delete -nbu -id htpststr001.san.mgmt.det_1248918143 -bpstart_to 300 -bpend_to 300 -clnt htpststr001.san.mgmt.det 11:54:10.744 [348.4724] <4> bpfis: INF – BACKUP START 348 11:54:11.713 [348.4724] <8> onlfi_initialize_vfms: VfMS error 10; see following […]
在使用Acronis Disk Director将Windows 2003安装从单个驱动器克隆到两个镜像驱动器之后，VSS不再起作用，尝试使用备份工具时提交事件12293和7001，并且在访问磁盘属性的卷影副本选项卡时还提供错误0x8004230f 。 我已经谷歌研究这相当彻底，并find了一个build议的修复[1]：取代磁盘的MBR签名。 这将导致窗口使旧的影子副本信息失效，这应该会使所有的工作都重新开始。 但是，我对此有点紧张…有没有可能会搞砸了，因为mbr来自单个磁盘安装，现在居住在一个RAID镜像？ 有没有人有这个问题，并解决了它？ 这个方法还是另一个？ [1] http://kb.backupassist.com/articles.php?aid=2971 （在标题分辨率2下）
我试图恢复一些用户意外删除的文件，使用2k8r2的恢复以前的版本function。 我可以看到以前的版本，但是无论如何尝试恢复它们 – 同一位置，新位置，复制 – 我得到一个错误，指出源path太长。 任何想法在这方面？
我已经遵循了几个关于如何在Windows 2008 R2上恢复mysql的影子副本的介绍，而且这些信息似乎不是jive。 它们表明mysql数据库文件位于C：\ Program Files \ MySQL \ MySQL Server 5.5 \ data目录中，但是我只find三个文件夹mysql，performace_schema和test。 没有包含任何看起来像数据库数据的东西。 我们将转移到另一个备份模式，但这是另一天。 任何帮助，将不胜感激。
服务器设置 Exchange 2007版本：08.03.0192.001（汇总4） Windows Small Business Server 2008 SP2（汇总5） D：驱动器上的交换（449 GB / 698 GB免费） OS驱动器上有80 GB / 148 GB的空闲空间。 问题 备份失败（VSS相关） 备份软件 Windows服务器备份（版本1.0） 简化的错误 创build共享保护点超时。 未知错误（0x81000101） 对卷C进行刷新和保持写入操作：在等待释放写入命令时超时。 卷影复制警告：VSS花了43秒尝试刷新并保持卷\？\卷{b562a5dd-8246-11de-a75b-806e6f6e6963}。 当影子副本集中的其他卷超时等待发布 – 写入阶段时，这可能会导致问题，并且可能导致卷影副本创build失败。 磁盘活动较低时再试一次可能会解决此问题。 我试过了 服务器重新启动。 更新了服务器和Exchange。 重新configurationSharepoint（帮助解决我遇到的最后一个VSS错误）。 已注册的VSS Dll's（备份有时会起作用，但VSS作者很快就会失败）。 尝试实施修补程序： http : //support.microsoft.com/kb/956136 尝试实施修补程序： http : //support.microsoft.com/kb/972135 我离开了几天，几个备份来了，但后来又开始失败。 详细资料 日志名称：应用程序 来源：VSS date：16/11/2011 8:02:11 PM 事件ID：12341 任务类别：无 […]
问题机器是Windows Server 2008 R2文件服务器与以下驱动器，所有NTFS： C: OS D: File shares E: DFSR staging folders, temp files, and Volume Shadow Copies D：驱动器configuration为将卷影副本放在E：上，C：驱动器禁用卷影副本。 一个星期前，共享文件夹被删除，DFS引用被删除。 这留下了一个孤立的DFSR复制项目，该项目已从显示中删除，并且手动删除了所有临时文件夹。 几天后，卷影副本停止工作。 以标准备份用户身份运行，尝试创build卷影副本失败，并显示“访问被拒绝”，但在提升的命令提示符下运行时，将失败并显示“文件系统限制”。 在E上运行CHKDSK：返回“文件系统的types是RAW”。 磁盘pipe理器显示“NTFS”。 使用“testing磁盘”工具，分区表仍然显示NTFS。 E：驱动器上的所有文件都可以访问，并且正在正常读取和写入临时文件。 现有的卷影副本可以毫无问题地被访问。 使用C：作为testing，我发现可以将目标卷设置为C：或D：来启用卷影副本，但是无法将目标卷设置为E：。 任何想法是怎么回事，它可能与早期的DFS问题有关，系统pipe理员以错误的顺序删除设置？
一段时间以来，我一直在尝试使用内置的服务器备份工具来备份服务器时遇到了问题：由于某种原因影子复制会失败，但是如果我只是select单独的驱动器，则会失败C :, D :)。 最近，它已经开始行动了，现在正在失败的蓝色与此： 我不知道是什么原因造成的，我一直在Google上search，但一直没有运气。 有关更多信息，请参阅事件日志中的几个快照，可能有所帮助： 最后，从图片3的详细信息窗口获得一个XML转储： Log Name: Microsoft-Windows-Backup Source: Microsoft-Windows-Backup Date: 6/10/2013 7:20:39 AM Event ID: 5 Task Category: None Level: Error Keywords: User: SYSTEM Computer: ****** Description: The backup operation that started at '2013-06-10T12:19:26.203012000Z' has failed with following error code '2147942487'. Please review the event details for a solution, and then […]