Есть ли способ исправить это? Автоматическое добавочное резервное копирование Windows Server «хорошо работает» с несколькими дисками резервного копирования?
Начиная с 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? И было ли это задокументировано?
(Для пояснения: вопрос выделен жирным шрифтом в предыдущем абзаце. Это не «как добавить второй диск в мой набор резервных копий», и не «как вообще работают инкрементные резервные копии» .)
«Действует как полная резервная копия» не означает полную резервный. Он по-прежнему основан на системе инкрементного резервного копирования, он просто оптимизирован для улучшенного восстановления, как это сделала Veeam давным-давно. Вам нужны предыдущие точки.
Если вы чередуете диски, вам нужно будет что-то сделать, чтобы на обоих дисках оставались все точки инкремента.
Чтобы решить вашу проблему, вам нужно будет настроить 2 отдельных задания и запланировать их выполнение когда вы знаете, что конкретный диск находится в сети. Пример: запланировать задание 1 для диска 1 на 1, 3, 5 и т. Д. Недели и jub 2 для диска 2 на 2, 4, 6 и т.д. интервал может быть желаемым, это не имеет значения, если резервная копия находит нужный диск на месте.
Подробную процедуру см. в официальном руководстве здесь .
Хорошо ли работает автоматическое инкрементное резервное копирование Windows Server с несколькими дисками резервных копий?
На мой взгляд, да.
Следующее благодаря аргументам, на которых я основываю свой ответ, можно провести дополнительное обсуждение. Есть еще некоторые аспекты того, как Windows Backup ведет себя в определенных условиях, в которых я не уверен, и люди могут захотеть уточнить или исправить меня. Тем не менее, я думаю, что о них стоит упомянуть здесь.
Использует ли Windows Server Backup вариант 1 или вариант 2? И было ли это задокументировано?
Прежде всего, я согласен с вами и почти уверен, что 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) и при необходимости заменяет файлы в нем. Замена файлов выполняется IN-PLACE, BLOCK-BY-BLOCK, wbengine действительно читает измененные исходные файлы, сравнивает блоки чтения с такими же блоками в целевом объекте резервного копирования и перезаписывает только в случае изменений. Поскольку в целевом объекте резервного копирования есть теневая копия, VSS распознает эти измененные блоки, которые фактически являются измененными блоками VHD (X), и копирует их перед перезаписью. Таким образом, все теневые копии в целевом объекте резервного копирования всегда содержат полнофункциональный VHD (X) системы, для которой ранее была создана резервная копия, и эти теневые копии в конечном итоге создают инкрементную историю. Поскольку все теневые копии содержат полнофункциональный VHD (X), дополнительные инкрементные данные не требуются, но можно просто подключить какой-нибудь моментальный снимок, VHD (X) в этот моментальный снимок и восстановить при необходимости.VSS будет обрабатывать детали сбора связанных блоков.
Я не совсем уверен в следующих моментах:
Как Windows Image Backup решает, какие файлы следует резервировать?
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 Server 2008 R2.
В случае резервного копирования в общие сетевые ресурсы, то, что делает 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 ist es immer ein Vollbackup, wobei das letzte Backup überschrieben wird.
https://administrator.de/forum/verständnisfragen-windows-server-backup-2012-294395. Lookinghtml
в моих собственных тестах с использованием 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 Server 2012 +.
С более новыми версиями Windows, похоже, все немного по-другому: я несколько уверен, что у одного моего клиента возникли проблемы с wbadmin и Windows Server 2012 и во время отладки тех, кто использует Process Monitor,Я проверил, что существующие файлы VHDX были сохранены, а не удалены и воссозданы. Я проверил это прямо сейчас с Windows Server 2019 снова, и несколько вызовов wbadmin привели к успешному резервному копированию, в то время как ХРАНИТЬ inodes файлов 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 start backup –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.
В сети время от времени обсуждают, что -vssFull и ] -vssCopy относится к полному, инкрементному и дифференциальному резервному копированию. На мой взгляд, оба аргумента просто НЕ влияют на то, как wbengine решает, какие файлы вообще резервировать, потому что журналы изменений используются всегда. Что может сбивать с толку относительно -vssCopy , так это следующее:
Резервная копия не может использоваться для инкрементного или дифференциального резервного копирования или восстановления.
Из-за того, как, по моему мнению, работает резервное копирование на основе изображений и как описано выше, у меня есть понятия не имею, что означает MS с этим предупреждением. Я уверен, что это предложение НЕ имеет отношения к самому wbadmin , а к сторонним продуктам и при этом предположении, что предупреждение будет соответствовать тому, что указано в документе для -vssFull
Do не используйте этот параметр, если вы используете продукт, отличный от Windows Server Backup, для резервного копирования приложений, находящихся на томах, включенных в текущую резервную копию. [...]
Даже если -vssFull сбрасывает архив бит файлов, я все еще убежден, что эти биты НЕ используются wbengine для принятия решения о том, какие файлы резервировать в любой настройке. Вместо этого этот аргумент сообщает другим приложениям, только если они должны выполнять дополнительные действия, связанные с резервным копированием:
Все файлы резервируются, история каждого файла обновляется, чтобы отразить, что он был зарезервирован, а журналы предыдущих резервных копий могут быть усечены. [ ...]
Не уверен, что это влияет на журналы изменений.Думаю, не потому, что оба аргумента имеют следующее общее утверждение:
Все файлы зарезервированы [...]
Другие объяснения этих аргументов, похоже, также касаются стороннего программного обеспечения:
Итак, когда вы делаете полное резервное копирование VSS, вы создаете резервную копию всех файлов, но после этого приложение резервного копирования может обрезать журналы в файловой системе.
Эти журналы принадлежат Exchange, базам данных или чему-то еще, скорее всего, но не журналам изменений. NTFS справляется сама по себе. Тот же источник, что и выше:
Просто последнее техническое примечание: тип резервного копирования (полное, копирование, инкрементное) может быть указан приложением резервного копирования на основе VSS в начале сеанса резервного копирования с помощью IVssBackupComponents :: SetBackupState. В ответ на это любое приложение, реализующее средство записи VSS, может выбрать усечение журналов в событии OnBackupComplete VSS. Это одно из последних событий, которые приложение резервного копирования на основе VSS (например, DPM) отправляет всем затронутым модулям записи в конце сеанса резервного копирования.
Так что, на мой взгляд, очевидно, что -vssFull и -vssCopy влияет только на поведение ПО ПОСЛЕ того, как файлы были скопированы, и НЕ влияет на то, какие файлы для резервного копирования или как они будут скопированы. Выполнение той же командной строки для wbadmin с использованием только -vssFull vs. -vssCopy в сетевой папке также ничего не меняет в отношении VHD (X) для меня.