Восстановление резервной копии — это критически важная операция, которая требует внимания к деталям. Часто возникает задача развернуть копию рабочей базы для тестирования или разработки ("песочница"). Если сделать это неправильно, можно случайно затереть рабочие данные или нарушить работу внешних обменов. Рассмотрим подробно, как организовать этот процесс максимально безопасно, объединив опыт администраторов баз данных и специфику платформы 1С.
Прежде чем запускать процедуру восстановления, проанализируем, что именно находится внутри нашего файла бэкапа. Нам необходимо знать логические имена файлов, чтобы случайно не перезаписать файлы рабочей базы.
Выполним команду для просмотра содержимого бэкапа:
RESTORE FILELISTONLY
FROM DISK = 'D:\Backups\ProductionDB.bak';
Это позволит нам увидеть логические имена (столбец LogicalName). Запомним их, так как они понадобятся нам для команды перемещения файлов.
Также, если мы восстанавливаем базу поверх существующей "сломанной" (а не создаем новую копию), обязательно создадим резервную копию "хвоста лога" (Tail-Log Backup). Это позволит сохранить транзакции, прошедшие с момента последнего полного бэкапа до момента сбоя.
Самая распространенная ошибка — восстановление тестовой базы по путям рабочей базы. Чтобы этого избежать, мы должны явно указать SQL Server, куда положить файлы новой базы. Рассмотрим скрипт, который создает копию базы данных из бэкапа.
Используем конструкцию WITH MOVE для переопределения физических путей:
-- Восстанавливаем копию под новым именем MyDB_Copy
RESTORE DATABASE MyDB_Copy
FROM DISK = 'C:\Backups\MyDB.bak'
WITH REPLACE, -- Разрешаем перезапись, если база с таким именем уже есть
RECOVERY, -- Переводим базу в рабочее состояние после восстановления
-- Перенаправляем файл данных
MOVE 'MyDB' TO 'C:\Data\MyDB_Copy.mdf',
-- Перенаправляем файл журнала транзакций
MOVE 'MyDB_log' TO 'C:\Data\MyDB_Copy.ldf';
Обратите внимание на опцию REPLACE. Она необходима, если база данных с именем MyDB_Copy уже существует. Однако будьте предельно внимательны: убедитесь, что вы не перезаписываете рабочую базу (Production). Проверяйте пути дважды.
Если вы используете графический интерфейс Management Studio, перейдите на вкладку "Files" в окне восстановления и вручную измените пути в колонке "Restore As".
Часто SQL Server не дает восстановить базу, сообщая, что она используется (ошибка "Database is in use"). Это происходит, если к целевой базе (той, в которую мы восстанавливаем) подключены пользователи или фоновые процессы.
Чтобы решить эту проблему, переведем базу в монопольный режим SINGLE_USER с немедленным разрывом соединений:
USE master;
ALTER DATABASE MyDB_Copy
SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
Важно: Не полагайтесь на наличие активных соединений как на защиту от перезаписи рабочей базы. Если вы по ошибке выполните эту команду для рабочей базы, SQL Server принудительно отключит всех пользователей и начнет процесс восстановления, уничтожая актуальные данные. Всегда проверяйте имя базы в команде.
После того как база восстановлена на уровне SQL, работа еще не закончена. Для систем на базе 1С:Предприятие существуют специфические риски при запуске копии.
Сразу после восстановления в копии базы могут быть активны РегламентныеЗадания. Это опасно тем, что тестовая база может начать отправлять письма реальным клиентам, выгружать данные в банк или обмениваться информацией с сайтом. Необходимо заблокировать их выполнение на уровне кластера серверов 1С или с помощью SQL-скрипта очистить расписание перед первым запуском.
При первом входе в восстановленную базу через конфигуратор или предприятие, платформа задаст вопрос: "Информационная база была перемещена или скопирована?".
Выберем ответ "Это копия". В этом случае 1С изменит внутренние идентификаторы базы, что автоматически заблокирует работу многих механизмов обмена с внешними системами. Это встроенный защитный механизм.
Если в вашей системе файлы (картинки, сканы договоров) хранятся не внутри базы, а в томах на диске, проанализируем пути к ним. В тестовой базе следует очистить пути к томам. Иначе, если пользователь в тестовой базе удалит "ненужный" файл, он удалится с физического диска, и рабочая база также потеряет доступ к этому файлу.
После восстановления полезно убедиться, что данные не повреждены. Даже если восстановление прошло успешно, в базе могут быть логические ошибки.
Запустим проверку целостности:
DBCC CHECKDB ('MyDB_Copy');
Также часто возникает проблема "осиротевших пользователей" (orphaned users), когда логин на SQL сервере не связан с пользователем внутри базы данных. Для исправления ситуации используем процедуру sp_change_users_login или команду ALTER USER, чтобы восстановить связь между логином сервера и пользователем базы.
Соблюдение этого алгоритма позволит нам создать безопасную среду для тестирования, исключив риски потери или искажения данных в основной рабочей системе.