MAXTRANSFERSIZEおよびCHECKSUMが使用されている場合、TDE対応データベースを復元できません
Update： @ AmitBanerjee -Microsoft SQL Server製品グループのシニアプログラムマネージャーは、MSが問題を調査することを確認しました- それは欠陥です。
TDEが有効でMAXTRANSFERSIZE> 65536を使用してSQL Server 2016で作成されたバックアップを復元するときに問題が発生しましたか（私の場合、65537を選択して TDEデータベースを圧縮できる ）およびCHECKSUM？
以下は再現です：
--- create database
create database test_restore
go
-- create table
create table test_kin (fname char(10))
go
-- Enable TDE
use master
GO
CREATE CERTIFICATE test_restore WITH SUBJECT = 'test_restore_cert'
GO
SELECT name, pvt_key_encryption_type_desc, * FROM sys.certificates WHERE name = 'test_restore'
GO
use test_restore
go
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128 ENCRYPTION BY SERVER CERTIFICATE test_restore
GO
alter database test_restore set encryption ON
完全なコピーのみのバックアップを取る.. 2回実行する..
backup database test_restore
to disk = 'D:\temporary-short-term\test_restore_KIN_test_restore_1.bak' -- change as per your location !!
with init, stats =10 -- overwrite ..using INIT !!
, maxtransfersize = 65537
, compression
,CHECKSUM
verifyonlyを実行してください...
restore verifyonly from disk = 'D:\temporary-short-term\test_restore_KIN_test_restore_1.bak'
エラーメッセージ ：
メッセージ3241、レベル16、状態40、行11デバイス 'D：\ temporary-short-term\test_restore_KIN_test_restore_1.bak'のメディアファミリの形式が正しくありません。 SQL Serverはこのメディアファミリを処理できません。メッセージ3013、レベル16、状態1、行11 VERIFY DATABASEが異常終了しています。
さまざまな組み合わせの結果（1 =オン、0 =オフ）：
+-------------------------+-------------+----------+--------+
| MAXTRANSFERSIZE (65537) | COMPRESSION | CHECKSUM | RESULT |
+-------------------------+-------------+----------+--------+
| 1 | 1 | 1 | FAIL |
| 1 | 1 | 0 | PASS |
| 1 | 0 | 1 | FAIL |
| 0 | 0 | 0 | PASS |
| 0 | 1 | 1 | PASS |
| 0 | 1 | 0 | PASS |
+-------------------------+-------------+----------+--------+
この問題は次の場所で発生します：
Microsoft SQL Server 2016（RTM-CU1）（KB3164674）-13.0.2149.0（X64）2016年7月11日22:05:22 Copyright（c）Microsoft Corporation Enterprise Edition（64-bit）on Windows Server 2012 R2 Standard 6.3（Build 9600 ：）
問題を再現することができました。
FORMATをBACKUPコマンドに追加すると解決しました。
具体的なドキュメントが見つからないようですが、これは、INITがバックアップセットの既存のメディアヘッダーを保持し、FORMATが新しいメディアヘッダーを作成するという事実に関連していると私は考えています。
私はまだこの問題を調査しており、追加情報が見つかった場合は、この回答を更新します。
このような問題は、KB 4032200で対処された可能性があります。
そのエントリから：
症状
Microsoft SQL Server 2016でデータベースの透過的データ暗号化（TDE）を有効にするとします。
BACKUP DATABASET-SQLステートメントを使用してデータベースをバックアップしようとします。COMPRESSIONとINITオプションの両方が指定されています。このシナリオでは、既存のバックアップファイルが新しいバックアップファイルによって上書きされ、新しいバックアップファイルは圧縮されない場合があります。解決
この問題は、SQL Serverの以下の累積的な更新で修正されています。
これは、質問で参照した ブログ投稿 が後で参照するように更新されたのと同じ問題である可能性があります。
2017年4月6日更新
SQL Server 2016でのTDEとバックアップ圧縮の使用に関連するいくつかの問題を最近発見しました。これらを修正する一方で、これらの既知の問題に遭遇しないようにするためのヒントをいくつか紹介します：
現在、TDEおよびバックアップ圧縮でストライプバックアップを使用することはお勧めできません
データベースに4GBを超える仮想ログファイル（VLF）がある場合、ログバックアップにTDEでバックアップ圧縮を使用しないでください。 VLFが何であるかわからない場合は、開始 ここ 。
WITH INIT現在のところ、TDEおよびバックアップ圧縮を使用する場合は使用しないでください。代わりに、現時点ではWITH FORMATを使用できます。
SQLエンジニアリングはSQL Server 2016でこれらの問題の修正に取り組んでいます。共有できる詳細情報があり次第、このブログ投稿を再度更新します。
そのメモにもかかわらず、それ以降、ブログの投稿は更新されていません。
ただし、 KB 401989 でもこれに対処できます。
そのKB記事で報告されたエラーメッセージは、あなたが報告しているものとは異なりますが、要因は非常によく似ています。 hotfix list に示されているように、SQL Server 2016 SP1 CU3には最初に修正が含まれていました。ただし、 報告がありました すべての状況で問題が解決したわけではありません。
SQL Server 2016 SP1 CU4も これに対する（おそらく更新された）修正が含まれています 、および KB 401989 は、問題が修正されたバージョンとしてSP1 CU4を表示するように更新されています。
残念ながら、自分の経験から、SP1 CU4の修正でさえその問題を完全には解決しないことを確認できます。現在、1つのTDE対応データベースがあり、 COMPRESSION（MAXTRANSFERSIZE> 64 KB経由）およびCHECKSUMを使用すると、SP1 CU4でも一貫して破損したバックアップが引き続き生成されます。この環境には他にも数十のTDE対応データベースがあり、一貫してdo n'tは、これらの設定で破損したバックアップを生成します。より小さなデータセット。これは、Microsoftがこれを引き起こす可能性のあるシナリオを実際に削っていることを示しているようですが、まだすべてを解決していません。
別の回答とSQLCAT ブログ投稿 で参照されているように、この問題を回避するためにFORMATをまだ使用していませんが、可能であればここで更新を提供しますそれを試して問題を解決します。これを再現する1つのデータベースは残念ながらかなり大きく（約1 TB）、（少なくともその規模で）利用可能な追加のストレージ領域がない開発/ QAクラスターにあるため、これのバリエーションをテストするとロジスティックに挑戦し、時間がかかることが証明されています。