Судебная экспертиза базы данных Microsoft SQL Server

Экспертиза нужна, когда спор зависит от того, что происходило с базой Microsoft SQL Server: какие данные и объекты существовали в определённый момент, какие операции отражены в сохранённых источниках, чем вызван сбой, можно ли реконструировать прежнее состояние и полностью ли выполнена миграция. Специалист исследует не только таблицы, но и точную версию и редакцию сервера, параметры базы, журнал транзакций, резервные копии, аудит, диагностические события и материалы связанного приложения. Экспертиза Microsoft SQL Server — специализированное направление экспертизы баз данных и СУБД.

До начала исследования можно оценить, достаточно ли сохранившихся материалов и насколько определённым может быть вывод. Специалист просмотрит перечень файлов базы, полных, дифференциальных и журнальных копий, сведения о модели восстановления, SQL Server Audit, Extended Events и других источниках. Предварительный прогноз покажет, охвачен ли нужный период и можно ли безопасно развернуть стенд; он может быть и неблагоприятным, например при разрыве цепочки резервных копий журнала. Окончательный вывод формируют после исследования всего согласованного комплекта объектов.

Если записи только что удалены, база перешла в состояние SUSPECT или произошёл неудачный перенос, не запускайте DBCC с параметрами исправления, SHRINKFILE, отсоединение и повторное присоединение базы, удаление файла журнала, переключение модели восстановления либо восстановление поверх единственного экземпляра. Зафиксируйте время и часовой пояс, состояние экземпляра и реплик, версию, редакцию, номер сборки и перечень копий. Систему не останавливайте, а копию снимайте как можно раньше — но не самовольно: согласуют не сам факт копирования, а полномочия и способ, то есть кто выполняет, какой командой и как фиксируется результат. Если система принадлежит другой стороне, доказательство сохраняют через суд. Для первого обращения достаточно описания ситуации: не отправляйте рабочую базу, сертификаты, ключи шифрования и пароли до согласования защищённого канала.

Отдельно о том, что будет, если ответить не удастся. Задачу, по которой уже из присланных материалов видно, что вывода не получится, мы просто не берём в работу и говорим об этом сразу. Это не обещание положительного вывода: отказ на входе означает лишь, что невозможность видна уже из перечня материалов. Если же невозможность выясняется по итогам полноценного исследования, это результат, а не пустой счёт: заключение объясняет, почему ответа нет и чего именно не хватило. В споре такой вывод часто закрывает вопрос: обоснованный ответ, что цепочка резервных копий за спорный период разорвана, показывает суду границы имеющихся источников. Назначать ли после этого дополнительную или повторную экспертизу, решает назначивший её орган. Бывает и частичная невозможность: тогда указывают, на какие вопросы ответ получен, а на какие нет и по какой причине.

Кто снимает копию, решают по объекту. Иногда это делает сам заказчик или его администратор по согласованному плану; иногда — наш специалист, удалённо или с выездом, как отдельная консультация; иногда фиксация входит в саму экспертизу. Выбор зависит от сложности системы, доступности и трудоёмкости: копию базы и цепочку резервных копий снимают по-разному на одиночном сервере и на нагруженном кластере. Если инфраструктурой управляет другая сторона, порядок доступа определяет суд, и фиксацию проводят с участием эксперта.

Сначала установите модель восстановления. В простой модели резервные копии журнала не поддерживаются, и сохранять нечего — переходите к копии файлов базы и существующих резервных копий. В полной и BULK_LOGGED ещё не выгруженную часть журнала снимают резервной копией журнала с параметром COPY_ONLY: обычная копия усекает журнал и отдаёт неактивные его части под перезапись, а следы в файле .ldf нужны исследованию.

Собственно копия хвоста журнала с параметром WITH NORECOVERY переводит базу в состояние восстановления, то есть выводит её из работы. Её делают только тогда, когда база уже недоступна или сразу за ней следует восстановление, и делает это администратор владельца системы по согласованному плану. Если система принадлежит другой стороне, это предмет ходатайства об обеспечении доказательств, а не самостоятельных действий.

