Как исправить ошибку «Невозможно восстановить журнал или разностную резервную копию» в MS SQL Server

Системный администратор IT и автоматизация бизнеса
← На главную

При обслуживании баз данных 1С на платформе MS SQL Server администраторы часто сталкиваются с ситуацией, когда стандартная процедура восстановления из полного и дифференциального (разностного) бэкапа завершается ошибкой. Сообщение «Невозможно восстановить журнал или разностную резервную копию, так как нет файлов, готовых к накату (Microsoft.SqlServer.SmoExtended)» или Ошибка 3136 указывает на критическое нарушение логики резервного копирования. В рамках этой статьи мы подробно разберем, почему это происходит и как правильно организовать процесс восстановления.

Анализируем причину ошибки: нарушение цепочки LSN

Для начала проанализируем ситуацию. SQL Server использует так называемые LSN (Log Sequence Number) — регистрационные номера последовательности транзакций. Каждый дифференциальный бэкап «привязан» к конкретной полной резервной копии через эти номера. Разберем по шагам, что происходит в момент возникновения ошибки:

  1. Вы создаете полную резервную копию (Full Backup) в воскресенье.
  2. Вы планируете дифференциальные копии (Differential) на каждый день недели.
  3. Если в промежутке между ними был сделан еще один полный бэкап (например, вручную или другим скриптом), то цепочка LSN «переключается» на этот новый файл.

В итоге, когда мы пытаемся накатить дифференциальный бэкап понедельника на полный бэкап воскресенья, SQL Server видит, что между ними была другая база (другая опорная точка), и выдает ошибку: «Разностная резервная копия не была восстановлена в более раннем состоянии».

Диагностика с помощью RESTORE HEADERONLY

Выясним причину разрыва цепочки с помощью технических средств. Для этого нам понадобится команда RESTORE HEADERONLY. Рассмотрим пример кода, который поможет нам увидеть внутренние параметры файлов бэкапа:


RESTORE HEADERONLY FROM DISK = 'E:\Backups\Full_Base.bak';
RESTORE HEADERONLY FROM DISK = 'E:\Backups\Diff_Base.bak';

Проанализируем вывод команды, обратив внимание на следующие поля:

Если эти цифры различаются — цепочка разорвана. Это значит, что между вашим полным и разностным архивами «вклинился» еще один полный бэкап.

Главный виновник: Внеплановые бэкапы и стороннее ПО

Посмотрим на типичные сценарии, которые приводят к этой ошибке:

  1. Дублирующие планы обслуживания: Как в обсуждении на форуме, вы можете использовать скрипты для автоматизации архивации, делая бэкап на один диск по расписанию, и еще один бэкап — другим заданием на другой носитель.
  2. Системы резервного копирования на уровне виртуальных машин: Программы типа Veeam или Commvault при создании снимка (snapshot) всей виртуальной машины могут запрашивать у SQL Server создание полного бэкапа базы для обеспечения целостности.
  3. Ручные действия: Администратор решил «на всякий случай» сделать полный бэкап перед важным обновлением 1С, не используя специальные флаги.

Решение проблемы: использование флага COPY_ONLY

Рассмотрим, как правильно делать дополнительные или внеплановые бэкапы, чтобы не ломать цепочку восстановления. Для этого в MS SQL Server существует параметр COPY_ONLY (Только копирование).

Когда вы делаете резервную копию с этим флагом, SQL Server сохраняет текущее состояние базы, но не меняет LSN-метку для будущих дифференциальных бэкапов. Они по-прежнему будут «считать» своим родителем предыдущий стандартный полный бэкап.

Пример правильной команды для внепланового полного бэкапа:


BACKUP DATABASE [ВашаБаза] 
TO DISK = 'E:\Backup\Full_Manual_Copy.bak' 
WITH COPY_ONLY, STATS = 10;

Если вы используете План обслуживания (Maintenance Plan), изучите инструкцию по настройке регламентных операций и обязательно найдите в настройках задачи резервного копирования галочку «Копировать только резервную копию» (Copy-only backup).

Правильный алгоритм восстановления из файлов

Если у вас есть правильная цепочка файлов, разберем по шагам, как выполнить восстановление через T-SQL (это надежнее, чем через графический интерфейс SSMS):

  1. Восстановление полной копии в режиме NORECOVERY: Этот режим оставляет базу в состоянии «Restoring», что позволяет накатывать следующие файлы. 
    
RESTORE DATABASE [ИмяБазы] 
FROM DISK = 'E:\Backups\Full_Base.bak' 
WITH NORECOVERY, REPLACE;
  2. Восстановление дифференциальной копии в режиме RECOVERY: Если это последний файл в вашей цепочке, используйте WITH RECOVERY, чтобы база стала доступной для пользователей. 
    
RESTORE DATABASE [ИмяБазы] 
FROM DISK = 'E:\Backups\Diff_Base.bak' 
WITH RECOVERY;

Дополнительные рекомендации

Рассмотрим еще несколько важных нюансов:

Расширения файлов: Не путайте расширения .bak, .dif или .trn. Для SQL Server это всего лишь текстовые метки. Вы можете назвать разностный бэкап как угодно, его тип определяется только внутренним заголовком. Однако для удобства администрирования лучше придерживаться стандартов.

Модель восстановления: Если у вас Simple (Простая) модель, вы ограничены только схемой «Полный + Дифференциальный». Если модель Full (Полная), вам также придется следить за цепочкой логов транзакций (Transaction Logs). Принцип LSN там работает аналогично — каждый следующий лог должен иметь FirstLSN, равный LastLSN предыдущего.

Проверка целостности: Рекомендуем периодически проверять возможность восстановления без фактического наката данных командой RESTORE VERIFYONLY. Это позволит заранее узнать, не повреждена ли цепочка LSN в ваших текущих планах обслуживания.

Таким образом, мы выяснили, что ключ к стабильному восстановлению баз данных 1С — это строгое соблюдение последовательности LSN и использование режима COPY_ONLY для любых бэкапов, которые не входят в основной цикл обслуживания.

← На главную