Ситуация, когда рабочая база данных ошибочно перезаписывается архивной копией (файлом .dt) или пустой базой, является одним из самых страшных кошмаров системного администратора и программиста 1С. Особенно критично это становится, когда выясняется, что штатные средства резервного копирования (SQL maintenance plans или сторонние утилиты) были настроены некорректно и актуальных файлов .bak просто не существует. Рассмотрим подробно, какие шаги можно предпринять в такой, казалось бы, безвыходной ситуации, используя возможности SQL Server, операционной системы и механизмов платформы 1С.
Первое правило в случае потери данных на физическом носителе или логической ошибки — прекратить любую запись на диск. Если вы работаете на физическом сервере (не виртуалка), каждое действие пользователей, каждая запись логов операционной системы уменьшает шансы на восстановление данных на низком уровне. Если есть возможность, переведите базу в режим Offline или остановите службу SQL Server, пока мы анализируем ситуацию.
Разберем, что именно происходит при загрузке .dt файла. Платформа 1С очищает таблицы базы данных и заполняет их данными из файла. Для SQL Server это выглядит как массовое удаление и вставка данных. Если модель восстановления (Recovery Model) базы данных была установлена в значение Full (Полная), у нас появляется крошечный шанс, так как транзакции могли сохраниться в журнале транзакций (файл .ldf), если он не был перезаписан или урезан (truncated).
Проверим историю резервного копирования, чтобы убедиться, что мы действительно ничего не упустили. Возможно, какой-то автоматический процесс все же делал бэкапы. Выполним следующий запрос в SQL Server Management Studio (SSMS):
sel ect
database_name,
type,
max(backup_start_date) as LastBackupDate
from
msdb..backupset
where
database_name = 'ИМЯ_ВАШЕЙ_БД'
group by
database_name, type
order by
3 desc
Разберем, что нам покажет этот запрос. Поле type означает тип бэкапа:
Если в результатах вы видите свежие даты, найдите путь к этим файлам в таблице msdb..backupmediafamily. Если же результат пустой или даты очень старые — переходим к следующим вариантам.
Так как мы работаем на физическом сервере под управлением Windows Server, у нас есть надежда на службу VSS (Volume Shadow Copy Service). Часто системные администраторы включают создание теневых копий тома по расписанию (например, два раза в день), либо они могут создаваться автоматически при установке обновлений Windows или работе некоторых программ архивации.
Проанализируем наличие теневых копий:
.mdf и .ldf).Если вам повезло, вы увидите список папок с датами. Вы можете открыть такую папку, найти файлы базы данных SQL и скопировать их в безопасное место. После этого их можно присоединить к серверу через команду Attach.
Важно: Не пытайтесь восстановить их "поверх" текущих файлов. Скопируйте их в отдельную папку, переименуйте и подключите как новую базу для анализа.
Если модель восстановления была Full, но бэкапы не делались, журнал транзакций .ldf мог вырасти до огромных размеров, храня в себе историю изменений за долгое время. При загрузке .dt происходит массовое изменение данных. Однако, старые данные не всегда затираются мгновенно.
Рассмотрим использование сторонних утилит для чтения логов SQL (Log Readers). Существуют инструменты (например, ApexSQL Log или аналоги), которые позволяют подключиться к живому файлу .ldf (или его копии) и попробовать прочитать транзакции.
Что мы ищем:
DELETE или TRUNCATE, которые выполнила 1С при загрузке dt.Если утилита сможет прочитать лог, она может сгенерировать скрипт UNDO (отмены операций), который теоретически вернет удаленные строки. Это сложный и рискованный процесс, но в безвыходной ситуации его стоит попробовать на копии файлов базы.
Поскольку сервер физический, старые данные в файле .mdf (сама база) могли быть помечены как удаленные, но физически остаться на магнитных пластинах жесткого диска или в ячейках SSD до момента перезаписи новыми данными.
Если база данных была большой (например, 50 ГБ), а вы загрузили поверх нее пустой или старый .dt размером в 1 ГБ, то большая часть старого файла .mdf могла остаться нетронутой на физическом уровне, хотя логически файловая система видит новый файл.
Для этого метода необходимо:
Некоторые утилиты умеют искать "сигнатуры" страниц данных SQL Server (SQL Data Pages) в нераспределенном пространстве диска. Если удастся найти старые страницы, специализированные фирмы могут собрать из них "фрагментированную" базу. Это дорогостоящая услуга, но если данные критичны, это вариант.
Если техническое восстановление базы невозможно, переходим к логическому восстановлению. В экосистеме 1С редко бывает так, что база работает изолированно. Чаще всего настроены обмены данными.
Проанализируем ситуацию с 1С:Зарплата и Управление Персоналом (ЗУП). Обычно она обменивается данными с 1С:Бухгалтерия Предприятия (БП).
Что можно восстановить из БП:
Для восстановления можно использовать стандартную обработку "Выгрузка и загрузка данных XML" или настроить обратный обмен (с осторожностью, чтобы не затереть данные в БП). Также стоит поднять архивы сданной отчетности (xml файлы), которые могли храниться в папках обмена или в системах электронной отчетности (1С-Отчетность, СБИС, Контур). Из XML-файлов отчетности можно частично восстановить базу для расчета среднего заработка.
В современных конфигурациях журнал регистрации (ЖР) хранится в отдельной папке srvinfo в формате .lgd (SQLite) или .lgp (текстовый). При перезаписи базы через загрузку .dt, журнал регистрации не очищается автоматически, если он не был внутри dt (а он там не хранится).
Посмотрим, что это нам дает:
Ситуация критическая, но не всегда безнадежная. Действовать нужно в таком порядке:
.ldf..mdf файлов или SQL-страниц.И, конечно, этот случай должен стать поводом немедленно настроить и, что важнее, протестировать систему автоматического резервного копирования с отправкой уведомлений об ошибках и успешных операциях на почту администратора.