При работе с MS SQL Server администраторы 1С часто сталкиваются с задачей создания копии рабочей базы для целей тестирования, разработки или анализа данных на определенную дату. Типичная проблема возникает при использовании графического интерфейса SQL Server Management Studio (SSMS): при попытке выбрать базу-источник в мастере восстановления нужная база просто отсутствует в выпадающем списке, либо там отображаются объекты с других серверов. Разберем подробно, почему это происходит и как правильно выполнить восстановление, не затерев при этом рабочие данные.
Для начала проанализируем ситуацию с точки зрения механизмов самого SQL Server. Окно восстановления в SSMS формирует список баз данных в поле «Source» (Источник) не на основе тех баз, которые физически прикреплены к серверу в данный момент, а на основе системной таблицы msdb.dbo.backupset. Рассмотрим основные причины «неправильного» поведения списка:
BACKUP DATABASE), она не появится в списке источников. Система «не знает», из чего восстанавливаться.msdb с другого сервера. Вместе с ней «переехала» и история бэкапов.msdb станут недействительными.Рекомендация: Вместо использования варианта «Database» в качестве источника, профессиональнее и надежнее использовать вариант «Device» (Устройство) и указывать прямой путь к файлу .bak.
Разберем вопрос о возможности возврата состояния базы «на вчерашний вечер», если последний бэкап был сделан сегодня утром. Здесь важно понимать теорию резервного копирования:
Бэкап — это мгновенный снимок. Если у вас есть полная копия (Full Backup) на 8:00 утра понедельника, вы не можете «откатить» ее к вечеру воскресенья, используя только этот файл. Для восстановления на произвольный момент времени должны соблюдаться следующие условия:
Full Backup + Differential Backups (опционально) + Transaction Log Backups (обязательно).Для визуального выбора времени в SSMS предусмотрена кнопка Timeline. Она позволяет буквально передвинуть ползунок на нужную секунду, но только если накоплены логи транзакций за этот период.
Рассмотрим ситуацию, когда нам нужно восстановить базу Work_Base в новую базу Test_Copy на том же сервере. Это критический момент: по умолчанию SQL Server попытается восстановить файлы в те же папки и с теми же именами, что у оригинала. Если нажать «ОК» без дополнительных настроек, можно повредить рабочую базу.
Проанализируем шаги во вкладке Files (Файлы) мастера восстановления:
Restore As..mdf и .ldf отличаются от имен файлов оригинальной базы. Например, вместо Work_Base.mdf укажите Test_Copy.mdf.Во вкладке Options обязательно обратите внимание на следующие параметры:
Рассмотрим пример скрипта, который позволяет выполнить восстановление максимально прозрачно. Использование RESTORE DATABASE с параметром WITH MOVE — это «золотой стандарт» администратора.
-- Пример восстановления базы из файла с переименованием файлов данных и лога
RESTORE DATABASE [Test_Copy]
FROM DISK = N'D:\Backups\Work_Base_Full.bak'
WITH
MOVE N'Work_Base_Data_Logical_Name' TO N'E:\SQL_Data\Test_Copy.mdf',
MOVE N'Work_Base_Log_Logical_Name' TO N'E:\SQL_Logs\Test_Copy_log.ldf',
REPLACE,
RECOVERY,
STATS = 10;
Разберем параметры этого скрипта подробнее:
REPLACE — указывает SQL Server, что нужно перезаписать целевую базу, если она уже существует.MOVE — сопоставляет логическое имя файла внутри бэкапа с новым физическим путем на диске. Это ключевой момент для предотвращения конфликта с рабочей базой.RECOVERY — переводит базу в оперативный режим (Online) после завершения восстановления.После того как база успешно восстановлена на SQL-уровне, работа администратора 1С не заканчивается. Проанализируем необходимые действия в самой системе:
v8users через SQL-запрос, чтобы обеспечить безопасность данных.Таким образом, мы выяснили, что отсутствие базы в списке источников — это лишь особенность ведения истории в msdb, а не критическая ошибка. Используя восстановление через файлы (Device) или T-SQL скрипты, вы получаете полный контроль над процессом и гарантируете сохранность своих данных.