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 дня сервис работает без сбоев, посмотрим что будет дальше.
inok_dexter, подскажите.
1) Были у вас следующие сервисы:
msaccess , linked server, терминальные клиенты с 2003 или локальные пользователи XP?
2) Помните ли Вы момент когда у Вас начали возникать такие проблемы?
3) С чем Вы связываете данную ситуацию?
ComodoHacker, вы ознакомились со статьей на течнете? Если нет, тогда у большинства участников форума нет ошибок или предупреждений, которых можно связать с данной проблемой.
Забыл добавить, что единственным решением в данной ситуации это жесткий ребут при удалении процесса машины на гипервизоре. Если отправить vm на перегрузку в операционной системе, она не может завершится.
Если добавить к командлету export-csv параметр -Encoding UTF8,то документ выгружается без проблем.
Но Вы не поняли сути вопроса.
Почему при экспорте первой строки с символами кириллицы происходит выгрузка "вопросов", а при следующем экспорте в цикле строка отображается корректно в файле? На основании какой информации система смогла определить, что следующий экспорт в цикле должен быть в UTF8?
Мои умозаключения также выше в комментариях....
Если добавить к командлету export-csv параметр -Encoding UTF8,то документ выгружается без проблем.
Но для меня все еще остается загадкой, почему первая строка выгружается с вопросами, а последующие имеют правильно формирование.
И у меня есть только одно предположение:
$Output | export-csv C:\organization.csv -Append
Первоначально при передаче переменной через конвейер командлет экспорта проверяет наличие файла на диске и создает данный файл. Загружает информацию в том варианте, который первоначально был получен из переменной.
То при повторном выполнении в цикле командлета экспорт уже находит данный и файл и сравнивает его кодировку с той, кодировкой которая располагается в консоли и декодирует ее в соответствии с кодировкой файла.
hint000, lu1ssuarez,
Да! Видимо я уже в порывах циклического бегания по кругу начинаю что-то упускать... Спасибо за внесения ясности, но я все таки немного поспорю...
Не думаю что остнастка SMS это клиент в моем случаи, по крайней мере в том виде, в каком это принято понимать в клиент-серверной архитектуре. А именно работа через сеть, потому у нас она отсутствует при локальном подключении.
Простите, но вы о чем?
Мы открываем в базе данных "New Query" и запускаем функцию внутри базы данных.
ИП и доменное имя тут причем?
У нас работа только внутри базы данных, без каких либо способов внешнего взаимодейтсвия.
В том числе база данных никуда не обращается во время запроса.
Т.е. агент, который стоит на гипервизоре постоянно отслеживает изменения внутри виртуальных машин.
В момент старта р.к. внутри машины происходят процедуры для создания консистентной копии - шринк логов баз данных итд.
Далее создается чекпойнт ВМ для того, что можно было сохранить состояние машины и передать только измененные блоки внутри vhdx файла за прошедшие 15 минут.
По окончанию копированию блоков, их сверки на дедупликацию и выполнение сжатия для сохранения в датацентр, чекпойнт удаляется и происходит сливание его с vhdx файлом.
Мы замечаем, что резервные копии почти на всех крупных машинах сильно раздуваются, но в рамках примера откинули все сложные машины (SQL, PLM и так далее) и взяли почтовую систему, так как она работает без баз данных и использует файловую структуру для хранения.
С момента, как р.к. создает чекпойнт (или если сделать его вручную) он очень быстро разрастается в объеме. И размер прошлого чекпойна до момента слияния очень похож на размер переданных блоков в рамках следующего р.к.
Т.к. в этом промежутке мы не видим, что внутри происходит какая либо активность (500мб) за 15 минут, то совершенно не понятно откуда в рамках копии он находит 15-30гб измененных блоков.
P.S. Как было ранее сказан своп в данной машине не используется.