Ситуация, когда после успешного восстановления резервной копии администратор обнаруживает в базе данные многолетней давности вместо актуальных документов, кажется невозможной. Однако в среде 1С:Предприятие + MS SQL Server такие казусы случаются. Чаще всего это связано не с ошибкой самой СУБД, а с человеческим фактором или путаницей в настройках кластера серверов 1С. В этой статье мы подробно разберем, как убедиться в правильности ваших действий, найти реальную базу на сервере и восстановить работоспособность системы.
Рассмотрим стандартную ситуацию: база «Бухгалтерия предприятия 3.0» работает в клиент-серверном режиме. Настроен план обслуживания, включающий еженедельные полные бэкапы, ежедневные разностные и ежечасные бэкапы лога транзакций. Вы выполняете восстановление на определенный момент времени (point-in-time recovery), процесс завершается без ошибок, но при входе в 1С вы видите документы, остановившиеся, например, на 2020 году.
Проанализируем основные причины такого поведения:
Buh_Prod, Buh_Work, Buh_Copy). Вы можете архивировать одну базу, думая, что она рабочая, в то время как пользователи давно работают в другой.COPY_ONLY, последующие разностные копии привязались к новому файлу, а ваш автоматизированный план обслуживания продолжает использовать старую базу.Если у вас нет пароля администратора кластера 1С, и вы не можете зайти в консоль администрирования (MMC), чтобы посмотреть свойства информационной базы, воспользуемся «черным ходом». Вся информация о связях баз 1С и SQL хранится в текстовых файлах конфигурации кластера.
Разберем, как найти нужные данные:
C:\Program Files\1cv8\srvinfo. Точный путь можно подсмотреть в свойствах службы 1С (параметр -d).reg_1541) и откроем файл 1CV8Clst.lst обычным текстовым редактором.Проанализируем содержимое файла. Нам нужна строка, описывающая вашу информационную базу. Она выглядит примерно так:
{e595cb83-41d1-4838-87f6-364fe10a8943,"ZP_Production","","MSSQLServer","SQL-SRV-01","Buh_Base_Real","sa", ...}
В этой строке нас интересуют два значения:
"ZP_Production" — это имя базы, как его видят пользователи в списке выбора 1С."Buh_Base_Real" — это реальное имя базы на сервере MS SQL Server.Важный момент: если вы обнаружили, что в 1С база называется «Бухгалтерия», а в файле указано имя SQL-базы Buh_2020_Archive, значит, вы все это время делали бэкапы архивной копии. Выясним это до того, как предпринимать дальнейшие действия.
Чтобы окончательно убедиться, какая база и когда архивировалась, обратимся к системным таблицам базы msdb. Выполним следующий запрос в SQL Server Management Studio (SSMS):
SELECT
s.database_name,
s.backup_finish_date,
s.type,
m.physical_device_name
FROM msdb.dbo.backupset s
JOIN msdb.dbo.backupmediafamily m ON s.media_set_id = m.media_set_id
WHERE s.database_name = 'Ваше_Имя_Базы_SQL'
ORDER BY s.backup_finish_date DESC;
Посмотрим на результат. Если дата последнего бэкапа актуальна, но физический путь (physical_device_name) ведет к странным файлам или на другой диск, это повод задуматься. Тип 'D' означает полный бэкап, 'I' — разностный, 'L' — журнал транзакций.
Если база восстановилась, но вы сомневаетесь в актуальности данных, посмотрим на них «глазами SQL». В 1С даты хранятся с небольшим секретом — смещением на 2000 лет. Проверим дату последнего документа реализации (например). Сначала выясним имя таблицы для документов РеализацияТоваровУслуг (оно может отличаться в разных версиях метаданных, например _Document150).
Выполним запрос для поиска максимальной даты:
SELECT MAX(_Date_Time) FROM _Document150;
Если запрос вернул дату вида 4024-05-20, значит, в базе есть документы за май 2024 года (вычитаем 2000 лет). Если же максимальная дата 4020-12-31, то в этой базе данных за последние годы действительно нет. Это подтверждает, что либо бэкап был сделан не с той базы, либо цепочка восстановления была нарушена.
Для полноценного управления и проверки настроек нам может понадобиться доступ в консоль администрирования. Если пароль утерян, выполним процедуру сброса:
srvinfo\reg_1541.1cv8users.lst. В нем хранится список администраторов кластера.После этого вход в консоль администрирования для этого кластера станет свободным. Теперь мы можем открыть свойства информационной базы и точно увидеть параметры подключения к SQL: сервер и имя базы данных.
Если вы используете модель восстановления Full, убедитесь, что при восстановлении на «произвольный момент времени» вы соблюдаете последовательность:
NORECOVERY).NORECOVERY).RECOVERY).Важно: Если вы выбираете время в графическом интерфейсе SSMS, убедитесь, что часовой пояс сервера совпадает с вашим представлением о времени. Ошибка в 3-4 часа может привести к тому, что вы восстановите базу на момент «до начала рабочего дня», когда транзакции еще не были совершены.
Проанализировав ситуацию, мы понимаем, что магии не существует. Если в восстановленной базе нет документов после 2020 года, значит:
Для предотвращения таких ситуаций в будущем рекомендуем всегда проверять 1CV8Clst.lst при настройке бэкапов и использовать в именах баз SQL четкие префиксы (PROD_, TEST_, ARCH_).