从 Windows Server 2008 R2（据我所知，最高可达 Server 2019）开始，Windows Server Backup 执行自动管理完整备份和增量备份：
自动管理完整备份和增量备份。您不再需要管理完整备份和增量备份。相反，Windows Server Backup 将默认创建一个增量备份，其行为类似于完整备份。您可以从单个备份中恢复任何项目，但备份将仅占用增量备份所需的空间。此外，Windows Server Backup 不需要用户干预来定期删除旧备份以释放磁盘空间用于新备份 - 旧备份会自动删除。
这听起来是个不错的功能。
然而，我们使用二备份磁盘：一个始终连接到服务器以进行每日备份，另一个始终存储在异地。我们每周都会切换这些磁盘，以确保我们始终拥有最多一周的异地服务器备份。
这些增量备份如何与交替磁盘一起工作？
显然，这样就没问题了（选项 1）：
Day 1: Full backup on Disk A.
Day 2: Incremental backup (w.r.t. Day 1 backup) on Disk A.
Day 3: Incremental backup (w.r.t. Day 1+2 backup) on Disk A.
...
Day 8: Full backup on Disk B.
Day 9: Incremental backup (w.r.t. Day 8 backup) on Disk B.
Day 10: Incremental backup (w.r.t. Day 8+9 backup) on Disk B.
...
Day 15: Incremental backup (w.r.t. Day 1-7 backup) on Disk A.
Day 16: Incremental backup (w.r.t. Day 1-7+15 backup) on Disk A.
但这会不是没问题（选项 2）：
Day 1: Full backup on Disk A.
Day 2: Incremental backup (w.r.t. Day 1 backup) on Disk A.
Day 3: Incremental backup (w.r.t. Day 1-2 backup) on Disk A.
...
Day 8: Incremental backup (w.r.t. Day 1-7 backup) on Disk B.
Day 9: Incremental backup (w.r.t. Day 1-8 backup) on Disk B.
Day 10: Incremental backup (w.r.t. Day 1-9 backup) on Disk B.
...
Day 15: Incremental backup (w.r.t. Day 1-14 backup) on Disk A.
Day 16: Incremental backup (w.r.t. Day 1-15 backup) on Disk A.
因为它需要两个都要还原的两个磁盘（因此，失去了拥有两个磁盘的目的）。
Windows Server Backup 使用选项 1 还是选项 2？ 记录在哪里？
（澄清一下：问题就是上一段加粗的内容。它不是“如何向备份集添加第二个磁盘”，也不是“增量备份通常如何工作”。）
答案1
Windows Server 的自动增量备份是否可以与多个备份磁盘“配合良好”？
我认为是的。
以下是我回答所依据的论据，可供进一步讨论。对于 Windows Backup 在某些情况下的行为方式，我仍有些方面不太确定，人们可能想澄清或纠正我。不过，我认为值得在这里提及。
Windows Server Backup 使用选项 1 还是选项 2？ 记录在哪里？
首先，总体上我同意你的观点，并且非常确定wbadmin/wbengine实现了选项 1，但我没有来自微软的明确声明来证明这一点。此外，我有点确定这不仅与 Windows Server 有关，而且对于非服务器版本的 Windows 也同样有效。事实上，自从 Windows 7 以来，我就一直在使用你提到的设置和 3 个不同的 USB 磁盘来创建基于映像的备份。1 个磁盘在异地，两个在一周内定期更换。
我发现 USB 磁盘上的 VHD(X) 文件始终会更新，而备份需要多长时间以及传输哪些文件实际上取决于自上次使用当前用作备份目标的 USB 磁盘以来哪些文件发生了变化。这就是文档中提到的增量部分，只有备份差异，但这些差异始终会写入 VHD(X) 中的现有文件中。
Windows Image Backup 不会自行管理备份的增量历史记录，它始终会覆盖当前使用的 VHD(X) 中的现有文件作为备份目标。因此，从当前可用的 VHD(X) 恢复时永远不需要增量历史记录。对于 NTFS 格式的 USB 磁盘，历史记录是使用卷影副本：在进行新备份之前，会在备份目标中创建一个影子副本，之后才会wbengine打开 VHD(X) 并根据需要替换其中的文件。替换文件是就地、逐块进行的，wbengine真正读取已更改的源文件，将读取的块与备份目标中的相同块进行比较，并且仅在发生更改时进行覆盖。由于备份目标中有一个影子副本，因此 VSS 会识别那些已更改的块（这些块实际上是 VHD(X) 的已更改块），并在覆盖之前复制内容。因此，备份目标中的所有影子副本始终包含以前备份的系统的完整功能 VHD(X)，并且这些影子副本最终会创建增量历史记录。由于所有影子副本都包含完整功能 VHD(X)，因此不需要任何额外的增量数据，而只需安装一些快照、该快照中的 VHD(X) 并根据需要进行恢复即可。VSS 将处理收集相关块的详细信息。
以下是我不太确定的几点：
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 2008 R2 备份目标时的行为。
如果备份到网络共享，wbengine似乎取决于所使用的 Windows 版本，但一般来说，前面描述的备份目标中每个备份卷始终只有一个 VHD(X) 的方法似乎也适用。主要区别似乎在于如何实现这一点，要么覆盖现有的 VHD(X) 文件，要么删除并重新创建它们，要么像 USB 磁盘一样，通过打开并就地修改它们。
以下是一些文档和其他人对该主题的看法：
如果将备份保存到远程共享文件夹，则当您再次使用同一文件夹备份同一台计算机时，该备份将被覆盖。[...]
请注意，如果您要备份到网络共享，则每次都会运行完整备份（因为 VSS 不可用），覆盖之前的完整备份。在这种情况下，根本没有备份策略，您只是维护系统的远程影子/副本。
https://lennox-it.uk/a-complete-guide-to-wbadmin-windows-backups
我们要确保中奖者的安全。当在庆典平台上时等等。心若无物，便会不断地更新心若无物。将它添加到共享文件夹，但它只是一个备份，我将使用最新的备份说明。
https://administrator.de/forum/verständnisfragen-windows-server-backup-2012-294395.html
查看我自己使用 Windows 2008 R2 进行的测试，“覆盖”在这里似乎有点误导，因为似乎真的创建了新文件，因为不仅图像的名称发生了变化，而且它们的 inode 也发生了变化：
root@[...]:~# ls -lisa "/volume1/[...]/WindowsImageBackup/[...]/Backup 2019-11-01 190024"
total 247604492
435 0 drwx------+ 1 [...] users 2582 Nov 2 09:12 .
430 0 drwx------+ 1 [...] users 108 Nov 1 19:58 ..
8200 214832596 -rwx------+ 1 [...] users 220521977856 Nov 1 21:33 3e4779f7-b3e1-11e0-b58f-001999a28c91.vhd
8199 32764536 -rwx------+ 1 [...] users 42484091904 Nov 1 20:12 5d3e4b2f-b386-11e0-ac00-806e6f6e6963.vhd
8214 4 -rwx------+ 1 [...] users 1078 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
8216 12 -rwx------+ 1 [...] users 11940 Nov 1 21:34 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Components.xml
8213 8 -rwx------+ 1 [...] users 5500 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_RegistryExcludes.xml
8203 4 -rwx------+ 1 [...] users 3138 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer0bada1de-01a9-4625-8278-69e735f39dd2.xml
8210 4 -rwx------+ 1 [...] users 1934 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer2a40fd15-dfca-4aa8-a654-1f8c654603f6.xml
8208 4 -rwx------+ 1 [...] users 3414 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
8207 4 -rwx------+ 1 [...] users 1488 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
8212 4 -rwx------+ 1 [...] users 1630 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer59b1f0cf-90ef-465f-9609-6ca8b2938366.xml
8202 4 -rwx------+ 1 [...] users 1628 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer75dfb225-e2e4-4d39-9ac9-ffaff65ddf06.xml
8211 4 -rwx------+ 1 [...] users 950 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writera65faa63-5ea8-4ebc-9dbd-a0c4db26912a.xml
8209 4 -rwx------+ 1 [...] users 1484 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
8206 4 -rwx------+ 1 [...] users 3844 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
8205 8 -rwx------+ 1 [...] users 4288 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
8201 4 -rwx------+ 1 [...] users 1746 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writerd61d61c8-d73a-4eee-8cdd-f6f9786b7124.xml
8204 7284 -rwx------+ 1 [...] users 7455796 Nov 1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writere8132975-6f93-4464-a53e-1050253ae220.xml
8215 4 -rwx------+ 1 [...] users 1098 Nov 1 21:33 BackupSpecs.xml
root@[...]:~# ls -lisa "/volume1/[...]/WindowsImageBackup/[...]/Backup 2019-11-02 190054"
total 247603788
435 0 drwx------+ 1 [...] users 2582 Nov 2 21:51 .
430 0 drwx------+ 1 [...] users 108 Nov 2 19:59 ..
8247 4 -rwx------+ 1 [...] users 1078 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
8249 12 -rwx------+ 1 [...] users 11940 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Components.xml
8246 8 -rwx------+ 1 [...] users 5500 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_RegistryExcludes.xml
8236 4 -rwx------+ 1 [...] users 3138 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer0bada1de-01a9-4625-8278-69e735f39dd2.xml
8242 4 -rwx------+ 1 [...] users 1934 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer2a40fd15-dfca-4aa8-a654-1f8c654603f6.xml
8239 4 -rwx------+ 1 [...] users 3414 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
8243 4 -rwx------+ 1 [...] users 1488 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
8241 4 -rwx------+ 1 [...] users 1630 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer59b1f0cf-90ef-465f-9609-6ca8b2938366.xml
8235 4 -rwx------+ 1 [...] users 1628 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer75dfb225-e2e4-4d39-9ac9-ffaff65ddf06.xml
8244 4 -rwx------+ 1 [...] users 950 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writera65faa63-5ea8-4ebc-9dbd-a0c4db26912a.xml
8245 4 -rwx------+ 1 [...] users 1484 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
8240 4 -rwx------+ 1 [...] users 3844 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
8238 8 -rwx------+ 1 [...] users 4288 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
8234 4 -rwx------+ 1 [...] users 1746 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writerd61d61c8-d73a-4eee-8cdd-f6f9786b7124.xml
8237 7284 -rwx------+ 1 [...] users 7455796 Nov 2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writere8132975-6f93-4464-a53e-1050253ae220.xml
8233 214832596 -rwx------+ 1 [...] users 220521977856 Nov 2 21:51 3e4779f7-b3e1-11e0-b58f-001999a28c91.vhd
8232 32763832 -rwx------+ 1 [...] users 42481994240 Nov 2 20:11 5d3e4b2f-b386-11e0-ac00-806e6f6e6963.vhd
8248 4 -rwx------+ 1 [...] users 1098 Nov 2 21:51 BackupSpecs.xml
这与我在 USB 磁盘上看到的情况不同，在 USB 磁盘上，图像保留其名称和文件 ID（/inodes），只有大多数 XML 文件获得新的 UUID。在 USB 磁盘上，VHD(X) 的父目录也会更改，但这只是重命名，因此不会以任何方式影响子文件。在测试期间，我曾一度wbengine决定保留 VHD 文件的名称，但它们的 inode 始终会更改。不过，没有使用任何新命令行调用，而只是随后调用：
8260 32767464 -rwx------+ 1 [...] users 42481994240 Nov 3 12:47 5d3e4b2f-b386-11e0-ac00-806e6f6e6963.vhd
8266 32764416 -rwx------+ 1 [...] users 42481994240 Nov 3 13:18 5d3e4b2f-b386-11e0-ac00-806e6f6e6963.vhd
我不知道为什么在使用共享的情况下他们会以这种方式实现这些功能，因为它会破坏底层的 BTRFS 快照。但这正是我看到的：我的 NAS 为存储这些备份的文件夹创建的所有快照几乎都独占了所有相关存储，而不是共享大部分数据。此外，根据日志文件大小和运行时间长度wbengine，所有备份几乎都花费相同的时间，即使备份源中的文件没有太多变化。
当网络共享作为 Windows Server 2012+ 的备份目标时的行为。
在较新版本的 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
它没有我预期的那么多，但这可能有其他原因，因为这个系统由于存储空间太少而无法备份。这实际上就是我再次调查这个主题并提出这个问题的原因。查看其他使用基于映像的备份的 Windows 10 客户端的快照，它们大多共享更多。但它们也使用基于 ZIP 的备份，并且 BTRFS 子卷包含每个用户的所有备份相关目录，因此这些数字可能有点误导。
问题在于，即使重复使用 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 的旧版本一样，在备份到共享时，不会获得增量备份。但即使保留了这些，并且可以像使用 USB 磁盘一样进行增量备份，更改为-vssCopy似乎vssFull对我来说也没有什么改变。在两种情况下，备份的运行时间似乎大致相同。
-vssFull 和 -vssCopy 的影响。
网络上偶尔会有一些关于完整、增量和差异备份的内容-vssFull和-vssCopy作用的讨论。在我看来，这两种观点根本不会影响wbengine决定要备份哪些文件的方式，因为更改日志总是被使用。-vssCopy尤其让人感到困惑的是以下内容：
复制备份不能用于增量或差异备份或恢复。
由于我认为基于映像的备份的工作方式以及上述描述，我不知道 MS 发出该警告是什么意思。我强烈猜测这句话与wbadmin它本身无关，而是与第三方产品有关，并且根据这种假设，该警告与文档中的内容一致-vssFull
如果您使用 Windows Server Backup 以外的产品来备份当前备份中包含的卷上的应用程序，请不要使用此参数。[...]
尽管-vssFull重置了文件的存档位，但我仍然相信这些位不会被用于wbengine决定在任何设置中备份哪些文件。相反，该参数仅告诉其他应用程序是否执行与备份相关的其他操作：
所有文件都已备份，每个文件的历史记录都已更新以反映其已备份，并且以前备份的日志可能会被截断。[...]
不过，不确定这是否会影响变更日志。我猜不会，因为这两个论点都有以下共同点：
所有文件都已备份[...]
这些论点的其他解释似乎也集中在第三方软件上：
因此，当您执行 VSS 完整备份时，您会创建所有文件的备份 - 但此后，备份应用程序可能会截断文件系统上的日志。
这些日志很可能是 Exchange 或数据库的日志，或者其他任何日志，我猜不是 NTFS 自己管理的那些更改日志。与上述来源相同：
最后一点技术说明：基于 VSS 的备份应用程序可以在备份会话开始时使用 IVssBackupComponents:: SetBackupState 指定备份类型（完整、复制、增量）。为此，任何实现 VSS 编写器的应用程序都可以选择在 OnBackupComplete VSS 事件中截断日志。这是基于 VSS 的备份应用程序（例如 DPM ）在备份会话结束时发送给所有受影响编写器的最后一个事件之一。
因此，在我看来，很明显，-vssFull并且-vssCopy只会影响文件备份后的行为方式，而不会影响要备份哪些文件或如何备份这些文件。对我来说，对wbadmin仅与网络-vssFull共享执行完全相同的命令-vssCopy行不会改变有关 VHD(X) 的任何内容。
答案2
“表现得像完整备份”并不意味着完整备份。它仍然基于增量备份系统，只是针对改进的恢复进行了优化，就像 Veeam 很久以前做的那样。您需要前面的几点。
如果您交替使用磁盘，则必须采取一些措施来保留两个磁盘上的所有增量点。
要解决您的问题，您必须配置 2 个单独的作业，并安排它们在您知道特定磁盘在线时运行。例如：在第 1、3、5 周等为磁盘 1 安排作业 1，在第 2、4、6 周等为磁盘 2 安排作业 2。间隔可以是您想要的间隔，只要备份找到正确的磁盘就行，这无关紧要。
详细步骤请参阅官方指南在这里。