Копию журналов и резервных копий вывезите на отдельный носитель с контрольными суммами. После этого штатное резервное копирование журнала не останавливайте: в полной модели восстановления журнал без него растёт, пока не заполнит диск, и база перестаёт принимать записи. Копия содержит сведения о людях и коммерческую информацию, поэтому объём доступа, необходимость обезличивания, круг допущенных лиц и порядок удаления рабочих копий согласуют до передачи.

Когда нужна экспертиза Microsoft SQL Server

Специализация на SQL Server нужна, когда ответ зависит от внутренних объектов, правил журналирования и возможностей конкретной версии продукта. Названия Microsoft SQL Server, Azure SQL Database и Azure SQL Managed Instance не взаимозаменяемы: способы доступа, резервного копирования, аудита и получения служебных данных различаются. Поэтому сначала идентифицируют фактическую среду, редакцию, номер сборки, уровень совместимости базы и действовавшие настройки.

Типичные задачи, для которых нужна экспертиза SQL Server:

• нужно сопоставить данные, схемы, ограничения, индексы, представления, триггеры, хранимые процедуры, функции, задания SQL Server Agent, логины, пользователи, роли или права;
• спор относится к изменению или удалению записей и сохранности следов в журнале транзакций, резервных копиях журнала, SQL Server Audit, Extended Events, CDC, temporal tables либо журналах приложения;
• требуется проверить возможность восстановления на заданный момент, целостность цепочки LSN, полноту резервных копий или причины потери данных;
• нужно исследовать повреждение страниц, ошибки ввода-вывода, блокировки, взаимоблокировки, планы запросов, Query Store, Always On или зафиксированный отказ;
• стороны расходятся в оценке миграции в SQL Server либо из него, совместимости типов, правил сравнения, идентификаторов и программной логики;
• необходимо проверить реализацию базы по измеримым требованиям технического задания, спецификации или SLA.

История конкретных строк подробнее исследуется при экспертизе изменений и удаления данных, перенос — при экспертизе миграции баз данных, а замедления и отказы — при экспертизе производительности и сбоев СУБД. Если основной вопрос относится к приложению, 1С или исполнению договора, SQL Server исследуют как один из компонентов системы, не подменяя анализом базы проверку всего программного продукта.

Что может установить эксперт

Возможность ответа определяется сохранностью материалов и тем, какие механизмы были включены в спорный период. Эксперт сопоставляет независимые источники, проверяет временную привязку и альтернативные объяснения, а вывод формулирует только в пределах подтверждаемых технических данных.

При достаточных материалах эксперт может установить:

• продукт, версию, редакцию и параметры экземпляра, состав баз, файлов, схем, таблиц, столбцов, индексов, ограничений, пользователей и прав;
• содержимое указанных записей в представленной копии и различия между экземплярами, резервными копиями или состояниями базы;
• последовательность и технические признаки операций в пределах сохранившегося журнала, log backup, аудита, событий и журналов приложения;
• возможность штатного восстановления состояния на заданный момент, а в специализированном сценарии — до обоснованной отметки или LSN, при наличии подходящей базовой копии и непрерывной последовательности журналов;
• механизм формирования значения запросом T-SQL, представлением, триггером, процедурой, функцией, заданием Agent или связанной частью приложения;
• признаки физической или логической несогласованности и подтверждаемые причины сбоя, деградации запросов или рассогласования реплик;
• полноту миграции и соответствие перечисленных объектов проверяемым требованиям документации.

Журнал транзакций фиксирует транзакции и изменения базы, а каждой записи журнала соответствует log sequence number — LSN. Однако журнал не является персональным аудитом и не обязан хранить исходный текст каждого запроса или сведения о человеке за учётной записью. Логин, session ID, имя приложения, адрес клиента и имя узла помогают сопоставить источники, но сами по себе не доказывают, какое физическое лицо действовало, имело ли оно полномочия и каков был умысел. Эксперт устанавливает технические обстоятельства в пределах представленных материалов; виновность, умысел, правомерность действий, нарушение договора и иные правовые последствия оценивает суд или иной уполномоченный орган.

