回答:
答えはノーです、どんなバックアップソフトウェアが使われているからです。
バックアップは物理的な操作であり、論理的な操作ではありません。割り当てられたページを含むすべてのエクステントを読み取り（つまり、8ページのエクステントから1ページだけが割り当てられている場合でも、64Kエクステント全体をバックアップします）、物理的な順序で実行します。
復元は物理的な操作であり、論理的な操作ではありません。データファイルの正当な場所にエクステントを配置します。
インデックス（またはそれに似たもの）の再構築は論理的な操作であり、ログに記録する必要があります。バックアップと復元では、バッファープールを経由せずにデータファイルを直接操作します。これが、これが実行できない理由の1つです。これが実行できないもう1つの理由は、バックアップと復元が、バックアップされるデータに何が含まれているかを理解できないためです。
ただし、これを実行できない主な理由は、復元操作中にページを移動すると、Bツリーポインターが壊れるためです。ページAがページBを指しているが、ページAが復元プロセスによって移動された場合、ページBはページAを指すように更新されますか？すぐに更新されると、残りの復元プロセスによって上書きされる可能性があります。遅延更新されている場合、復元プロセスでページAまたはページBを削除したトランザクションログが復元されたらどうなるでしょうか。それは単に行うことはできません。
結論-バックアップと復元は、データを変更することのない物理的な操作です。
お役に立てれば！
PSこの質問には直接対応していませんが、さまざまなバックアップが内部でどのように機能するかを説明している、7月のTechNet Magazineで私が書いた記事（SQL Serverバックアップについて）を確認してください。9月のマガジンは、復元の理解に関するシリーズの次の記事になります。
ネイティブ SQLのバックアップは、バックアップファイルのちょうどページ単位ダンプなので、答えは「ノー」があります。Quest lightspeedバックアップは、ある種の圧縮圧縮アルゴリズムを使用している可能性がありますが、それでもデータファイルまたはインデックスを「再構築」しないため、大きなデータベースでは非常に長い時間がかかります。
バックアップは定期的かつ頻繁に行われます（私はそう思います）。したがって、設計者はバックアップが可能な限り迅速であることを確認しました。最も速いI / Oは何ですか？一連の。正確な物理順序でディスクからブロックを読み取り、最高のパフォーマンスを発揮します。
なぜ地球上では、データベースが毎晩厄介なランダムI / O操作を実行して、ディスクの頭をあちこちに破壊する必要があるのでしょうか。違いはおよそ2桁です。これには可能な利益はありません。
うーん。BradC、以前にFirebird / Interbaseを使用したことがありますか？メインのバックアップ/復元ユーティリティ/ APIは、SSMS / EMの「データベースのコピー...」に似ていますか？もしそうなら、MS SQL Serverはそれが好きではないことを知っています。
SQLServerバックアップは、「現状のまま」で復元されるデータベースダンプです。したがって、「他の場所での切り離し、コピー、再接続」操作の快適なオンラインショートカットに似ています。復元されたデータベースは、元のデータベースファイルのほぼ正確なコピーです（復元されたデータベースのデータベースファイルの配置を変更できるためです）。