Мы рассмотрим крайне сложную и критическую ситуацию, когда основной файл базы данных MSSQL (.mdf) был случайно или преднамеренно удален, но при этом сохранился файл журнала транзакций (.ldf) и, возможно, имеется старая выгрузка базы 1С в формате .dt. Нам предстоит выяснить, существуют ли реальные способы восстановить недостающие данные за период между датой выгрузки .dt и моментом удаления файла .mdf, а также понять, почему многие очевидные на первый взгляд решения не работают.
Представим сценарий: клиент случайно удалил основной файл базы данных MSSQL (.mdf), который использовался для работы 1С. К счастью, служба MSSQL запускалась вручную, и на диске остался файл журнала транзакций (.ldf) размером около 44 ГБ, содержащий записи до начала января 2024 года. Единственный "рабочий" файл с данными, доступный на данный момент, — это выгрузка 1С в формате .dt, датированная 15 декабря 2023 года. Таким образом, имеется временной разрыв в 21 день (с 15 декабря по начало января), данные за который мы стремимся восстановить.
Первая интуитивная попытка, которую мы могли бы предпринять, — это создать новую базу данных в MSSQL из старой .dt выгрузки, а затем попытаться "подсунуть" ей сохраненный файл журнала транзакций. Однако, как показал опыт, такой подход не увенчался успехом: файл .ldf остался прежнего размера, а база данных содержала лишь старые данные до 15 декабря.
Чтобы понять, почему наша первая попытка оказалась безуспешной, а также почему большинство стандартных методов восстановления не применимы, давайте рассмотрим технические особенности работы MSSQL и 1С:
Невозможность "подсунуть" файл .ldf к новой базе из .dt:
Ключевой момент заключается в том, что каждая база данных MSSQL имеет уникальный внутренний идентификатор (Database ID или GUID), который неявно связывает файл данных (.mdf) и файл журнала транзакций (.ldf). Когда мы создаем новую базу данных из .dt выгрузки, SQL Server воспринимает ее как совершенно новую сущность, даже если мы дадим ей то же имя, что и у потерянной базы. У этой новой базы будет свой собственный, отличный от оригинального, внутренний идентификатор. Попытка присоединить или "подсунуть" файл журнала транзакций от старой базы данных к новой приведет к ошибке, поскольку SQL Server обнаружит несоответствие идентификаторов и откажется работать с несогласованными файлами.
Журнал транзакций содержит последовательность изменений (транзакций), которые относятся к очень конкретному состоянию базы данных. Эти изменения записываются с использованием Log Sequence Numbers (LSN), которые представляют собой своего рода временные метки транзакций. Каждая запись в журнале связана с определенным LSN и указывает на изменения в определенных блоках данных оригинального .mdf файла. Без соответствующего .mdf файла, который имеет тот же идентификатор и содержит данные в том состоянии, на которое ссылается журнал, невозможно корректно применить эти изменения.
Журнал транзакций (.ldf) без файла данных (.mdf) не является полной базой:
Мы должны четко понимать, что файл журнала транзакций сам по себе не является полной копией данных. Он содержит только последовательность изменений (INSERT, UPDATE, DELETE, создание объектов, изменение метаданных и т.д.), которые были применены к базе данных. Для того чтобы "накатить" эти изменения и получить актуальное состояние базы данных, всегда требуется полная или разностная резервная копия базы данных, к которой этот журнал относится. Без файла .mdf или его актуальной резервной копии невозможно просто "присоединить" .ldf и получить рабочую базу. Журнал транзакций ссылается на определенные точки в базе данных, и эти ссылки будут недействительны без соответствующего файла .mdf.
Стандартными средствами SQL Server невозможно просто "открыть" файл .ldf и извлечь из него данные, как из текстового файла или таблицы. Информация в нем хранится в бинарном формате, оптимизированном для последовательного применения транзакций.
Что такое LSN и почему он важен для восстановления:
Log Sequence Number (LSN) — это уникальный идентификатор для каждой записи в журнале транзакций. Это число постоянно увеличивается, и каждая транзакция получает свой LSN. Когда мы создаем полный бэкап базы данных, в нем записывается последний LSN на момент создания бэкапа. При восстановлении мы можем накатывать последующие журналы транзакций, начиная с LSN, записанного в бэкапе, и так далее по цепочке. Это позволяет SQL Server гарантировать последовательное и безошибочное применение всех изменений. Если у нас нет полного бэкапа (т.е. нет исходной точки с известным LSN), к которому можно было бы применить наш файл журнала, мы не сможем использовать журнал транзакций для восстановления.
В нашем случае, поскольку мы потеряли основной .mdf файл и не имеем актуального полного бэкапа, мы фактически потеряли начальную точку для применения журнала транзакций.
Восстановление удаленного файла .mdf с диска:
В операционной системе Windows существуют программы для восстановления удаленных файлов, такие как Hetman Partition Recovery, R-Studio, Wondershare Data Recovery, Recuva и другие. Эти инструменты сканируют диск в поисках удаленных файлов, которые еще не были перезаписаны. Однако в данной ситуации, когда клиент "бороздил" SSD-диск после удаления, шансы на успешное восстановление .mdf файла крайне минимальны. SSD-диски имеют особенности работы (например, TRIM-команды), которые могут быстро и безвозвратно удалить данные из ячеек памяти после команды удаления. Каждое обращение к диску после удаления увеличивает вероятность перезаписи секторов, где находился файл базы данных. Более того, файл .mdf может быть фрагментирован, что еще больше усложняет его восстановление.
Точки восстановления операционной системы Windows также не помогут, поскольку диск базы данных, скорее всего, не находился на системном диске, и они не предназначены для восстановления отдельных файлов баз данных.
Учитывая все вышесказанное, стандартными средствами MSSQL восстановить базу данных из одного файла .ldf без соответствующего .mdf или полного бэкапа невозможно. Однако существуют специализированные сторонние инструменты, которые могут помочь в очень ограниченных сценариях, но не гарантируют полного восстановления:
Такие утилиты, как ApexSQL Log (ранее известный как Redgate SQL Log Rescue) или DbForge Studio for SQL Server (имеет аналогичную функциональность), предназначены для чтения и анализа файла журнала транзакций. Их основное назначение — аудит изменений, откат конкретных транзакций или просмотр истории данных. Мы можем попробовать использовать их в нашей ситуации.
Как они работают: Эти инструменты способны "читать" бинарный файл .ldf и интерпретировать его содержимое. Они могут отображать выполненные операции (INSERT, UPDATE, DELETE), имена таблиц, пользователей, время транзакций и, в некоторых случаях, даже значения данных, которые были изменены.
Ограничения без файла .mdf: Несмотря на их возможности, эффективность этих инструментов без соответствующего файла .mdf или полной резервной копии сильно ограничена. Они могут показать нам записи журнала, но собрать из этого полноценную рабочую базу данных, восстановив ее состояние на определенный момент времени, практически невозможно без исходного контекста .mdf.
UPDATE и DELETE, эти инструменты часто нуждаются в наличии как файла .ldf, так и соответствующего файла .mdf (или его резервной копии). Это необходимо, чтобы понять контекст данных до и после изменений. Если .mdf отсутствует полностью, они могут показать только записи журнала, но не всегда смогут реконструировать состояние строк таблицы или получить "старые" значения для UPDATE или удаленные данные для DELETE.INSERT с полными данными, которые были вставлены. Но для UPDATE они могут показать только новые значения, а старые значения, возможно, будут недоступны без .mdf. Для DELETE они могут показать информацию об удаленных строках, но не сами данные, если они были полностью удалены из файла данных.Сценарий применения в нашей ситуации: Если нам удастся получить список транзакций за утерянный период (с 15 декабря по начало января) с помощью этих инструментов, то это может стать основой для ручного ввода данных. Например, мы можем увидеть все операции INSERT, которые были выполнены, и данные, которые были добавлены. Мы также можем увидеть новые значения для операций UPDATE. Это крайне трудоемкий процесс, но это может быть единственным способом восстановить хоть какую-то информацию, если .mdf безвозвратно утерян.
Подведем итог: если нам не удается восстановить оригинальный файл .mdf, а сторонние инструменты не могут собрать полноценную базу данных из "осиротевшего" файла .ldf, то единственный, хоть и крайне трудоемкий, способ получить данные за период между 15 декабря 2023 года и началом января 2024 года — это ручной ввод данных.
Мы должны будем:
INSERT, UPDATE и DELETE, произошедшие за этот период..dt выгрузки.Это может занять очень много времени и усилий, но в условиях полного отсутствия бэкапов и файла .mdf, это зачастую единственный выход.
Эта ситуация является ярким напоминанием о жизненной необходимости регулярного резервного копирования данных. Как гласит известная поговорка среди IT-специалистов: "Все программисты делятся на 2 категории: те, кто делает бэкапы, и те, кто... будет их делать".
Для предотвращения подобных катастроф в будущем мы настоятельно рекомендуем:
.dt: В дополнение к бэкапам MSSQL, регулярные выгрузки 1С могут служить дополнительной страховкой.Только комплексный подход к резервному копированию может защитить от безвозвратной потери данных.