我目前正在使用 RSYNC 备份 VirtualBox 的一些虚拟机，这些虚拟机的 HDD 映像文件相当大。其中一些映像的大小为 100 GiB，其中一个甚至有 750 GiB。通过让 RSYNC 仅计算差异来备份这些文件花费太多时间，很可能是因为备份目标是一些较旧的 Synology DS1512+ NAS。虽然速度不是太慢，但使用--whole-file和不使用之间的差异很大：3 小时 vs. 12 小时后中止。
这就是为什么我考虑将这些大图像分割成较小的块，例如 2 GiB 大小。这应该可以实现虚拟盒只需将可用映像克隆到 VMDK 中分裂变体. 预期是由于虚拟机并不总是覆盖其全部可用数据，而只是其中的一部分，因此只有部分分割文件会被 RSYNC 识别为已更改且需要备份，从而最终降低总体时间。
当前使用的 RSYNC 选项如下：
--owner \
--numeric-ids \
--compress-level=0 \
--group \
--perms \
--rsh=rsh \
--devices \
--hard-links \
--inplace \
--whole-file \
--links \
--recursive \
--times \
--delete \
--delete-during \
--delete-excluded \
--rsync-path=[...] \
--specials
这是正确的吗？还是 VirtualBox 出于某种原因总是写入所有单个部分？还有其他需要考虑的因素吗？或者为什么这种方法可能不起作用？
谢谢！
答案1
这是正确的吗？或者 VirtualBox 是否因为某种原因总是写入所有单独的部分？
我已经将我的一台 Windows 10 转换为使用分割的 VMDK 文件，并让它在过去一周的大部分时间处于闲置状态。虽然 VirtualBox 不会写入所有单个文件，但它写入的内容远远超出了我在该情况下的预期。我已于 2020 年 10 月 25 日进行了转换，以下是 RSYNC 今天最终放到 NAS 上的内容。
需要注意的是，RSYNC 不会根据校验和决定传输什么，而实际上只会根据默认文件大小和时间戳来决定。因此，根据 VirtualBox 如何写入单个文件、何时刷新/关闭这些文件等，存在一定的风险。最后，在我的场景中，我没有其他选择，我根本无法努力读取所有数据来计算校验和，以比较备份源和目标之间的校验和。
total 73548036
358 0 drwxr-xr-x 1 1000 1000 2876 Oct 25 13:38 .
357 0 drwx------ 1 1000 1000 270 Oct 25 13:43 ..
364 1949056 -rw------- 1 1000 1000 1995833344 Oct 31 03:28 win10-s001.vmdk
365 2090752 -rw------- 1 1000 1000 2140930048 Oct 31 03:29 win10-s002.vmdk
366 2077056 -rw------- 1 1000 1000 2126905344 Oct 31 03:29 win10-s003.vmdk
367 2077120 -rw------- 1 1000 1000 2126970880 Oct 31 03:21 win10-s004.vmdk
368 2065664 -rw------- 1 1000 1000 2115239936 Oct 31 02:41 win10-s005.vmdk
369 2064960 -rw------- 1 1000 1000 2114519040 Oct 31 03:22 win10-s006.vmdk
370 2095232 -rw------- 1 1000 1000 2145517568 Oct 30 23:32 win10-s007.vmdk
371 2095744 -rw------- 1 1000 1000 2146041856 Oct 31 01:57 win10-s008.vmdk
372 2089600 -rw------- 1 1000 1000 2139750400 Oct 31 03:21 win10-s009.vmdk
373 2064256 -rw------- 1 1000 1000 2113798144 Oct 31 03:28 win10-s010.vmdk
374 2066112 -rw------- 1 1000 1000 2115698688 Oct 31 03:28 win10-s011.vmdk
375 2092480 -rw------- 1 1000 1000 2142699520 Oct 31 03:28 win10-s012.vmdk
376 2065664 -rw------- 1 1000 1000 2115239936 Oct 31 03:12 win10-s013.vmdk
377 2096384 -rw------- 1 1000 1000 2146697216 Oct 31 03:21 win10-s014.vmdk
378 2093184 -rw------- 1 1000 1000 2143420416 Oct 30 14:42 win10-s015.vmdk
379 2082688 -rw------- 1 1000 1000 2132672512 Oct 31 03:23 win10-s016.vmdk
380 2095872 -rw------- 1 1000 1000 2146172928 Oct 31 03:23 win10-s017.vmdk
381 2083264 -rw------- 1 1000 1000 2133262336 Oct 31 03:23 win10-s018.vmdk
382 1996416 -rw------- 1 1000 1000 2044329984 Oct 30 22:37 win10-s019.vmdk
383 2096384 -rw------- 1 1000 1000 2146697216 Oct 30 17:41 win10-s020.vmdk
384 2092160 -rw------- 1 1000 1000 2142371840 Oct 31 03:28 win10-s021.vmdk
385 2096448 -rw------- 1 1000 1000 2146762752 Oct 25 13:39 win10-s022.vmdk
386 2093504 -rw------- 1 1000 1000 2143748096 Oct 30 13:51 win10-s023.vmdk
387 2095680 -rw------- 1 1000 1000 2145976320 Oct 31 03:03 win10-s024.vmdk
388 2001728 -rw------- 1 1000 1000 2049769472 Oct 28 11:50 win10-s025.vmdk
389 2091008 -rw------- 1 1000 1000 2141192192 Oct 28 11:50 win10-s026.vmdk
390 2091648 -rw------- 1 1000 1000 2141847552 Oct 25 13:39 win10-s027.vmdk
391 2096000 -rw------- 1 1000 1000 2146304000 Oct 30 13:51 win10-s028.vmdk
392 2094976 -rw------- 1 1000 1000 2145255424 Oct 31 03:03 win10-s029.vmdk
393 2096448 -rw------- 1 1000 1000 2146762752 Oct 25 13:39 win10-s030.vmdk
394 1856640 -rw------- 1 1000 1000 1901199360 Oct 25 13:39 win10-s031.vmdk
395 2089600 -rw------- 1 1000 1000 2139750400 Oct 30 13:51 win10-s032.vmdk
396 2094336 -rw------- 1 1000 1000 2144600064 Oct 25 13:39 win10-s033.vmdk
397 2096448 -rw------- 1 1000 1000 2146762752 Oct 25 13:39 win10-s034.vmdk
398 1759936 -rw------- 1 1000 1000 1802174464 Oct 25 13:39 win10-s035.vmdk
399 320 -rw------- 1 1000 1000 327680 Oct 25 13:39 win10-s036.vmdk
400 289024 -rw------- 1 1000 1000 295960576 Oct 26 01:43 win10-s037.vmdk
401 1074240 -rw------- 1 1000 1000 1100021760 Oct 26 01:43 win10-s038.vmdk
402 4 -rw------- 1 1000 1000 2828 Oct 31 03:29 win10.vmdk
因此，虽然现在很明显有一些好处，但似乎比我希望的要少。但这可能只是与当前的操作系统有关，尤其是 Windows 有自动功能，如 Windows Search 等。在后台运行并写入数据。我将对一些目前具有 ~100 GiB 映像的 Linux-VM 进行同样的尝试，看看它是否会改变什么。
答案2
您的命令存在许多问题rsync，解决这些问题将有助于解决潜在的速度问题。因此，我将解决这个问题，而不是讨论如何拆分 VirtualBox 文件（如本问题中所述）。解决这些问题，其余的问题将变得无关紧要。
看看最近的评论您正在使用客户端/服务器方法rsync，这很好，因为这意味着可以使用基于块的更改：
rsync …options… /path/to/source/ remoteHost:/path/to/destination/
因此，您几乎肯定不会使用--whole-file，因为这将要求将源文件完整地复制，即使只更改了一个字节。对于您考虑的文件大小（即 VirtualDisk 映像，无论是分割的还是完整的），相对较慢的网络速度几乎肯定会淹没对话双方的任何直接磁盘读取rsync。
现在我们已经删除了--whole-file我们也应该删除，--in-place除非你是真的目标上的磁盘空间紧张，因为块被重新排列时需要大量额外的磁盘活动（读取和写入）。-z除非您有千兆网络连接（或更快）或 CPU 速度极慢，否则我建议包括（压缩）。
我要再次重申这一点，因为它非常重要：--whole-disk --in-place在这种情况下，对吞吐量的净效应是灾难性的。
我也不确定您是否使用--numeric-ids；我认为您可能正在尝试重新发明-M--fake-super，这可能是备份的更好选择。（如果使用 ，则-M--fake-super每次访问备份文件时都需要使用它，无论是写入还是读取。）请注意--fake-super需要启用扩展属性的文件系统。我不知道 Synology 是否默认这样做（QNAP 这样做，所以我假设 Synology 设备也这样做），因此您可能需要恢复-M--fake-super到numeric-ids。
尝试这组选项，而不是你当前的选项，看看有什么效果
-azH --delete -M--fake-super