我们在 Windows SBS 2008 服务器上启用了卷影副本。尝试从卷影副本还原文件出现以下错误 -
源文件名大于文件系统支持的名称。尝试移动到具有较短路径名的位置，或在尝试此操作之前尝试重命名为较短的名称。
文件名有 67 个字符，它的卷影复制路径是 170 个字符。这些似乎低于 NTFS 限制（260？）。
我们尝试了-
在进行复制之前，是否可以重命名卷影副本中的文件？尽管文件名大小似乎在限制范围内，但知道为什么会出现错误吗？
采取的步骤
编辑-（不）幸运的是，我现在无法重现此错误。导致问题的特定文件已被删除，并且无法使用其他类似文件重新创建错误。
让我先介绍一下背景。在 Linux 系统上，我经常依赖这样一个事实：只要我可以将所有文件从一个硬盘驱动器转移到另一个硬盘驱动器，并且只要我修复了引导加载程序，我就会得到一个相同的、可引导的、完全相同的功能系统。同样的事情适用于备份和恢复（不需要特殊的系统状态备份，只需要文件）......即使 MySQL有时也可以恢复，即使它在备份时没有被冻结
在 Windows 上，我从来没有通过在文件级别克隆系统而走运。我总是需要一个工具，如 VMWare Converter、Ghost、diXML 等。它们基于将驱动器的图像作为一个整体。起初我认为这主要是因为 Windows 注册表的特殊/神奇方式，我没有质疑它（它有效）。直到今天。我意识到这种想法很愚蠢，实际上Windows也只是一个文件的集合。因此，作为测试，我使用了一个脱机的 Windows 2003 服务器驱动器，我将文件复制到一个空白的硬盘驱动器，使驱动器处于活动状态，并且 .. 运行完美！
还是做到了？为什么我会因为它不像我对 Ghost 所期望的那样逐字复制而有这种非理性的恐惧，它会失败？我应该害怕吗？为什么这么容易？AD服务器有什么不同吗？有没有这种方法会失败的情况？
如果逐个文件复制是可行的方法，为什么当我尝试使用 VSS（将影子复制的 C: 驱动器暴露为 S: 驱动器）做同样的事情时，同样的方法失败了。更具体地说，我有一个引导系统一直到登录屏幕。它甚至接受了我的密码，但随后立即注销了我的用户，GUI 中没有错误。我什至尝试在复制之前关闭所有不可停止的服务......相同的结果。
顺便说一句，我正在使用robocopy /E /SEC所有这些复制操作
我使用这些方法只是在寻找麻烦吗？我知道 Ghost 等已经被证明了……那为什么要重新发明轮子呢？......我明白了......但作为一名专业人士，我想知道为什么事情会这样运作。这就是为什么弄清楚这一点对我来说很重要。（更不用说在我从未进行过系统状态备份的系统上进行裸机还原的罕见可能性）
如何在特定驱动器（D:、E:、...）上启用卷影复制并使用 Powershell 设置计划？
我只需要一些提示如何开始。
计划是创建一个相当大的 I/O 密集型卷的卷影副本。它有 350GB，包含一个基于文件系统的全文索引，该索引组织在数百个文件夹和数十万个需要处于一致状态才能成功恢复的小文件中。
当前索引器已停止，备份任务运行，然后索引器重新启动。这会导致索引在备份期间数小时不可用。我想通过卷影副本进行一致的备份，理想情况下根本不必停止索引器。
因此，我为该卷打开了 Shadow Copy，并将其配置为每晚制作一次快照到不同的卷。
现在我有点不知所措 - 我怎样才能访问整个卷影副本，以便我可以进行备份？我设想了一个只读驱动器，其中包含上次快照时的文件，但也许事情完全不同。
操作系统为Windows Server 2003 SP2，备份软件为CommVault Galaxy 7.0。
编辑：请注意 - 同时 - 已经创建了两个答案，它们以脚本的形式实现了必要的功能：
有一些与同时使用 DFSR 和 Shadow Copies 相关的问题，但没有一个问题表明 Shadow Copies 是否会复制。意思是，如果我在服务器 A 上有一对带有卷影副本的 DFS 副本，我可以将该文件还原到服务器 B 上的先前版本吗？如果是这样，该还原是否会复制回服务器 A？
我怀疑不是 - VSS 是本地 NTFS 功能并且不在复制范围内，但我目前无法验证这一点。
我有 Windows Server 2016。我的服务器上也有 Hyper-V 角色。5:36我每天都有错误，disk full我的虚拟机正在停止。在 Hyper-V 日志中：
ProviderName: Microsoft-Windows-Hyper-V-StorageVSP
TimeCreated Id LevelDisplayName Message
----------- -- ---------------- -------
11.03.2018 5:36:08 5 Information Storage device 'D:\DBS82-Data.vhdx' changed recovery state. Previous state = Recoverable Error Detected, New state = Recoverable Error Detected.
11.03.2018 5:36:08 4 Information Storage device 'D:\DBS82-Data.vhdx' received a recovery status notification. Current device state = Recoverable Error Detected, Last status = No Errors, New status = Disk Full.
11.03.2018 5:36:08 6 Information Storage device …许多著名的 Windows 备份实用程序使用内置于较新版本 Windows 的卷影复制服务来创建磁盘的时间点快照，以便安全地备份打开的文件。
但是这种机制在 SQL Server 上的表现如何？我知道存在 SQL Server VSS Writer 以帮助备份系统与 SQL Server 互操作，但并非所有备份系统都了解 SQL Server 并利用它提供的与备份相关的 API。
所以我的问题是，那些对 SQL Server 一无所知的程序呢？
他们大概会获得 MDF 和 LDF 文件在某个时刻存在的时间点快照。并且大概 SQL Server 数据格式足够健壮，可以保证这样的快照是一致和可用的。
这是事情的运作方式，还是我错过了什么？使用这种备份机制是否存在“问题”，或者我会安全吗？
我需要通过命令提示符以最少的停机时间备份正在运行的 Hyper-V 虚拟机。备份应存储在另一个本地磁盘或远程共享上。
我正在开发一个使用卷影复制服务定期备份特定文件的应用程序。这在以管理员身份运行时有效，但是当我在“网络服务”帐户下运行服务时，我认为这是应用程序的正确选择，我无法设置 SE_BACKUP_NAME 权限，因此无法使用 VSS。
以管理员身份运行服务似乎不正确，但这似乎是唯一的选择。我还有别的选择吗？
多年来，这一直困扰着我，现在我又要处理它了。我从来没有完全理解影子副本/VSS 的完整黑魔法。我了解它的作用以及如何初始设置它并在卷上设置时间表。我也理解它在备份中的作用。
为了简化它，我将坚持在我的环境中使用单个卷。我启用了以下计划：
1 - M-F 7am starting on 4/14/13
2 - M-F 12pm starting on 4/14/13
3 - 1st day of the month at 9am starting on 6/11/13
该Use limit卷的卷影副本的25,599MB (25GB).
该卷250GB具有44GB可用空间。
从今天开始倒退，我将所有正确的卷影副本时间/时间表显示回至 13 年 7 月 29 日。它不会再往前追溯，也没有 7/1/13 月刊。
我很确定我记得在最旧的被覆盖之前阅读有 64 个副本限制。这是有道理的，因为我计算了列表中当前的 64 个副本。
我的目标是达到我可以有 12 个“月刊”和上个月两次“日报”的程度（看起来总共大约 72 份）。
我有使用 Commvault Simpana 的“真实备份”，但处理从卷影副本恢复简单文件共享要容易得多。