Windows Image Backup 如何决定备份哪些文件？
Windows/NTFS 管理更改日记帐在每个卷上，跟踪哪个文件已更改、更改方式，并且由于默认情况下这些文件是所有 NTFS 卷的一部分，因此它们也可以在备份目标的 VHD(X) 中使用。据我了解，wbengine只需比较这些日志即可知道哪些文件需要备份。这使得支持不同的备份目标变得容易，而无需关心文件的存档位或类似的东西，因为这些更改日志绑定到卷唯一的文件 ID，并且这些 ID 在备份目标中完全相同：
C:\>fsutil file queryfileid "C:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin\perlapp.exe"
Datei-ID: 0x000000000000000000080000000ea5f1
C:\>fsutil file queryfileid "D:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin\perlapp.exe"
Datei-ID: 0x000000000000000000080000000ea5f1
在上面的例子中，C:\是我当前的系统卷，而 是D:\两个可用备份目标之一上安装的最后一个备份。甚至文件大小、时间戳等都相同：
C:\>dir /A "C:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin\perlapp.exe"
Datenträger in Laufwerk C: ist System
Volumeseriennummer: 266B-2863
Verzeichnis von C:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin
03.02.2016 17:08 560.640 perlapp.exe
1 Datei(en), 560.640 Bytes
0 Verzeichnis(se), 1.337.040.216.064 Bytes frei
C:\>dir /A "D:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin\perlapp.exe"
Datenträger in Laufwerk D: ist System
Volumeseriennummer: 266B-2863
Verzeichnis von D:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin
03.02.2016 17:08 560.640 perlapp.exe
1 Datei(en), 560.640 Bytes
0 Verzeichnis(se), 1.281.302.233.088 Bytes frei
通过使用这种方法，备份可以随时使用任何较旧的 VHD(X) 决定需要备份哪些文件，只要当前日志和映像中的日志有一些共同点，即我理解的条目 ID。如果没有这样的共享 ID，例如由于太多 I/O 发生生产并且备份太旧，则wbengine只需进行完整备份而不是增量备份。
使用这些日志还可以快速知道要备份哪些文件，因为不需要迭代整个文件树。这也是我们在实践中实际看到的情况：备份似乎很快就知道要备份哪些文件并开始处理这些文件，而不是迭代文件树。
当网络共享作为 Windows Server 2012+ 的备份目标时的行为。
在旧版本的 Windows 中，wbengine 似乎总是重新创建 VHD 文件，这使得它与某些底层文件系统（如 BTRFS 或 ZFS）支持的快照非常不兼容。此外，每个备份都是完整的，只是因为wbengine无法访问任何以前的备份来进行比较。
在较新版本的 Windows 中，情况似乎略有不同：我有点确定我的一个客户在使用wbadminWindows Server 2012 时遇到了麻烦，在使用 Process Monitor 调试这些麻烦时，我验证了现有的 VHDX 文件被保留了下来，而不是被删除并重新创建。我现在再次使用 Windows Server 2019 对此进行了测试，多次调用wbadmin导致备份成功，同时保持 VHDX 文件的 inode 不变：
root@[...]:~# ls -lisa "/volume1/[...]/Backup 2019-11-02 200024"
total 549063256
271 0 d---------+ 1 user group 594 Nov 2 20:58 .
266 0 d---------+ 1 user group 108 Nov 2 20:58 ..
273 507813736 ----------+ 1 user group 520061190144 Nov 2 22:02 165c4b13-8376-4c55-9643-a8c1b2c17d6b.vhdx
3814 4 ----------+ 1 user group 776 Nov 1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
3816 440 ----------+ 1 user group 450488 Nov 1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_Components.xml
3813 8 ----------+ 1 user group 6212 Nov 1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_RegistryExcludes.xml
3815 4 ----------+ 1 user group 1192 Nov 1 22:47 BackupSpecs.xml
272 41249064 ----------+ 1 user group 42289070080 Nov 2 22:03 f7650533-11ca-4db4-80f5-2db42f7b900a.vhdx
root@[...]:~# ls -lisa "/volume1/[...]/Backup 2019-11-03 132201"
total 549318872
271 0 d---------+ 1 user group 594 Nov 2 20:58 .
266 0 d---------+ 1 user group 108 Nov 3 14:19 ..
273 507813736 ----------+ 1 user group 520061190144 Nov 3 14:19 165c4b13-8376-4c55-9643-a8c1b2c17d6b.vhdx
3814 4 ----------+ 1 user group 776 Nov 1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
3816 440 ----------+ 1 user group 450488 Nov 1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_Components.xml
3813 8 ----------+ 1 user group 6212 Nov 1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_RegistryExcludes.xml
3815 4 ----------+ 1 user group 1192 Nov 1 22:47 BackupSpecs.xml
272 41504680 ----------+ 1 user group 42289070080 Nov 3 14:21 f7650533-11ca-4db4-80f5-2db42f7b900a.vhdx
root@[...]:~# ls -lisa "/volume1/[...]/Backup 2019-11-03 133308"
total 41262660
271 0 d---------+ 1 user group 2504 Nov 3 14:44 .
266 0 d---------+ 1 user group 108 Nov 3 14:30 ..
3851 4 ----------+ 1 user group 776 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
3853 440 ----------+ 1 user group 450488 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Components.xml
3850 8 ----------+ 1 user group 6212 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_RegistryExcludes.xml
3840 4 ----------+ 1 user group 3138 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer0bada1de-01a9-4625-8278-69e735f39dd2.xml
3848 4 ----------+ 1 user group 2284 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer2707761b-2324-473d-88eb-eb007a359533.xml
3844 8 ----------+ 1 user group 5386 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
3846 4 ----------+ 1 user group 1488 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
3839 4 ----------+ 1 user group 1628 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer75dfb225-e2e4-4d39-9ac9-ffaff65ddf06.xml
3842 24 ----------+ 1 user group 21686 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writera65faa63-5ea8-4ebc-9dbd-a0c4db26912a.xml
3847 4 ----------+ 1 user group 1484 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
3845 4 ----------+ 1 user group 2940 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
3849 4 ----------+ 1 user group 1850 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writerb2014c9e-8711-4c5c-a5a9-3cf384484757.xml
3843 8 ----------+ 1 user group 6048 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
3838 4 ----------+ 1 user group 1746 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writerd61d61c8-d73a-4eee-8cdd-f6f9786b7124.xml
3841 13068 ----------+ 1 user group 13379228 Nov 3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writere8132975-6f93-4464-a53e-1050253ae220.xml
3852 4 ----------+ 1 user group 758 Nov 3 14:44 BackupSpecs.xml
272 41249064 ----------+ 1 user group 42289070080 Nov 3 14:44 f7650533-11ca-4db4-80f5-2db42f7b900a.vhdx
因此，从理论上讲，这应该允许增量备份就地替换文件，并同时高效快照（例如底层 BTRFS 或 ZFS）。查看测试的 Windows Server 2019 快照的存储，至少其中一些确实共享了一些空间：
Total Exclusive Set shared Filename
424.41GiB 417.69GiB 6.72GiB /volume1/@sharesnap/[...]/GMT+01-2019.10.29-00.00.09
446.53GiB 400.16GiB 46.37GiB /volume1/@sharesnap/[...]/GMT+01-2019.10.30-00.00.08
483.05GiB 448.36GiB 34.70GiB /volume1/@sharesnap/[...]/GMT+01-2019.10.31-00.00.08
553.78GiB 209.26GiB 344.52GiB /volume1/@sharesnap/[...]/GMT+01-2019.11.02-00.00.09
204.68GiB 204.63GiB 0.05GiB /volume1/@sharesnap/[...]/GMT+02-2019.10.01-00.00.07
410.24GiB 405.37GiB 4.87GiB /volume1/@sharesnap/[...]/GMT+02-2019.10.27-00.00.06
不过，这并不像我预期的那么多。问题在于，即使重复使用了 VHDX 文件，共享的空间也可能不多，因为当我随后调用C:该服务器的备份时，备份似乎并没有变得更快。
由于大量数据发生变化，第一次备份可能需要更长时间，但在备份完成后，服务器不执行任何操作，几分钟后进行的第二次备份应该会快得多，因为只备份文件的差异。但事实似乎并非如此，相反，它似乎花费的时间与以前相同。此外，虽然 BTRFS 可以在使用完全相同的命令行的不同调用之间共享创建的快照的差异wbadmin，但当真正只备份更改的文件时，这些差异比预期的要小得多：
root@[...]:~# btrfs filesystem du -s --gbytes /volume1/@sharesnap/[a-zA-Z]*/GMT*
Total Exclusive Set shared Filename
446.53GiB 400.20GiB 46.33GiB /volume1/@sharesnap/[...]/GMT+01-2019.10.30-00.00.08
483.05GiB 448.36GiB 34.70GiB /volume1/@sharesnap/[...]/GMT+01-2019.10.31-00.00.08
553.78GiB 546.54GiB 7.24GiB /volume1/@sharesnap/[...]/GMT+01-2019.11.02-00.00.09
39.35GiB 37.68GiB 1.67GiB /volume1/@sharesnap/[...]/GMT+01-2019.11.03-15.36.52
39.35GiB 31.18GiB 8.17GiB /volume1/@sharesnap/[...]/GMT+01-2019.11.03-15.49.03
39.35GiB 37.98GiB 1.37GiB /volume1/@sharesnap/[...]/GMT+01-2019.11.03-16.03.06
410.24GiB 409.72GiB 0.52GiB /volume1/@sharesnap/[...]/GMT+02-2019.10.27-00.00.06
这与我备份到 USB 磁盘时看到的情况不同，如果没有任何变化，后续备份会快得多。有趣的是，其他人似乎也不太确定网络共享上的情况：
如果您创建计划备份作业到网络共享文件夹或映射网络驱动器，则所有备份将仅通过完整备份执行，因为网络位置不是卷。如果您需要创建差异备份或增量备份到网络文件夹，则需要第三方备份软件。
https://www.ubackup.com/windows-server/windows-server-backup-differential-4348.html
然而，同样的人却写了下面的内容，但这没有多大意义：
提示：您还可以使用 WBADMIN 创建增量备份到网络共享，如下所示：
wbadmin 开始备份 –backupTarget:\backupshare\backup1-allCritical-include:C:-vssFull –quiet
https://www.ubackup.com/articles/wbadmin-incremental-backup-5740.html
在备份到共享的情况下，如果总是重新创建 VHD，就像旧版本的 Windows 一样，则无法获得增量备份。但即使 VHDX 文件保留在较新版本的 Windows 中，似乎仅备份更改的文件仍然无法像使用 USB 磁盘时那样工作。
-vssFull 和 -vssCopy 的影响。
在我的测试中，使用-vssFullvs.-vssCopy没有任何区别，而且据我所知，它甚至没有打算这样做。这些参数仅与第三方软件有关，不会影响备份哪些文件以及如何备份。相信这一点的理由记录在我之前的回答中：
-vssFull 和 -vssCopy 的影响。
https://serverfault.com/a/990394/333397
Server 2016 的备份行为。
我的一位客户也在使用 Server 2016 wbadmin，这显示出每天运行一次备份时的行为略有不同。查看日志文件和wbadmin运行时间，似乎在这种情况下C:\创建了真正的增量备份，因为大多数备份都很快，并且 BTRFS 的快照共享了大量空间：
root@[...]:~# btrfs filesystem du -s --gbytes /volume1/@sharesnap/[a-zA-Z]*/GMT*
Total Exclusive Set shared Filename
388.12GiB 4.29GiB 383.83GiB /volume1/@sharesnap/[...]/GMT+01-2019.11.01-00.00.05
389.34GiB 1.60GiB 387.73GiB /volume1/@sharesnap/[...]/GMT+01-2019.11.03-00.00.05
389.64GiB 1.39GiB 388.25GiB /volume1/@sharesnap/[...]/GMT+01-2019.11.04-00.00.04
330.22GiB 0.00GiB 330.22GiB /volume1/@sharesnap/[...]/GMT+01-2019.11.05-00.00.06
most是这里的关键词，因为似乎每 14 天左右的备份时间大约是 3 倍，这似乎又是一个完整备份。这与我在某处读到的内容一致，即服务器备份每 14 天自动进行一次完整备份，之后只进行增量备份。但这并不能解释为什么我的 Server 2019 似乎没有这样做。
我所看到的命令行的唯一区别是-allCritical -systemState用于 Server 2016，而-include:c:,d:出于某些原因，Server 2019 使用的是。无论如何，两者都在使用-vssCopy，因此如预期的那样，使用 或-vssFull应该不会有任何区别。
问题
Windows Server 2019 在针对网络共享时是否wbengine支持增量备份？如果支持，在什么条件下支持，比如命令行参数？在使用快照的情况下，是否有人看到备份时间和存储分配有所改善？
答案1
是的，确实如此，不过可能需要在服务器上启用自动快照创建功能。自从提出问题以来，我已经设置了多个这样的功能，所有这些功能都表现得符合预期，初始备份时间较长，之后的备份速度相当快，具体取决于更改的数据量。在所有情况下，我都使用 SMB 备份到一些 Synology NAS。
不确定这是否是巧合，但几天前我意识到 Server 2019 上的（自动）快照尚未针对内部卷启用。所以我这样做了，从下一次备份开始，在过去几天里，这些快照的速度已经快了很多。我只是启用了具有默认配额的自动快照，但将其更改为每天创建一次而不是每个工作日创建一次。就是这样，wbadmin 现在需要的时间少了很多，关于复制数据的日志消息现在短了很多。我没想到这些计划的快照会对 wbadmin 产生任何影响。