Какие объекты исследуются

Набор объектов выбирают под вопрос и период. Одна выгрузка таблиц может показать текущее содержимое, но обычно не сохраняет журнал транзакций, конфигурацию экземпляра, серверные объекты, историю аудита и физическое состояние страниц. Поэтому до копирования составляют перечень всех доступных источников.

Файлы базы и резервные копии

Исследуются основные и дополнительные файлы данных, обычно имеющие расширения .mdf и .ndf, файлы журнала .ldf, а также полные, дифференциальные и журнальные резервные копии. Расширение файла — только ориентир: тип и принадлежность базе подтверждают по заголовкам набора, DatabaseBackupLSN, FirstLSN, LastLSN, RecoveryForkID, DatabaseGUID и другим метаданным. Для differential отдельно сверяют DifferentialBaseLSN, DifferentialBaseGUID и IsCopyOnly. Для TDE на стенде должен быть доступен сертификат или асимметричный ключ, защищающий DEK; при переносе сертификата нужны закрытый ключ и пароль его экспорта. Для отдельно зашифрованной резервной копии требуется encryptor, использованный при её создании.

Копирование файлов работающей базы обычными средствами может дать несогласованный набор. Для каждого завершённого объекта фиксируют источник и владельца, время и часовой пояс передачи, способ и версию инструмента получения, размер, идентификатор и криптографическое хэш-значение с указанием алгоритма; проверки повторяют при приёме и перед исследованием. Исходные MDF, NDF и LDF и контрольную копию не подключают к SQL Server: для каждого опыта создают отдельную производную копию. При первом attach или startup сервер выполняет recovery и изменяет рабочие файлы, а более новая версия может обновить формат базы. RESTORE VERIFYONLY полезен для предварительной проверки читаемости и полноты резервной копии, но не заменяет пробное восстановление и проверку целостности.

Схема, конфигурация и серверные объекты

На уровне базы сопоставляют DDL, таблицы, ограничения, индексы, представления, синонимы, последовательности, триггеры, процедуры, функции, сборки CLR, Service Broker, full-text и параметры ALTER DATABASE. На уровне экземпляра важны startup parameters, sp_configure, endpoints, linked servers, credentials, logins, server roles, Resource Governor и настройки сети. Для заданий, операторов и истории SQL Server Agent, планов обслуживания и сведений о резервном копировании может потребоваться база msdb; для серверных логинов и конфигурации — соответствующие системные базы и экспортированные метаданные.

Аудит, события и журналы инфраструктуры

Сопоставляются SQL Server Audit, файлы Extended Events, SQL Server error log, история Agent, Windows Event Log, журналы приложения, прокси, балансировщика, системы управления доступом, кластера и хранилища. Для каждого источника проверяют, был ли он включён в нужный период, какие события и action groups собирались, куда писались данные, действовали ли фильтры, ротация и срок хранения, синхронизировались ли часы. Отсутствие записи в выключенном, неполном или уже перезаписанном журнале не доказывает отсутствия действия.

Передача копии, в которой есть сведения о людях или охраняемая законом тайна, требует законного основания. По назначенной экспертизе объекты поступают от назначившего органа; вне процесса — от обладателя сведений и в объёме, необходимом для ответа на поставленные вопросы. Обезличивание при этом обсуждают не как уступку, а как способ передать меньше, чем есть. Эксперт не разглашает сведения, ставшие известными ему в связи с исследованием, а рабочие копии удаляет по окончании работы.

Журнал транзакций, LSN и восстановление

