Ивор Барханский, видимо вы либо неправильно поняли поставленный вопрос, либо я что то не так указал.
В любом случаи решение в комментариях с моей стороной было указано.
Ивор Барханский, ну самый простой пример, если по каким то причинам вы локально запускаете установку нового программного обеспечения на рабочей станции под текущим доменным пользователем без прав администратора.
Alexey Dmitriev, агентный бекап показывает объем данных равный измененным - 500мб. Но данный вариант является проблемным, так как агентный бекап подразумеваем восстановление через bmr (bare metal recovery), что требует значительно больше времени.
Как я понимаю, мы имеем следующую картину:
1) В рамках первой р.к. создается avhd файл в котором происходят какие то изменения
2) По окончанию р.к. идет слияние снимка в vhd и cbt отмечает данные блоки как измененные, что в принципе верно.
Вопрос тут в сторону Hyper-v, что он пишет в vhdx за это время и как можно повлиять на его размер, если фактических данных в машине не меняется.
Ниже прошлый скриншот с агентным бекапом но включенным свопом:
Alexey Dmitriev, в рамках резервного копирования (далее р.к.) , как было написано выше, используется механизм CBT.
Т.е. агент, который стоит на гипервизоре постоянно отслеживает изменения внутри виртуальных машин.
В момент старта р.к. внутри машины происходят процедуры для создания консистентной копии - шринк логов баз данных итд.
Далее создается чекпойнт ВМ для того, что можно было сохранить состояние машины и передать только измененные блоки внутри vhdx файла за прошедшие 15 минут.
По окончанию копированию блоков, их сверки на дедупликацию и выполнение сжатия для сохранения в датацентр, чекпойнт удаляется и происходит сливание его с vhdx файлом.
Мы замечаем, что резервные копии почти на всех крупных машинах сильно раздуваются, но в рамках примера откинули все сложные машины (SQL, PLM и так далее) и взяли почтовую систему, так как она работает без баз данных и использует файловую структуру для хранения.
С момента, как р.к. создает чекпойнт (или если сделать его вручную) он очень быстро разрастается в объеме. И размер прошлого чекпойна до момента слияния очень похож на размер переданных блоков в рамках следующего р.к.
Т.к. в этом промежутке мы не видим, что внутри происходит какая либо активность (500мб) за 15 минут, то совершенно не понятно откуда в рамках копии он находит 15-30гб измененных блоков.
P.S. Как было ранее сказан своп в данной машине не используется.
Alexey Dmitriev, мы говорим о блочном резервном копировании с гипервизора.
Принцип работы без агентного копирования Arcserve аналогичен другим вендорам - Veeam,Symantec итд
Поэтому посмотреть, что внутри является проблемой, так как это не файлы, а изменённые блоки внутри машины. (Change Block Tracking)
Так как в 2012 r2 не было MS драйвера CBT, каждый вендор использовал свой. К сожалению размер отслеживаемого блока драйвером очень огромный и имеет размер 4 мегабайта. (ответ саппорта)
Но у меня есть подозрение, что это особенности самих чекпойнтов от Hyper-V, поэтому надеюсь услышать мнение другие коллег.
Имеется ввиду, что было несколько критических обновлений на домен контроллерах, которые не были установлены.
В том числе определенное кол-во других обновлений, включая обновления телеметрии.
Так как понять причину ошибок мы не могли, во время переустановки FS решили также установить полностью все обновления без разбора и на домен контроллеры.
"-Касперский кстати такой-же версии, попробую другую версию"
До переустановки мы пробовали отключать KES + агент, но спустя время также получали ошибки. P.S. Правда это было еще на 2008r2...
dmitrius8, неправильно поняли.
Мы используем сервер только как фс, но одно из дополнительных действий после переустановки - обновлены "по полной" контроллеры домена.
dmitrius8, да.
Ошибка пропала и уже стабильно работает в течении 3 недель. (раб. дни)
Изменения, которые были выявлены и которые могли повлиять на работу:
1) Первоначальный дистрибутив был скачен сотрудником с версией evoluation - https://www.microsoft.com/ru-ru/evalcenter/evaluat...
при переустановки был скачал с msdn аккаунта.(могу залить, если вам требуется - SW_DVD9_Windows_Svr_Std_and_DataCtr_2012_R2_64Bit_English_-4_MLF_X19-82891
2) Были до обновлены все контроллеры домена включая телеметрию
3) Вместо Kasperskyi Endpoint Security 11.4.0.233 установлен Kaspersky Security 10 for Windows Server_10.1.2.996. В ближайшее время планируем перевести на KE легкий агент для ВС.
4) Локаль РУ пока не была установлена, также диски не были слиты в 2 VHD и сейчас используем 4, access базы остались на другом сервере.
Процедуры по слиянию дисков, переноса шары с access базами, переустановки антивирусной системы и установки локали планируем после 4 рабочих недель. (т.е на следующей неделе). Они будут идти поэтапно с шагом в 1 неделю.
Так как ошибки 1020 описанные ранее у нас появлялись, мы смогли обнаружить дамп в -
%SystemRoot%\LiveKernelReports
Но выявить причину не смогли и решили пока отложить. Дамп формируется спустя некоторое время (от 10 минут), поэтому для его появления необходимо будет подождать. Возможно его появление уже не связано с нашей проблемой, так временной штамп отличается от старта проблемы.
Одни раз застал момент отвисая жесткого диска. Был подключен по RDP и вся система не была доступна в течении 20-40 секунд. (Rdp сессия активно, дисконекта не было, но все оснастки были неактивны). После машина отвисла и была обнаружена проблема.
Теперь относительно статьи:
support.microsoft.com/ru-ru/help/2957623/cannot-access-shared-files-or-folders-on-a-drive-in-windows-server-201
В ней рекомендация: NET STOP SERVER. NET START SERVER
И при выполнении данных действий мы получаем зависание службы, что говорит нам о проблеме с сервисом smb.
Добавление данных ключей позволяет отключить лизинг для протокола smb2, что возможно могло решить данную проблему.
На данный момент приняли решение повторно переустановить машину:
Обнаружил, что обновился дистрибутив от MSND с корп портала. И для установки использовал его - SW_DVD9_Windows_Svr_Std_and_DataCtr_2012_R2_64Bit_English_-4_MLF_X19-82891
Кол-во обновлений все равно более 200.
Шары переносились, через реестр.
Как писал ранее коллега, отключение SMB2,SMB3 мы пока не пробовали.
На данный момент 3 дня сервис работает без сбоев, посмотрим что будет дальше.
В любом случаи решение в комментариях с моей стороной было указано.