私はこれに対する答えを知っていると確信していますが、ある時点での回復の制限が私の心を吹き消します。
2TBのデータベースがFULL
リカバリモードに設定されているとしましょう。毎週のフルバックアップ、毎日の差分バックアップ、ログのバックアップを30分ごとに行っています。
ここで、データベースを1時間前にロールバックします。完全バックアップ、差分、およびログ全体を最大1時間前に復元する必要がありますか?これには非常に長い時間がかかると思いますか?
トランザクションログファイルを使用して変更をROLLBACK
する方法がないため、このタイプのリカバリには数分かかりますか?
はい。SQLServerでポイントインタイムリカバリを実行するには、フルバックアップ、最大1つの差分バックアップ、および必要なすべてのログバックアップを復元する必要があります。 SQL Serverでは、すでにコミットされたトランザクションをロールバックして時間を遡ることはできません。 STOPAT
構文を使用して、データベースを希望する正確な 特定の時点 に復元することをお勧めします。
実際、トランザクションログのバックアップを30分ごとに実行しているため、SQL Serverは各ログバックアップでトランザクションログもクリアしています。そのため、1時間前に戻ると、SQL Serverはロールするために必要な情報すらありません。 SQL Serverにそのような機能があったとしても(悲しいことにそうではありません)、それまでのところです。
復元時間はデータベースの大きさ、log/diffバックアップに含まれる変更の数、および必要なログバックアップの数に応じてかなり異なるため、「非常に長い時間」がかかるかどうかはわかりません。復元されました。非常にビジーではない小さなデータベースの場合、復元はかなり高速になる可能性がありますが、非常にビジーなマルチテラバイトのデータベースの場合、しばらく時間がかかる可能性があります。
Oracleには Flashback と呼ばれる機能があり、説明したとおりに実行できますが、SQL Serverには同等の機能がありません。
ユースケースに応じて、 SQL Serverスナップショット機能 の使用を検討できます。特定のテスト開始条件に一致するようにDBをリセットしたい場合は、本番環境を実行する前、および非Prod環境でこの機能を使用します。スパースファイルを利用し、変更されたページのみをコピーしてスナップショットを維持し、特定の時点の1つ以上のスナップショットを維持できるため、特にVLDB設定の細かい変更を追跡する場合に非常に効果的です。注意が必要なことの1つは、スパースファイルのサイズが大きくなり、スパースファイルが配置されているスペースが不足すると停止する可能性があるため、変更されるページの量です。
はい、要するに。
最後の完全バックアップ、最新の差分バックアップ、最後の差分バックアップ以降のすべてのログバックアップを復元する必要があります。
これが、データベースが大きくなりすぎた場合の理由です。通常、開発チームに古いデータ(保存期間よりも古い)を削除するよう依頼します。場合によっては、パージのオプションがなく、それに対処する必要があります。
より適切に準備するために、常にテスト環境でデータベースを回復する練習をしてください。これにより、概算が得られます。見積もりに加えて、RTOについて合意することができます。
なぜロールバックできないのかについては、良い答えがいくつかあります 1 & 2 。 @AMtwoの回答には、回復の速さについての話があります。私はそれを少し拡張し、あなたのタイトルの質問に取り組みたかったのです。
SQL Serverのポイントインタイムリカバリには、完全なリカバリと同じくらいの時間がかかりますか?
完全バックアップを復元する必要があるため、特定の時点(PIT)の回復には少なくとも1つのtログが必要なので、PITは常に完全回復と同じくらいの時間がかかります。
差分バックアップは通常、バックアップを保存する場所を節約するために行われます。システムに大きな変更がない場合、これらは通常、完全バックアップよりもはるかに小さくなります。 6つの差分と1週間分のt-logを使用する単一の完全バックアップは、通常、7つの完全バックアップとt-logに比べて大幅に少ないスペースで済みます。
差分バックアップは、その完全バックアップ以降に変更されたデータのみをキャプチャします。 ソース
差分の場合、完全にバックアップしてから、最初に復元する必要があります。
必要に応じて、差分をスキップし、stopat
を使用してPITするまで完全バックアップとすべてのt-logバックアップを復元できます
私は定期的にバックアップテストを行っています。大きなハードルの1つは、古いバックアップを安全な場所(テープ、オフサイトストレージなど)からサーバーに移動するときです。これはデザインによって異なります。あなたのビジネスだけが、今回が何であるかを知ることができます。
バックアップがサーバー上にあると、それらは復元されます。最終的に、フルとPITのリカバリ時間の差は、変更がどれだけあったかによって異なります。
数百回のPITリストアの私の経験では、1秒間のPITの余分な時間はわずかで、数秒または1分です。 Full、Differential、およびすべてのt-logを1つのフォルダーに入れ、GUIを使用して復元(SQL 2012+)を実行し、すべてを選択すると、それらが自動的にソートされ、PITに復元されます。困難または追加時間。
TL:DRその他、ビジネスや設計に固有のいくつかの変数。サーバーのポイントインタイムリカバリには、完全なリカバリとほぼ同じ時間がかかります。
特に30分ごとにバックアップがある場合は、以前のトランザクションがアクティブなトランザクションログに残っているという保証はありません。残念ながら、最新の完全な復元、最新の差分、そしてその差分以降に取られたすべてのトランザクションログバックアップを復元する必要があります。