← На главную

При работе с базами данных 1С на платформе MS SQL Server одной из стандартных задач является восстановление из резервных копий. Часто используется схема, когда раз в неделю создается полный бэкап, а в остальные дни — разностные (дифференциальные). Однако при попытке восстановить такой бэкап можно столкнуться с ошибкой: "Неправильное состояние файла не позволяет применить к нему данную разностную резервную копию". Давайте подробно разберем, почему она возникает и как решить эту проблему.

Классический сценарий, приводящий к ошибке, выглядит так:

1. Выбираем для восстановления последний полный бэкап и восстанавливаем его с опцией WITH NORECOVERY. База данных успешно переходит в состояние "Восстановление" (Restoring).
2. Следом пытаемся применить разностный бэкап с опцией WITH RECOVERY, чтобы завершить процесс.
3. В этот момент MS SQL Server выдает указанную выше ошибку, и восстановление прерывается.

Проанализируем основные причины этой проблемы и рассмотрим пошаговые решения.

Основная причина: нарушение цепочки резервных копий

Чтобы понять суть проблемы, нужно вспомнить, как работают разностные бэкапы. Разностная резервная копия содержит все изменения, произошедшие в базе данных с момента создания последней полной резервной копии. Именно на эту полную копию она "опирается". Совокупность полной копии и последующих разностных копий (а также журналов транзакций) называется цепочкой резервного копирования.

Ошибка "Неправильное состояние файла" возникает, когда эта цепочка нарушена. Это означает, что разностный бэкап, который мы пытаемся применить, был создан на основе другой полной копии, а не той, которую мы только что восстановили.

Самый частый сценарий нарушения цепочки: между созданием "нашей" плановой полной копии (например, в воскресенье) и "нашей" разностной копии (например, в среду) была создана еще одна полная резервная копия. После этого все последующие разностные бэкапы стали основываться уже на этой новой, промежуточной полной копии. Попытка применить их к старой воскресной копии предсказуемо завершается ошибкой.

Диагностика: ищем источник "лишнего" бэкапа

Кто или что могло создать этот промежуточный полный бэкап?

1. Другой администратор или ручные действия. Кто-то мог вручную запустить создание полного бэкапа для своих нужд и не сообщить об этом.
2. Другой план обслуживания MS SQL Server. Возможно, на сервере настроено несколько пересекающихся планов резервного копирования.
3. Стороннее программное обеспечение. Это наиболее частая причина в современных инфраструктурах. Системы резервного копирования виртуальных машин (например, Veeam) или другое ПО для централизованного бэкапа могут создавать свои копии баз данных.

Как показала практика, именно стороннее ПО чаще всего становится "виновником" проблемы. Давайте рассмотрим решение на конкретном примере с системой Veeam.

Решение 1: Настройка стороннего ПО для использования "COPY_ONLY" бэкапов

Системы вроде Veeam для создания консистентных бэкапов приложений на виртуальной машине используют службу теневого копирования томов (VSS). Когда Veeam делает бэкап сервера с MS SQL, он может инициировать стандартную операцию создания полной резервной копии базы данных. Эта операция регистрируется в MS SQL Server как обычный полный бэкап и, соответственно, разрывает существующую цепочку для планов обслуживания.

Чтобы этого избежать, в MS SQL Server существует специальный тип резервного копирования — COPY_ONLY. Бэкап, созданный с этим флагом, является самодостаточной копией и, что самое главное, не влияет на основную цепочку восстановления. Он не сбрасывает точку отсчета для разностных бэкапов.

Разберем по шагам, как настроить стороннее ПО, чтобы оно не нарушало ваши планы обслуживания:

1. Откройте настройки задания резервного копирования в вашей системе (например, в Veeam Backup & Replication).
2. Перейдите в раздел, отвечающий за обработку гостевой ОС и приложений (Guest Processing, Application-Aware Processing).
3. Найдите настройки для Microsoft SQL Server. В них должна быть опция, включающая режим "только для копирования". В Veeam она так и называется: "Perform copy only". Включите этот флаг.
4. Также обратите внимание на настройки обработки журналов транзакций. Если вы управляете усечением логов (log truncation) с помощью собственных планов обслуживания SQL, то в стороннем ПО следует выбрать опцию, которая не будет вмешиваться в этот процесс (например, "Do not truncate logs" в Veeam).
5. Сохраните изменения.

После применения этих настроек все новые резервные копии, создаваемые Veeam или аналогичной программой, не будут нарушать последовательность, заданную вашими планами обслуживания в MS SQL Server. Новые разностные бэкапы будут корректно привязываться к плановым полным бэкапам, и проблема с восстановлением исчезнет.

Решение 2: Если цепочка уже нарушена и нужно срочно восстановиться

Что делать, если проблема уже произошла, и у вас на руках есть разностный бэкап, который не восстанавливается на плановый полный? Это значит, вам нужно найти тот самый промежуточный полный бэкап, на основе которого он был создан.

В этом случае необходимо:

1. Выяснить, где хранятся бэкапы, созданные сторонним ПО или другим администратором.
2. Найти полный бэкап, дата и время создания которого предшествуют нужному вам разностному бэкапу.
3. Выполнить восстановление, используя именно эту пару:
   • Восстановить найденный "промежуточный" полный бэкап с опцией WITH NORECOVERY.
   • Следом восстановить ваш разностный бэкап с опцией WITH RECOVERY.

Для точного определения связи между полным и разностным бэкапами можно использовать системные таблицы MS SQL, в частности msdb.dbo.backupset. У разностного бэкапа значение поля database_backup_lsn должно совпадать со значением поля first_lsn у его базового полного бэкапа. Это технически сложный путь, но он позволяет со 100% уверенностью найти правильную пару для восстановления.

Общие рекомендации и правильная последовательность восстановления

Вне зависимости от причин, давайте еще раз закрепим правильный алгоритм восстановления базы из полного и разностного бэкапов:

1. Восстановление полного бэкапа. Всегда начинайте с него. При восстановлении используйте опцию WITH NORECOVERY. Этот параметр указывает SQL Server, что процесс восстановления еще не завершен, и база данных должна оставаться в состоянии "Restoring", готовая к применению следующих копий (разностных или журналов транзакций). Также может потребоваться опция WITH REPLACE, если вы восстанавливаете поверх существующей базы с тем же именем.
2. Восстановление разностного бэкапа. После успешного применения полной копии, приступайте к разностной. Если это последняя копия в вашей цепочке восстановления, используйте опцию WITH RECOVERY. Этот параметр завершает процесс восстановления, выполняет откат незавершенных транзакций и делает базу данных доступной для работы.
3. Проверка путей к файлам. При восстановлении в новую базу или на другой сервер убедитесь, что на вкладке "Файлы" (Files) указаны корректные пути для физических файлов базы данных (.mdf) и журнала транзакций (.ldf) в целевой системе.

В заключение: ошибка "Неправильное состояние файла" почти всегда указывает на нарушенную цепочку резервных копий. Чаще всего виновником является стороннее ПО, создающее "неофициальные" полные бэкапы. Включение опции COPY_ONLY для таких систем и строгий контроль за всеми операциями резервного копирования являются ключом к стабильной и предсказуемой процедуре восстановления данных.