Каждая база SQL Server имеет журнал транзакций. Записи создаются последовательно и идентифицируются LSN; активная часть нужна для восстановления базы. Неактивные виртуальные файлы журнала — VLF — могут быть исключены из логического журнала и освобождены для повторного использования. Усечение происходит по границам VLF, само по себе не уменьшает физический файл и не гарантирует сохранность прежних записей для экспертного чтения.

Модель восстановления определяет обслуживание журнала и доступные варианты восстановления. В SIMPLE резервные копии журнала не поддерживаются, а возврат к произвольному моменту между резервными копиями данных невозможен. FULL и BULK_LOGGED допускают резервное копирование журнала, но само значение FULL ещё не подтверждает непрерывную цепочку. Проверяют подходящую базовую копию и последовательность log backup, которая в нужной ветви восстановления покрывает диапазон от DatabaseBackupLSN до целевой точки. Если log backup в BULK_LOGGED содержит минимально журналируемые массовые операции, восстановление на произвольный момент внутри такой копии ограничено.

Для штатного восстановления средствами RESTORE обычно разворачивают подходящую полную копию, при наличии — нужную дифференциальную, затем последовательно применяют резервные копии журнала до заданного времени или отмеченной транзакции. Восстановление до LSN — специализированный режим через STOPATMARK или STOPBEFOREMARK; выбор отметки и включение либо исключение её записи должны быть обоснованы. При аварии может потребоваться tail-log backup, если его получение возможно и согласовано. Экспертная реконструкция отдельных сведений по сохранившимся следам не равнозначна восстановлению исходной базы: её полноту и ограничения оценивают отдельно.

Audit, Extended Events и история изменений

SQL Server Audit использует инфраструктуру Extended Events и может записывать выбранные серверные и базовые действия в audit file либо журналы Windows. Он полезен только в пределах реально созданных audit specification, включённого состояния, фильтров и сохранённых целей. Extended Events — настраиваемый диагностический механизм: сессия собирает лишь выбранные события и действия, а ring buffer или event file имеют собственные ограничения хранения. Ни Audit, ни Extended Events нельзя считать автоматически включённой бесконечной историей.

Change Data Capture сохраняет сведения о DML для включённых таблиц, включая тип операции и изменённые данные, но работает через асинхронное считывание журнала и обслуживается политикой очистки. Change Tracking идентифицирует изменённые строки и последнюю операцию относительно базовой версии; сведения о столбцах доступны только при TRACK_COLUMNS_UPDATED = ON, а несколько изменений одной строки могут быть объединены. Прежние значения и полную хронологию этот механизм не хранит. Системно-версионные temporal tables сохраняют предыдущие версии строк после включения versioning, однако периодные значения отражают UTC-время начала транзакции, а не обязательно время отдельного оператора или commit. Несколько изменений одной транзакции проверяют непосредственно в history table. Встроенная политика retention доступна с SQL Server 2017; для более ранней версии нужен иной контролируемый способ очистки. Задним числом создать отсутствовавшую историю нельзя.

Query Store хранит тексты запросов, планы и агрегированную статистику выполнения по временным интервалам в пределах настроек capture mode, размера и срока очистки. Он помогает исследовать регрессии и нагрузку, но не заменяет аудит пользователя и не показывает прежние значения каждой строки. Текущие dynamic management views также отражают состояние на момент сбора либо ограниченную историю с запуска, поэтому для ретроспективного вывода нужны сохранённые выгрузки или мониторинг за спорный период.

Что сделать до экспертизы, чтобы сохранить данные и журналы

Полностью исключить изменение работающего экземпляра нельзя: даже чтение создаёт соединения, нагрузку и возможные записи в аудит, а сама система продолжает выполнять транзакции, повторно использовать VLF и очищать диагностические данные. Для live-сбора заранее утверждают минимально необходимое воздействие, фиксируют время и синхронизацию часов, состояние экземпляра, учётную запись, перечень и порядок команд, а после — фактически созданные записи и другие изменения. Тип резервной копии выбирают вместе с ответственным администратором с учётом действующей схемы; при необходимости рассматривают COPY_ONLY и документируют влияние операции на differential base, log chain, truncation, msdb, аудит и доступность.

