Начиная с 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? И было ли это задокументировано?
(Для пояснения: вопрос выделен жирным шрифтом в предыдущем абзаце. Это не «как добавить второй диск в мой набор резервных копий», и не «как вообще работают инкрементные резервные копии».)
На мой взгляд, да.
Ниже приведены аргументы, на которых я основываю свой ответ, что позволяет провести дополнительное обсуждение. Есть еще некоторые аспекты того, как Windows Backup ведет себя в определенных условиях, в которых я не уверен, и люди могут захотеть уточнить или исправить меня. Тем не менее, думаю, о них стоит упомянуть.
Во-первых, в целом я согласен с вами и почти уверен, что wbadmin/wbengine реализует вариант 1, но у меня нет окончательного подтверждения этого и от Microsoft. Кроме того, я в некоторой степени уверен, что это не относится только к Windows Server, но работает так же для не-серверных выпусков Windows. Фактически, я использую именно вашу упомянутую настройку с 3 различными USB-дисками, начиная с Windows 7, уже для создания резервных копий на основе образов. 1 диск стоит на выезде, два меняют регулярно в течении недели.
Я вижу, что файлы VHD (X), содержащиеся на USB-дисках, всегда обновляются, и сколько времени занимает резервное копирование и какие файлы вообще передаются, действительно зависит от того, какие файлы были изменены, поскольку USB-диск, используемый в настоящее время в качестве цели резервного копирования, последний раз использовался. Это инкрементная часть, упомянутая в ваших документах, только различия резервного копирования, но эти различия всегда записываются в существующие файлы на VHD (X).
Windows Image Backup НЕ управляет инкрементной историей резервных копий самостоятельно, он ВСЕГДА перезаписывает существующие файлы на текущем VHD (X) в качестве целевого объекта резервного копирования. Поэтому НИКОГДА не требуется инкрементная история для восстановления с доступного в настоящее время VHD (X). В случае USB-дисков в формате NTFS история реализуется с помощью Объемные теневые копии: Перед выполнением новой резервной копии в целевой резервной копии создается теневая копия, только после этого wbengine открывает VHD (X) и при необходимости заменяет файлы в нем. Замена файлов выполняется НА МЕСТЕ, ПО-БЛОКУ, wbengine действительно читает измененные исходные файлы, сравнивает блоки чтения с такими же блоками в целевом объекте резервного копирования и перезаписывает только в случае изменений. Поскольку в целевом объекте резервного копирования есть теневая копия, VSS распознает эти измененные блоки, которые фактически являются измененными блоками VHD (X) в конечном итоге, и копирует данные перед перезаписью. Таким образом, все теневые копии в целевом объекте резервного копирования всегда содержат полнофункциональный VHD (X) системы, для которой ранее была создана резервная копия, и эти теневые копии в конечном итоге создают инкрементную историю. Поскольку все теневые копии содержат полнофункциональный виртуальный жесткий диск (X), дополнительные инкрементные данные не требуются, но можно просто подключить какой-нибудь моментальный снимок, виртуальный жесткий диск (X) в этом моментальном снимке, и при необходимости восстановить. VSS будет обрабатывать детали сбора связанных блоков.
Я не уверен в следующих моментах:
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 просто сделает полную резервную копию вместо инкрементной.
Использование этих журналов также позволяет довольно быстро узнать, какие файлы следует резервировать, поскольку нет необходимости перебирать все дерево файлов. Это то, что на самом деле можно увидеть и на практике: кажется, что резервное копирование довольно скоро знает, какие файлы нужно резервировать, и начинает их обрабатывать, а не повторять дерево файлов.
В случае резервного копирования в общие сетевые ресурсы, что wbengine действительно, похоже, зависит от используемой версии Windows, но в целом описанный ранее подход, согласно которому всегда имеется только один VHD (X) на резервный том в целевом объекте резервного копирования, похоже, также работает. Основное различие, по-видимому, заключается в том, как это достигается: либо путем перезаписи существующих файлов VHD (X), их удаления и воссоздания, либо, как в случае с USB-дисками, путем их открытия и изменения на месте.
Вот что говорят по этой теме некоторые документы и другие люди:
Если вы сохраните резервную копию в удаленной общей папке, эта резервная копия будет перезаписана, если вы снова воспользуетесь той же папкой для резервного копирования того же компьютера. [...]
Обратите внимание, что если вы выполняете резервное копирование в общий сетевой ресурс, полное резервное копирование будет запускаться каждый раз (поскольку 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, все резервные копии занимают почти одинаковое количество времени, даже если файлы в резервном источнике не сильно меняются.
В более новых версиях 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
Это не так много, как я ожидал, но у этого могут быть другие причины, поскольку в этой системе возникают проблемы с резервным копированием из-за слишком малого объема памяти. Собственно поэтому я снова исследую эту тему и пришел к этому вопросу. Если посмотреть на снимки других клиентов 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 касается полных, инкрементных и дифференциальных резервных копий. На мой взгляд, оба аргумента просто НЕ влияют на то, как 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 vs. -vssCopy к сетевому ресурсу ничего не меняет в отношении VHD (X) для меня.
«Действует как полная резервная копия» не означает полную резервную копию. Он по-прежнему основан на системе инкрементного резервного копирования, он просто оптимизирован для улучшенного восстановления, как это сделала Veeam давным-давно. Вам нужны предыдущие пункты.
Если вы чередуете диски, вам нужно будет что-то сделать, чтобы на обоих дисках были все точки инкремента.
Чтобы решить вашу проблему, вам нужно будет настроить 2 отдельных задания и запланировать их запуск, когда вы знаете, что определенный диск подключен к сети. Пример: запланировать задание 1 для диска 1 на 1,3,5 недели и т. Д. И jub 2 для диска 2 на недели 2,4,6 и т. Д. Интервал может быть желаемым, но не имеет значения, если резервная копия находит нужный диск на месте.
Для получения подробной информации см. официальный гид здесь.