SQL Server-バックアップの復元-インデックスを失いますか？
クライアントサイトのように見えますが、データベースのバックアップと復元（SQL Server 2008からSQL Server 2012へ）の後、テーブルからインデックスが失われ、手動で作成する必要があったようです。これについては2つの例があります。
バックアップと復元はすべてのオブジェクトをそのまま維持すると思いました。これは可能ですか？復元中にユーザーが実際にオブジェクトを省略できる設定はありますか？
バックアップまたは復元からインデックスを省略できる設定はありません。そのような機能はバックアップがはるかに小さくなるのでいいでしょうが、Microsoftはそのような機能を追加するには多くのハードルがあると述べています（ ここ を参照）。
バックアップが完了したときにインデックスが存在しなかった可能性が最も高いです。データのロード前にインデックスを削除し、ロードの完了後にインデックスを再度作成するETLジョブがある場合があります。バックアップウィンドウに至るまでサーバーで発生する他のタイプのアクティビティを探します。たとえば、これを実行するETLジョブの場合、一部のロードに時間がかかりすぎて、バックアップが終了しても完了しない場合があります。そのため、バックアップにインデックスがある場合とない場合があるタイミングの問題があります。
それも可能ですが、実際にバックアップがデータベースのコピーを持つ別のサーバーで作成され、バックアップジョブが最初にインデックスを削除してバックアップを小さくすることを知っていると思います。あなたが報告したように、これはヒットまたはミスの状況ではありません。
また、ファイルグループを使用してこれを達成する別の方法について ここ を読むこともできますが、これも報告されているようにヒットまたはミスすることはありません。
質問は少し異なります（リストアで再構築フラグメント化されたインデックスを作成できるかどうかを尋ねていました） ただし、この回答（MS SQLエンジンチームの元メンバーから）が適用されますあなたの状況に直接 ：
バックアップは物理的な操作であり、論理的な操作ではありません。割り当てられたページを含むすべてのエクステントを読み取り（つまり、8ページのエクステントから1ページしか割り当てられていない場合でも、64Kエクステント全体をバックアップします）、物理的な順序で実行します。
インデックス（またはそのようなもの）の再構築は論理的な操作であり、ログに記録する必要があります。バックアップと復元では、バッファープールを経由せずにデータファイルを直接操作します。これが、これが実行できない理由の1つです。これを実行できないもう1つの理由は、バックアップと復元が、バックアップされるデータに何が含まれているかを理解していないためです。
結論-バックアップと復元は、データを変更することのない物理的な操作です。
したがって、あなたのケースでは（そしてトニーの答えと一致して）、それらがすべて論理操作であるため、インデックスを無視/削除/追加/再構築できるバックアップまたは復元の可能な設定はありません、適切に記録する必要があります。
最も可能性の高いシナリオは、インポート速度を最適化するためにインデックスを削除するある種のデータロードプロセスであるとトニーと同意します。おそらく、毎晩のデータロードが中断または失敗したか、インデックスが削除されてから再度追加される前に、ジョブの途中でフルバックアップが行われた可能性があります。