До получения копии и начала исследования:

• не удаляйте и не пересоздавайте .ldf, не выполняйте DBCC SHRINKFILE, DBCC CHECKDB с REPAIR_ALLOW_DATA_LOSS, detach/attach или восстановление поверх единственной спорной базы;
• не переключайте recovery model, не прерывайте цепочку log backup, не очищайте audit, Extended Events, Agent history, CDC или temporal history до фиксации;
• не запускайте failover, resume/suspend data movement, повторную миграцию или массовое исправление без оценки влияния на следы и доступность;
• сохраните полную версию и номер сборки, edition, instance и database name, database_id и database_guid, recovery model, compatibility level, collation, параметры времени и состояние Always On;
• зафиксируйте для каждого файла и набора резервной копии источник, владельца, передавших и принявших лиц, время и часовой пояс, носитель, способ и версию инструмента получения, все доступы и передачи, размеры и повторно проверяемые хэш-значения завершённых копий;
• отдельно сохраните сертификаты и ключи TDE и backup encryption, но передавайте их только согласованным защищённым способом.

DBCC CHECKDB выполняет предусмотренные выбранными параметрами проверки физической, allocation-, catalog- и части логической согласованности. Охват зависит от версии, compatibility level и опций и не включает бизнес-семантику данных; чистый результат нельзя распространять на невыполненные классы проверок. Команда создаёт нагрузку, а параметры repair могут изменить или удалить данные. Основной способ исправления повреждений — восстановление из заведомо исправной копии; исходное состояние исследуют до ремонта и на отдельном экземпляре. PAGE_VERIFY CHECKSUM помогает обнаруживать изменение страницы после записи на диск при последующем чтении, но успешная checksum не доказывает отсутствие логически корректного изменения данных.

Always On, сбои и производительность

В Always On Availability Groups первичная реплика передаёт записи журнала вторичным, которые сохраняют и применяют их. Вторичная реплика повышает доступность, но не является независимой резервной копией: ошибочное удаление или логически корректное изменение может распространиться на неё. При подключённой реплике в состоянии SYNCHRONIZED synchronous commit ожидает hardening журнала и допускает failover без потери подтверждённых транзакций. Если синхронизированной реплики нет, используется asynchronous commit либо выполняется forced failover, возможна потеря данных. Ни один из режимов не защищает от ошибочной операции. Исследуются роли и состояние реплик, очереди отправки и повторного выполнения, режим commit, failover, cluster log и резервные копии.

При сбое или замедлении сопоставляют SQL Server error log, Extended Events и deadlock graphs, Query Store, планы выполнения, wait statistics, блокировки, TempDB, memory grants, статистику, параметры параллелизма, ввод-вывод, счётчики Windows и состояние хранилища. Текущий Activity Monitor или снимок DMV не доказывает прошлое состояние, а один медленный запрос не объясняет причину без параметров, данных, плана и нагрузки за тот же период. Если исследуется путь атаки, вредоносное ПО или компрометация учётных данных за пределами базы, может потребоваться экспертиза инцидентов информационной безопасности.

Как проверить миграцию

Равное количество строк — только начальный критерий. Сопоставляют перечень схем и объектов, ключи и ограничения, identity и sequence, типы и точность чисел, даты и часовые пояса, NULL, значения по умолчанию, computed columns, collations, регистр и акценты, индексы, представления, триггеры, процедуры, функции, Agent jobs, Service Broker, CLR, full-text, пользователей и права. Отдельно проверяют отбракованные записи, преобразования, повторные запуски и изменения после контрольной точки.

Сверка должна быть воспроизводимой: указываются версия источника и приёмника, момент фиксации, карта соответствия, запросы, алгоритмы хэширования и допустимые различия. При переходе между SQL Server, PostgreSQL, Oracle, MySQL или другой СУБД одинаковые имена таблиц не означают одинаковое поведение: различаются типы, генерация идентификаторов, правила сравнения, уровни изоляции, программные объекты и семантика отдельных выражений T-SQL.

