Restore Accounting падает: LSN, MOVE путей и REPLACE только после копии

Короткий ответ

Restore Accounting на SQL01 падает не «потому что 1С», а из‑за цепочки LSN, чужого backup set, путей файлов без WITH MOVE, нехватки места или REPLACE в неправильный момент. Читайте HEADERONLY/FILELISTONLY, восстанавливайте full → diff → log по порядку, на тестовое имя, пути на этот хост. WITH REPLACE поверх боевой базы — только после копии текущих файлов и понимания, что прод уничтожите.

Симптомы и как отличить

Типичная картина:

• 3154: backup от другой базы;
• 3156: файл не туда / нет пути;
• 4305/3116: log не от этой цепочки;
• «database in use» — сеансы 1С.

Отличия:

Возможные причины

1. Взяли не тот .bak (тест вместо прод).
2. Diff/log от другого full (после COPY_ONLY путаница или новый full).
3. Пути в backup D:\... на новом сервере нет.
4. База в use: SRV-1C держит соединения.
5. Нет места.
6. Попытка log restore на SIMPLE (после смены model).
7. Encrypted backup без сертификата.

Диагностика

RESTORE HEADERONLY FROM DISK = N'E:\SQLBackup\Accounting_full.bak';
RESTORE FILELISTONLY FROM DISK = N'E:\SQLBackup\Accounting_full.bak';

Сверьте DatabaseName, BackupType (1 full, 5 log, 2 diff), FirstLSN/LastLSN/CheckpointLSN/DatabaseBackupLSN.

Цепочка log:

SELECT bs.backup_start_date, bs.type, bs.first_lsn, bs.last_lsn, bs.database_backup_lsn,
       bf.physical_device_name
FROM msdb.dbo.backupset bs
JOIN msdb.dbo.backupmediafamily bf ON bs.media_set_id = bf.media_set_id
WHERE bs.database_name = N'Accounting'
ORDER BY bs.backup_start_date;

Сеансы:

SELECT session_id, login_name, host_name, program_name
FROM sys.dm_exec_sessions
WHERE database_id = DB_ID(N'Accounting');

Решение

Сценарий A. Тестовый restore на другое имя

Сеансы 1С не трогаете. MOVE на свободные пути:

RESTORE DATABASE [Accounting_restore]
FROM DISK = N'E:\SQLBackup\Accounting_full.bak'
WITH NORECOVERY, STATS = 10,
MOVE N'Accounting' TO N'D:\SQL\Data\Accounting_restore.mdf',
MOVE N'Accounting_log' TO N'L:\SQL\Log\Accounting_restore_log.ldf';
-- затем DIFF если есть, WITH NORECOVERY
-- затем LOG по порядку, последний WITH RECOVERY

Логические имена файлов — из FILELISTONLY, не угадывать.

Сценарий B. 3156 / пути

Создайте каталоги, MOVE каждый logical name. Не REPLACE, если цель — новое имя.

Сценарий C. LSN mismatch

Вернитесь к full, на который ссылается database_backup_lsn лога. Нельзя накатить «случайный» trn. Если full новый, старые log не подойдут.

Сценарий D. Прод restore (авария)

1. Стоп сеансов 1С к Accounting.
2. Копия текущих файлов, если они ещё читаются.
3. Restore цепочки.
4. Не оставляйте NORECOVERY для пользователей.

ALTER DATABASE [Accounting] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
-- RESTORE ... WITH REPLACE, MOVE при смене путей

REPLACE нужен, если имя совпадает и файлы существуют. Без понимания затрёте прод.

Сценарий E. База в use

Завершите сеансы кластера, не KILL всего SQL. Либо SINGLE_USER WITH ROLLBACK осознанно (обрыв транзакций 1С).

Контур переноса и аварии: MOVE, логины, 1С

После успешного restore Accounting на новом томе 1С может получить 18456: SID login не совпал. Это не ошибка restore, чините права. Не давайте sysadmin, чтобы «срочно открылось».

FILELISTONLY показывает logical names, которые 1С не обязана называть Accounting. Часто 1cv8c_data / 1cv8c_log или имя при создании базы. MOVE без точного logical name падает 3156. Не угадывайте.

NORECOVERY оставляет базу недоступной для 1С — это нормально, пока накатываете log. Не пускайте пользователей и не «проверьте 1С на промежуточном шаге». Откроют — сорвёте цепочку. Последний файл — WITH RECOVERY или отдельный RESTORE DATABASE Accounting WITH RECOVERY.

Если restore на тот же SQL01 поверх прод, кластер всё ещё держит пул соединений: database in use. Завершите сеансы 1С, подождите, затем SINGLE_USER. Не KILL spid 1–50 системных.

VERIFYONLY с CHECKSUM ловит битый bak раньше, чем вы уничтожите прод REPLACE. Делайте VERIFYONLY на копии файла, не на единственном bak, который одновременно пишет job.

Шифрование backup сертификатом: сертификат должен быть на целевом SQL01. Без него ошибка не про MOVE. Экспорт сертификата с ключом — в сейф, не в тот же каталог bak без ACL.

Как проверить, что проблема устранена

SELECT name, state_desc FROM sys.databases WHERE name IN (N'Accounting', N'Accounting_restore');

ONLINE. 1С на тестовой строке к Accounting_restore (отдельная инфобаза) открывается. CHECKDB без ошибок. Для прод-восстановления — сверка документов.

Если не помогло

• Нет полного набора trn — RPO дырявый, чините процесс backup.
• Шифрование — сертификат/ключ на этот экземпляр.
• Страницы 824 после restore — сторадж, не «ещё раз тот же bak».

Профилактика

• Регулярный restore-тест на другое имя.
• Хранить набор full+diff+log, не один bak «на диске C».
• Документ logical names и путей SQL01.
• Не делать лишний full руками в обед, ломая diff, без нужды.

Перед REPLACE на проде соберите пакет в тикете: HEADERONLY скрин, FILELISTONLY, список trn по LSN, новые пути MOVE, кто подтвердил уничтожение текущих файлов Accounting. Если кто-то уже скопировал MDF «на всякий случай» на тот же том без места — copy будет обрезан, это не копия. После restore 1С проверьте не только вход, но проведение контрольного документа и что инфобаза в кластере смотрит на этот экземпляр SQL01, а не на старый IP. Логины, SID, Job Agent backup — часть restore, не «потом». Если поднимаете копию рядом с продом, запретите ей сеть обмена и банк-клиент, иначе тестовые платежки уедут в мир.

FAQ

WITH RECOVERY на полном, потом log.

Нельзя. Log только на NORECOVERY (или STANDBY). Порядок: full NORECOVERY → … → последний RECOVERY.

STOPAT для 1С.

Да, если Full + непрерывные log. Укажите время до сбоя. Проверьте, что регламент 1С не оставил дыру в log backup.

Restore на SQL 2022 с bak с 2019.

Обычно вверх совместимо. Обратно 2022→2019 — нет. Смотрите версию в HEADERONLY.

Зачем MOVE всегда на тесте?

Чтобы не перезаписать боевые файлы Accounting.mdf случайно.

1С надо отцеплять перед restore?

Сеансы — да. Инфобазу в кластере можно оставить, но к СУБД никто не должен быть подключён. После restore проверьте логин SQL.