SQL Serverバックアップ-ログ配布とVMスナップショット
セットアップ
AWS VMでSql Server Standardを実行しています
このサーバー上の私のDBの1つについて、以下を実行します。
1x日次バックアップ
また、このDBのログ配布専用の別のDBサーバーVMに15分ごとにログを配布します。
長期的には、ログ配布VMをレポートDBとし、プライマリサーバーの負荷を軽減する役割を果たすことを意図していましたが、この要件は今では費用を節約することに次ぐものです。
回復の重要度（RTO/RPO）
公式のSLAはありません。ただし、一般的なコンセンサスは次のとおりです。ライブシステムのマイナス1時間以内に回復することは、このシステムではほとんど許容できると見なされています。昨夜のバックアップに行かなければならない場合でも、虐待を受けた後でも生き残ることができます。 2時間以内の回復が理想的ですが、最大12まで許容できます。
お金を節約するための新しいアプローチ-VMスナップショット
ログ配布をオフにすることを検討していますVMおよび本番DBのスナップショットに切り替えるVM 1時間ごと。これにより、年間1,000ドルも節約できます。） Note私は完全なAWS EC2 VM EBSスナップショットであり、SQL DBスナップショットではない）を参照しています。
私はこれらのVMスナップショットを古いデータの重要でない調査のために過去にスピンアップして非常に満足しています。しかし、DR計画の一部としてそれらに依存していません。
質問
-上記で言及したDBリカバリプロファイルを考慮して、スナップショットに切り替えますか、それとも他に何かしますか？ -誰かが古いSQL Serverを起動する際に問題がありましたかVMスナップショット？
ありがとう
（以下のこの回答はちょっと役に立ちましたが、私も実際の体験に興味があります。 Are VM SQLをバックアップするのに十分なスナップショットですか？ ）
VMスナップショットは1）の問題は、最も安価なオプションではありません。通常、データベースのバックアップよりも保存にコストがかかります。 2）それらは多くのことからあなたを守りません。
費用を節約するには、完全バックアップとログバックアップを続行し、コールドスタンバイを維持しますVM災害時に起動して復元できます。数週間ごとに起動しますパッチを取得し、復元プロセスをテストします。
おそらく、ログ配布ジョブを変更してセカンダリVMをシャットダウンすることにより、現在の設定を最小限に変更するだけでこれを実行できます。あなたはそれを毎週持ち出して、すべてのログを適用することができます。そうすれば、完全なデータベースの回復からわずか数回のリストアで済みます。