Как проходит исследование

Методика зависит от вопроса, но ход работы должен оставаться проверяемым другим специалистом. Каждый вывод связывают с идентифицированным объектом, командой, результатом и установленным ограничением.

Обычно исследование проходит так:

1. Уточняется задача. Фиксируются экземпляр и база, продукт, версия, редакция, период, часовой пояс, спорные объекты и технический критерий.
2. Инвентаризируются источники. Описываются файлы, backup sets, журнал, системные базы, аудит, события, реплики, приложение и документы.
3. Сохраняется исходное состояние. Проверяются происхождение, способ копирования, идентификаторы, хэш-значения и непрерывность цепочки передачи.
4. Создаётся совместимый стенд. Восстановление и потенциально изменяющие проверки выполняются на рабочих копиях, а не на единственном источнике.
5. Проверяются гипотезы. Сопоставляются данные, LSN, audit records, event files, временные метки, запросы, конфигурация и альтернативные причины.
6. Формируется вывод. Указывается, что установлено, какими объектами подтверждается, что не проверено и почему.

Снимок экрана из SSMS не заменяет первичный источник. Он может помочь определить объект, запрос или время, но результат проверяют по файлам, резервным копиям, выгрузкам, журналам и воспроизводимым действиям. Если исходная база недоступна, в заключении прямо разграничивают подтверждённые сведения и предположения по вторичным материалам.

Как выбрать формат работы

Формат выбирают по стадии спора и по тому, что нужно получить: ответ по существу или помощь в подготовке задания. Один и тот же комплект файлов SQL Server — база, цепочка резервных копий, записи Audit — годится для любого формата, но подменять консультацию исследованием, а прогноз рецензией нельзя.

В зависимости от задачи можно выбрать:

• Консультация отвечает на вопрос, что вообще можно установить по вашей модели восстановления и сохранившейся цепочке копий, и какие файлы для этого понадобятся.
• Предварительный прогноз делают, посмотрев перечень резервных копий, состояние Audit и Change Data Capture: он показывает, насколько определённым получится вывод и где уже есть разрыв.
• Внесудебное исследование проводится по договору и отвечает на согласованные технические вопросы — например, что содержала таблица на выбранный момент восстановления.
• Судебная экспертиза проводится по назначению суда или органа расследования в установленном процессуальном порядке.
• Рецензирование проверяет готовое заключение: идентификацию backup sets, работу с журналом транзакций и обоснованность выбранной точки восстановления. Это не новое первичное исследование.

Если судебная экспертиза уже назначена, назначенный по делу эксперт не принимает от одной стороны напрямую дополнительные базы и не даёт ей частный прогноз по переданному объекту: новые материалы, вопросы и уточнение доступа идут через назначивший орган. Это не исключает обращения стороны к другому, не назначенному по делу специалисту — за консультацией или рецензией по законно полученным материалам. Информационное письмо может описывать компетенцию, необходимые материалы, ориентировочные стоимость и срок, но не подменяет исследование выводом по существу дела.

Примеры вопросов на экспертизу

При судебной экспертизе окончательный круг вопросов определяет суд, а в иных предусмотренных законом процедурах — орган или лицо, назначившие экспертизу. Вопросы о виновности, умысле, правовой квалификации события, нарушении договора и ответственности разрешает суд или иной уполномоченный орган. Эксперт отвечает на поставленные вопросы в пределах специальных знаний и представленных материалов; о неясности вопроса, выходе за пределы компетенции или недостаточности материалов он в установленном порядке сообщает суду, органу или лицу, назначившим экспертизу.

