Это продолжение того, что я записал в Ответ к Другой вопрос:
Я несколько уверен, что wbengine Windows Server 2008 R2 всегда создает новые файлы VHD, если нацелены на общий сетевой ресурс. Вот что говорят по этой теме некоторые документы и другие люди:
Если вы сохраните резервную копию в удаленной общей папке, эта резервная копия будет перезаписана, если вы снова воспользуетесь той же папкой для резервного копирования того же компьютера. [...]
Обратите внимание, что если вы выполняете резервное копирование в общий сетевой ресурс, полное резервное копирование будет запускаться каждый раз (поскольку VSS недоступен), перезаписывая предыдущую полную резервную копию. В этом случае нет никакой политики резервного копирования, вы просто поддерживаете удаленную тень / копию системы.
https://lennox-it.uk/a-complete-guide-to-wbadmin-windows-backups
Das kommt darauf an auf welches Medium du sicherst. Wenn auf Festplatten ect. gesichert wird, dann wird immer inkrementell gesichert. Wird auf ein Share gesichert, dann is immer ein Vollbackup, wobei das letzte Backup überschrieben wird.
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-дисках, где изображения сохраняют свои имена и идентификаторы файлов (/ inodes), и только большинство файлов XML получают новые UUID. На USB-дисках родительский каталог VHD (X) также изменяется, но это просто переименование и, следовательно, никак не влияет на дочерние файлы. В какой-то момент во время тестов мне удалось wbengine решил оставить имена файлов VHD, но их индекс всегда менялся. Однако не вызывался с новой командной строкой, а просто впоследствии:
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 выбрала эту реализацию воссоздания файлов изображений?
Единственное, что приходит мне в голову, - это размер файла изображения, поскольку я где-то читал, что файлы VHD нельзя эффективно сжать, и это улучшилось с помощью VHDX. В новых версиях Windows используется VHDX, и я действительно вижу, что эти файлы используются повторно, сохраняя их inode, что делает их немного лучше совместимыми со снимками BTRFS и ZFS.
Другие причины, может быть, официальные заявления?