Это продолжение того, что я записал в Ответ к Другой вопрос:
Windows / NTFS управляет изменить журналы на каждом томе, отслеживая, какой файл был изменен, как он изменился, и поскольку они по умолчанию являются частью всех томов NTFS, они также доступны на VHD (X) целевого объекта резервного копирования. Насколько я понимаю, wbengine просто сравнивает эти журналы, чтобы узнать, какие файлы нуждаются в резервном копировании. Это упрощает поддержку различных целей резервного копирования, не заботясь об архивных битах файлов или тому подобном, потому что эти журналы изменений привязаны к уникальным для тома идентификаторам файлов, и эти идентификаторы точно такие же в целевой резервной копии:
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), какие файлы необходимо скопировать, если текущий журнал и журнал в образе имеют что-то общее, а это идентификаторы записей в моем понимание. Без такого общего идентификатора, например потому что слишком много операций ввода-вывода произошло продуктивно, а резервная копия слишком старая, wbengine просто сделает полную резервную копию вместо инкрементной.
Использование этих журналов также позволяет довольно быстро узнать, какие файлы следует резервировать, поскольку нет необходимости перебирать все дерево файлов. Это то, что на самом деле можно увидеть и на практике: кажется, что резервное копирование довольно скоро знает, какие файлы нужно резервировать, и начинает их обрабатывать, а не повторять дерево файлов.
В более старых версиях Windows wbengine кажется, всегда воссоздавал файлы VHD, что делает его несовместимым со снимками, поддерживаемыми какой-либо базовой файловой системой, такой как BTRFS или ZFS. Кроме того, каждая резервная копия была полной просто потому, что wbengine не было доступа к какой-либо предыдущей резервной копии для сравнения.
В более новых версиях Windows все выглядит немного иначе: я несколько уверен, что у одного из моих клиентов возникли проблемы с wbadmin и Windows Server 2012, а во время отладки тех, которые используют Process Monitor, я убедился, что существующие файлы VHDX сохраняются, а не удаляются и создаются заново. Я проверил это прямо сейчас с Windows Server 2019 снова и с несколькими вызовами wbadmin привело к успешному резервному копированию при сохранении неизменных индексов файлов VHDX:
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 vs. -vssCopy не повлиял на мои тесты и, как я понимаю, даже не предназначен для этого. Эти аргументы относятся только к стороннему программному обеспечению и не влияют на то, какие файлы копируются. Причины верить в это описаны в моем предыдущем ответе:
Влияние -vssFull и -vssCopy.
https://serverfault.com/a/990394/333397
Один из моих клиентов использует 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 раза больше времени, что снова похоже на полное резервное копирование. Это соответствовало бы тому, что я где-то читал, что Server Backup автоматически выполняет полные резервные копии каждые 14 дней, а затем только инкрементные. Но это не объясняет, почему мой Server 2019, похоже, так себя не ведет.
Единственная разница в используемой командной строке, которую я вижу, это -allCritical -systemState используется для Server 2016, в то время как Server 2019 использует -include:c:,d: вместо этого по некоторым причинам. В любом случае, оба использовали -vssCopy, как и ожидалось, используя это или -vssFull не должно иметь никакого значения.
Делает wbengine Windows Server 2019 поддерживает инкрементное резервное копирование при нацеливании на общие сетевые ресурсы? Если да, то при каких условиях, например аргументах командной строки? Кто-нибудь видит улучшение времени резервного копирования и распределения хранилища в случае моментальных снимков?