Восстановление разностной резервной копии создает файл журнала DEFUNCT?

Здесь моя проблема. Я пытаюсь переместить базу данных на новый сервер с помощью полного восстановления, а затем перенести с помощью быстрого разностного резервного копирования / восстановления. Я могу сделать полное восстановление без проблем, но при восстановлении разностной резервной копии я получаю следующее предупреждение:

Сообщение 3127, уровень 16, состояние 1, строка 1 Файл «Database_Log2» восстановленной базы данных «DatabaseName» остается в несуществующем состоянии, поскольку база данных использует простую модель восстановления и файл помечен для доступа на чтение и запись. Таким образом, только частичные файлы могут быть восстановлены путем частичного восстановления.

База данных восстанавливается и считается подключенной, но любая операция резервного копирования не выполняется из-за этого файла DEFUNCT со следующей ошибкой:

Сообщение 3636, уровень 16, состояние 2, строка 1 Произошла ошибка при обработке метаданных BackupMetadata для идентификатора файла базы данных с идентификатором 10. Сообщение 3046, уровень 16, состояние 2, строка 1 Обнаружены несогласованные метаданные. Единственная возможная операция резервного копирования - это резервное копирование с использованием опции WITH CONTINUE_AFTER_ERROR или NO_TRUNCATE. Сообщение 3013, Уровень 16, Состояние 1, Строка 1 РЕЗЕРВНАЯ БАЗА ДАННЫХ завершается ненормально.

Если я выполню команду RESTORE FILELISTONLY для полной и дифференциальной систем, то получу одинаковый вывод, который совпадает с тем, что я вижу из sys.database_files в исходной базе данных. Сервер SQL2012 SP1, для разработчиков.

Я могу сделать полное резервное копирование и сразу после этого сделать дифференциал, и восстановить эти файлы в другой базе данных на том же сервере и увидеть точно такую ​​же проблему, так что есть что-то с тем, как создается дифференциал, который вызывает это. Если я восстановлю полную резервную копию с помощью RECOVERY, проблем не возникнет. Я не знаю, существовал ли этот файл в этой базе данных, но вполне возможно, что этот файл существовал и был удален очень давно. Если я запрашиваю sys.database_files в восстановленной базе данных, в файле DEFUNCT есть значение drop_lsn, которое, кажется, подтверждает это. В настоящее время в исходной базе данных есть только одна файловая группа (PRIMARY), 4 файла данных и один файл журнала.

Есть идеи?

Вот шаги, чтобы воспроизвести это, протестировано на SQL 2012 SP1 Developer Edition. Это не происходит в SQL 2008. Подводя итог, можно сказать, что база данных, созданная в SQL 2012 в то время, когда база данных модели находится в режиме восстановления SIMPLE, с полной резервной копией, созданной при наличии дополнительного файла журнала, не может создать пригодные для использования разностные резервные копии, если этот дополнительный файл журнала когда-либо удалял

ALTER DATABASE [model] SET RECOVERY SIMPLE
GO
CREATE DATABASE [DefunctTest]
GO
ALTER DATABASE [DefunctTest] ADD LOG FILE ( NAME = N'DefunctTest_log2', FILENAME = N'D:\DefunctTest_log2.ldf' , SIZE = 25600KB , FILEGROWTH = 10%)
GO
BACKUP DATABASE [DefunctTest] TO DISK = 'D:\DefunctTestPostLogFile.bak' WITH INIT
GO
ALTER DATABASE [DefunctTest]  REMOVE FILE [DefunctTest_log2]
GO

BACKUP DATABASE [DefunctTest] TO DISK = 'D:\DefunctTestFull.bak' WITH INIT
GO
BACKUP DATABASE [DefunctTest] TO DISK = 'D:\DefunctTestDiff.bak' WITH DIFFERENTIAL, INIT
GO
--Show that the backups only have the one log file.
RESTORE FILELISTONLY FROM DISK = 'D:\DefunctTestFull.bak'
RESTORE FILELISTONLY FROM DISK = 'D:\DefunctTestDiff.bak'
GO
RESTORE DATABASE [DefunctTest2] FROM DISK = 'D:\DefunctTestFull.bak' WITH 
MOVE 'DefunctTest' TO 'D:\DefunctTest2.mdf',
MOVE 'DefunctTest_log' TO 'D:\DefunctTest2_log.ldf', REPLACE, NORECOVERY
GO
--This restore will have the error.
RESTORE DATABASE [DefunctTest2] FROM DISK = 'D:\DefunctTestDiff.bak' WITH RECOVERY
GO

USE [DefunctTest2]
SELECT * FROM sys.database_files
GO

Я отправил элемент Connect для этой ошибки здесь . Единственный способ удалить этот несуществующий файл - это отсоединить базу данных и заново присоединить ее с помощью ATTACH_REBUILD_LOG.

ОБНОВЛЕНИЕ: ошибка, которая создает этот сценарий в моем сценарии воспроизведения, кажется, была исправлена ​​этим KB: https://support.microsoft.com/en-us/kb/2830400 . Из комментариев видно, что дополнительное исправление доступно для SQL2012 / 2014, сценарии кажутся очень похожими: https://support.microsoft.com/en-us/kb/3009576.