为什么 Windows Server 2008 R2 的“wbengine”在针对网络共享时总是创建新的 VHD 文件?

为什么 Windows Server 2008 R2 的“wbengine”在针对网络共享时总是创建新的 VHD 文件?

这是我在一个答案另一个问题

我有点确定,wbengine如果以网络共享为目标,Windows Server 2008 R2 总是会创建新的 VHD 文件。以下是一些文档和其他人对该主题的看法:

如果将备份保存到远程共享文件夹,则当您再次使用同一文件夹备份同一台计算机时,该备份将被覆盖。[...]

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc742130(v=ws.10)

请注意,如果您要备份到网络共享,则每次都会运行完整备份(因为 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,所有备份几乎都花费相同的时间,即使备份源中的文件没有太多变化。

那么,为什么 MS 选择重新创建图像文件的实现方式呢?

答案1

我唯一想到的是图像文件大小,因为我在某处读到过 VHD 文件无法有效缩小,而 VHDX 可以改善这种情况。较新版本的 Windows 使用 VHDX,对于这些文件,我确实看到这些文件被重复使用,保留了它们的 inode,使它们与 BTRFS 和 ZFS 的快照更好地兼容。

其他原因,也许是官方声明?

相关内容