Відновлення диференціальної резервної копії створює файл журналу DEFUNCT?

Ось моя проблема. Я намагаюся перенести базу даних на новий сервер через повне відновлення, а потім розріз із швидким диференціальним резервним копією / відновленням. Я можу зробити повне відновлення без проблем, але при відновленні резервної копії диференціалу я отримую таке попередження:

Msg 3127, рівень 16, стан 1, рядок 1 Файл 'Database_Log2' відновленої бази даних 'DatabaseName' залишається в неіснуючому стані, оскільки база даних використовує просту модель відновлення, а файл позначений для доступу для читання-запису. Отже, відновлення лише за допомогою фрагментів може бути відновлено лише файли лише для читання.

База даних відновлюється і вважається в Інтернеті, але будь-яка операція резервного копіювання завершується невдачею через цей файл DEFUNCT із наступною помилкою:

Msg 3636, Рівень 16, Стан 2, Рядок 1 Під час обробки метаданих 'BackupMetadata' для ідентифікатора файлу бази даних 10 10 сталася помилка. 6. Msg 3046, рівень 16, стан 2, рядок 1 Виникли непослідовні метадані. Єдина можлива операція резервного копіювання - це резервне копіювання журналу хвоста, використовуючи параметр WITH CONTINUE_AFTER_ERROR або NO_TRUNCATE. Повідомлення 3013, Рівень 16, Стан 1, Рядок 1 БЕЗПЕКА БАКУПАЦІЇ закінчується аномально.

Якщо я роблю ПОНЯТТЕ ФІЛІСТИЧНО на повній та диференціальній, обидва дають мені однаковий вихід, який відповідає тому, що я бачу з sys.database_files у вихідній базі даних. Сервер - SQL2012 SP1, у версії Developer.

Я можу зробити повне резервне копіювання та одразу після цього зробити диференціальний та відновити ці файли в іншій базі даних на тому ж сервері і побачити ту саму проблему, тож є щось із того, як створюється диференціальний, що викликає це. Якщо я відновлю повну резервну копію із ВІДНОСНЕННЯм, проблем немає. Я не знаю, чи існував цей файл у цій базі даних, але цілком можливо, що цей файл існував і був видалений давно. Якщо я запитую sys.database_files у відновленій базі даних, у файлі DEFUNCT є значення для drop_lsn, яке, здається, підтверджує це. В даний час у вихідній базі даних є лише одна група файлів (ПЕРВИЧНА), 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.

ОНОВЛЕННЯ: Помилка, що створює цей сценарій у моєму сценарії repro, здається, виправлена ​​цим КБ: https://support.microsoft.com/en-us/kb/2830400 . З коментарів, як видається, доступний додатковий виправлення для SQL2012 / 2014, сценарії здаються дуже схожими: https://support.microsoft.com/en-us/kb/3009576