До назначения стороны могут использовать приведённые ниже формулировки как предложения о технических вопросах. Для SQL Server полезно указать экземпляр и базу данных, продукт, версию и редакцию, спорные таблицы, строки или наборы резервных копий, период и часовой пояс, а при необходимости — LSN. Если вывод зависит от приложения, Windows, кластера или хранилища, соответствующие объекты и компетенции указывают отдельно. Примеры:

1. Какие сведения содержатся в указанных таблицах и записях представленной базы Microsoft SQL Server?
2. Чем различаются перечисленные данные и объекты в двух представленных копиях или восстановленных состояниях базы?
3. Какие операции с указанными объектами отражены в представленных материалах журнала транзакций и log backup за заданный период?
4. Имеются ли технические признаки изменения или удаления перечисленных записей; какими источниками они подтверждаются?
5. Позволяют ли представленные полная, дифференциальная и журнальные копии реконструировать состояние указанных данных на заданный момент или LSN; каковы ограничения результата?
6. Какие признаки логического или физического повреждения установлены и какие технические причины подтверждаются error log, DBCC и сведениями подсистемы ввода-вывода?
7. Каков механизм формирования значения в указанном поле с учётом T-SQL, триггеров, процедур, заданий Agent и связанного приложения?
8. Какие технические причины зафиксированной деградации, взаимоблокировки или рассогласования реплик подтверждаются сохранёнными измерениями?
9. Соответствуют ли перечисленные объекты и данные правилам преобразования, карте соответствия и критериям приёмки миграции?

Например, стороны могут предложить исследовать операции, технические идентификаторы и временную последовательность, относящиеся к спорной записи; соответствие конкретных объектов пунктам технического задания; возможность восстановления определённых строк за указанный период по названной базовой копии и журналам. Логин или session ID сами по себе не устанавливают физическое лицо и его умысел; эти обстоятельства оценивает суд или иной уполномоченный орган вместе с другими доказательствами.

Границы и проверка выводов

Журнал транзакций SQL Server ведётся ради восстановления, а не ради дознания: он не хранит сведений о том, кто именно сидел за клавиатурой, и его формат производителем не документирован, поэтому средства чтения журнала дают результат, который приходится проверять другими источниками. Нельзя установить событие, которое не отражалось в сохранённых источниках, или назвать человека только по общей учётной записи приложения или по заданию SQL Server Agent, выполняемому под служебной записью. Отсутствие операции в повторно использованной области журнала, неполной цепочке log backup, выключенном Audit либо очищенном CDC не доказывает отсутствия действия. Нельзя также переносить поведение одной версии, edition или compatibility level на другую без проверки.

При проверке готового заключения по базам данных выясняют, идентифицированы ли объекты и backup sets, зафиксированы ли хэш-значения и время, названы ли версия SQL Server и инструменты, проверены ли recovery model, цепочка LSN, границы транзакций, audit specifications, временные зоны и альтернативные источники. Воспроизводимый вывод связывает каждый ответ с конкретными командами и наблюдаемыми результатами, а не только со снимками экрана или утверждением программы анализа журнала.

Стоимость и срок

Ориентировочная стоимость судебной экспертизы — от 100 000 ₽, срок — от 10 рабочих дней. Больше всего на трудоёмкость влияет состояние цепочки резервных копий: непрерывная цепочка журнальных копий позволяет восстановить состояние на нужный момент почти сразу, разорванная превращает работу в поиск обходных источников. Дальше идут объём и число баз, версия и редакция экземпляра, шифрование, группы доступности Always On, необходимость разворачивать совместимый стенд, число вопросов и режим доступа к системе. Точный расчёт возможен после просмотра перечня материалов: по нему видно, какие вопросы вообще проверяемы на сохранившихся источниках.

Чтобы начать, позвоните по телефону 8 (800) 333-24-09 или отправьте описание через форму. Укажите версию SQL Server, что произошло, нужный период, модель восстановления, какие файлы, backup, audit и event logs сохранились и назначена ли уже судебная экспертиза. Не отправляйте пароли, ключи и рабочую базу по обычной электронной почте до согласования безопасного способа передачи.