2012r2+qnap iscsi таргет + перезагрузка = -1 месяц данных

[rezets]

Ситуация плачевная. Есть qnap, на нем создан 1 лун, в нем 1 таргет. Сервер подключился к этому таргету, далее разметили новый диск на весь размер, создали обычный диск под NTFS. В очередной раз пришлось перезагрузить сервер. В результате после перезагрузке диск не подключился: подключили вручную. Диск появился, но с данными месячной давности. Для понимания ошибок вводная: диск D - это локальный диск сервера, диск Е - как раз тот самый сетевой ISCSI диск, на котором данные и откатились на месяц.
Логи: в кунапе тишина
в r2 вот что:
сначала вот такая ошибка: volsnap 25: Теневые копии тома D: удалены из-за невозможности увеличения хранилища теневых копий. Уменьшите загрузку ввода-вывода для системы или выберите другой том для хранилища теневых копий, который не подлежит теневому копированию.
(самое интересное, что теневое копирование не стояло ни на одном диске, поэтому откуда это взялось - не понятно)
Затем:
NTFS код 55: Обнаружено повреждение в структуре файловой системы на томе E:. Точная природа повреждения неизвестна. Необходимо проверить структуры файловой системы в режиме подключения к сети. (ошибки 55 были и до предыдущих перезагрузок и всё было нормально)
- такие ошибки были до и после перезагрузки
NTFS 98: Том E: (\Device\HarddiskVolume8) необходимо перевести в автономный режим для полной проверки диска. Запустите команду "CHKDSK /F" локально с помощью командной строки либо выполните команду "REPAIR-VOLUME <диск:>" локально или удаленно с использованием PowerShell.

Итак, после перезагрузки в менеджере "управления дисками" на диске Е висела ошибка, мол давайте восстановим структуру, запустили. Все прошло успешно, но данные за месяц так и не появились.

Кто сталкивался с таким, что посоветуете?

[cameron]

исключительно в саппорт кунапа, а пока вынимать данные из бэкапов.

[rezets]

господа кунапа уже обрадовали, что это не их проблема, а проблема Microsoft, поскольку именно microsoft выступает в этом случае инициатором ISCSI. Мол только инициатор знает, как его использует и именно он дает команды на запись/перезапись, откаты и пр.

По сути получается, что r2 каким-то образом хранил снапшот за одним числом всех данных этого виртуального диска (ещё вопрос где и почему именно на ту дату, на которую он откатился) и в момент перезагрузки откатил его (понятно, что без возможности возврата).
Одно меня сильно смущает: как, с выключенной службой VSS он вообще это делал.
По-другому, была ещё вероятность конфликтов raid 1 на кунапе, но логи молчат о каких-либо косяках хардов, всё работало и работает в штатном режиме.

[cameron]

господа кунапа уже обрадовали, что это не их проблема, а проблема Microsoft, поскольку именно microsoft выступает в этом случае инициатором ISCSI. Мол только инициатор знает, как его использует и именно он дает команды на запись/перезапись, откаты и пр. »
ну, тут просто - покупаете обращение в саппорт МСа (если нет подписки) и пересылаете этот ответ в МС.
они либо оперативно нагибают кунап, чтобы неповадно было писать такое, либо расскажут почему произошёл косяк ;)

[rezets]

Спасибо за помощь, а не дадите ссылку на покупку саппорта?

[cameron]

http://blogs.msdn.com/b/paulfo/archive/2010/02/23/do-you-know-how-to-get-microsoft-technical-support.aspx

[rezets]

Cameron, спасибо за помощь. Пообщались с Microsoft, но в результате отказались от общего ответа за 149$. Тему можно закрывать, поскольку скорее всего тут отработал откат снапшота Microsoft на подключенном томе (кто подключил VSS на нем ещё будем разбираться), в любом случае теперь сидим пытаемся через linux поднять данные из скрытых данных.