Comments 9
Мощнейшая сложная статья! Спасибо дружище! Огромный труд.
ряд служебных баз Exchange
Не только служебных (очереди, например): базы данных, содержащие п/я и сообщения Exchange (*.edb) - это тоже ESE.
ESE поддерживает транзакции, так что БД, полученные в состоянии Dirty Shutdown можно восстановить утилитой работы с БД (eseutil / esentutl) в согласованнное состояние, применив к ним нужные файлы журнала транзакций. Диапазон номеров нужных для этого файлов журнала транзакций (*.log) указан в заголовке БД ESE.
Добрый день!
Большое спасибо за уточнения.
Не только служебных (очереди, например): базы данных, содержащие п/я и сообщения Exchange (*.edb) - это тоже ESE.
Да, немного некорректно выразился.
БД, полученные в состоянии Dirty Shutdown можно восстановить утилитой работы с БД (eseutil / esentutl) в согласованнное состояние, применив к ним нужные файлы журнала транзакций
В общем случае — да, но поскольку мы снимаем данные с хостов в обход стандартных средств (так как дампы снимаются с живой системы), то иногда попадаем в ситуацию, при которой БД не восстанавливается из журналов транзакций.
поскольку мы снимаем данные с хостов в обход стандартных средств (так как дампы снимаются с живой системы)
Что вам мешает снимать данные со снимка (теневой копии)? Поддержка теневых копий встроена в саму систему Windows давным-давно, доступна через команды vssadmin и diskshadow (последняя входит в компонент WindowsServerBackup, который может быть не установлен) . Делайте на живой системе теневую копию и снимайте на здоровье. Единственно, может потребоваться проявить некоторую аккуратность сделать теневую копию в режиме копирования (а не бэкапа). Или, как вариант, можно снимать данные с помощью Windows Backup (тоже в режиме копирования) - он в качестве резльата создает виртуальные диски (*.vxd), которые можно потом подключить в любой другой системе и работать с ними.
ESE поддерживает транзакции, так что БД, полученные в состоянии Dirty Shutdown можно восстановить утилитой работы с БД (eseutil / esentutl) в согласованнное состояние, применив к ним нужные файлы журнала транзакций
Все зависит от причин, по которым возникло "грязное" состояние. При копировании файлов путем прямого доступа к физическому диску — есть редкий шанс попасть в ситуацию, когда логи транзакций не спасут (они рассчитаны на сбой при записи, а не на медленное копирование одного файла, когда захватываются два его состояния: одно в начале копирования, другое в конце копирования).
Впрочем, любителей читать данные напрямую с диска C: (а не с PHYSICALDRIVE<X>) это не затрагивает — в современных версиях Windows попытка парсинга NTFS с логического диска приводит к тому, что драйвер переводит том в состояние, эквивалентное созданию теневой копии, когда некоторое время данные на диске "стабильны" (разумеется, при этом часть метаданных NTFS теряется).
При копировании файлов путем прямого доступа к физическому диску
Буквально недавно было, что принесли нам несколько vmdk файлов с контроллеров домена. И вот там были ошибки чексумм на страницах и неправильные ссылки на страницы (причём, явно было видно, что «выпали» конкретные блоки).
в современных версиях Windows
А не подскажете, пожалуйста, насколько современные версии имеются в виду? Посмотрел Вашу статью You write to a logical drive when you read from it, там упоминается только тестовый стенд на Windows 10.
Может быть, Вы проводили какие-то тесты на более старых версиях ОС?
Все зависит от причин, по которым возникло “грязное” состояние. При копировании файлов путем прямого доступа к физическому диску — есть редкий шанс попасть в ситуацию, когда логи транзакций не спасут (они рассчитаны на сбой при записи, а не на медленное копирование одного файла, когда захватываются два его состояния: одно в начале копирования, другое в конце копирования).
Речь идет в любом случае про согласованное состояние, когда файлы для копии берутся на определенный момент времени. В WIndows уже давно, начиная с Server 2003 (и XP начиная с какого-то Service Pack) для этого есть поддержка снимков (“теневых копий”), доступная через команды vssadmin и diskshadow: делаете теневую копию и забираете файлы с нее.
Речь идет в любом случае про согласованное состояние, когда файлы для копии берутся на определенный момент времени.
Нет же. Содержимое файлов читается "на лету", без их заморозки.
В WIndows уже давно, начиная с Server 2003 (и XP начиная с какого-то Service Pack) для этого есть поддержка снимков (“теневых копий”), доступная через команды vssadmin и diskshadow: делаете теневую копию и забираете файлы с нее.
Создание теневой копии — это слишком "шумно" (flush для приложений, затем flush для драйвера NTFS), да и можно потерять самую старую (и самую нужную, по закону подлости) теневую копию. Плюс, в теневых копиях не в серверных вариантах операционной системы может быть мусор вместо нужного содержимого файлов (в copy-on-write не включены по умолчанию пользовательские файлы начиная с Windows 8, это теперь фича для отката изменений системных файлов, а не для восстановления всяких документов).
Заглядываем внутрь ESE: от B+ деревьев до артефактов Windows