最新の状態へのリストア処理（デフォルト）では、障害発生時点までデータベースがリカバリされます。SnapCenterでは、この処理が次の順序で実行されます。

最新の状態へのリストア処理を実行するには、連続したトランザクション ログ セットが必要です。

SnapCenter は、ログ配布バックアップ ファイルから SQL Server データベースのトランザクション ログを復元できないため (ログ配布を使用すると、プライマリ サーバー インスタンス上のプライマリ データベースから別のセカンダリ サーバー インスタンス上の 1 つ以上のセカンダリ データベースにトランザクション ログ バックアップを自動的に送信できます)、トランザクション ログ バックアップから最新の状態への復元操作を実行することはできません。このため、SQL Server データベースのトランザクション ログ ファイルをバックアップするには、 SnapCenterを使用する必要があります。

すべてのバックアップに最新の状態へのリストア機能を使用する必要がない場合は、バックアップ ポリシーを使用してシステムのトランザクション ログ バックアップ保持を設定できます。

毎日正午に SQL Server のバックアップを実行し、水曜日の午後 4 時にバックアップから復元する必要があるとします。何らかの理由により、水曜日の正午のバックアップの検証に失敗したため、火曜日の正午のバックアップを使用してリストアを実行することにしました。その後、バックアップが復元されると、火曜日のバックアップを作成した際にコミットされなかったトランザクション ログから始まり、水曜日の午後 4 時に書き込まれた最新のトランザクション ログまで (トランザクション ログがバックアップされている場合)、すべてのトランザクション ログが前へ移動され、復元されたデータベースに適用されます。

ポイントインタイム リストア処理では、データベースが過去の特定の時点にリストアされます。ポイントインタイム リストア処理は次の状況で発生します。

次の図は、ポイントインタイム リストア処理を実行した場合の問題を示しています。

この図のリカバリ パス1では、フル バックアップが作成され、その後複数のトランザクション ログ バックアップが作成されます。データベースをある時点にリストアします。ポイントインタイム リストア処理のあと、新しいトランザクション ログ バックアップが作成されて、リカバリ パス2が発生します。新しいトランザクション ログ バックアップが作成されるときに、新しいフル バックアップは作成されません。新しいフル バックアップが作成されるまでの間は、データ破損やその他の問題が発生しても現在のデータベースをリストアできません。また、リカバリ パス2で作成されたトランザクション ログを、リカバリ パス1のフル バックアップに適用することはできません。

トランザクション ログ バックアップ セットを適用する場合は、トランザクションの適用を終了する日時を指定することもできます。これを行うには、使用可能な範囲内で日付と時刻を指定すると、 SnapCenter はその時点より前にコミットされていないトランザクションを削除します。この方法を使用すると、破損が発生する前の時点にデータベースをリストアしたり、誤って削除したデータベースやテーブルをリカバリしたりすることができます。

フル データベース バックアップを午前0時に1回、トランザクション ログ バックアップを1時間おきに実行しているとします。データベースは午前 9 時 45 分にクラッシュしましたが、障害が発生したデータベースのトランザクション ログをバックアップします。この場合、次に示すポイントインタイム リストアのシナリオが考えられます。

この場合は、エラーが報告された日時を特定します。指定した日時までにコミットされていなかったトランザクションすべては削除されます。