web-dev-qa-db-ja.com

毎週の完全バックアップと毎日の差分バックアップ、毎週の完全バックアップを保存しますか？

毎週日曜日の朝に行われる完全バックアップを実行する保守計画を作成したいと考えています。月曜日から金曜日の勤務時間後、この完全バックアップに基づいて差分バックアップを実行したいと考えています。ただし、前週のフルバックアップを上書きするのではなく、そのフルバックアップに関連する差分を取り除きながら、履歴記録/オフサイト用にそのフルバックアップを保持したいと考えています。私が作成しようとしている計画のタイプは次のとおりです：

  • 必要に応じて、データベースインデックスの再構築が日曜日の午前AMから始まります。
    • これに対するさらなる注意は、存在する断片化の量に基づいて、代わりに統計を再編成+更新することです。
  • インデックスのメンテナンスに続いて、同じ朝に完全バックアップが作成されます。
  • 月曜日から金曜日の夜、完全バックアップに基づいて差分バックアップが作成されます。
  • 差分に続いて、DB整合性チェックが実行されます。
  • 次の日曜日に到着し、完全バックアップが確立され、前週の差分が削除され、前の完全バックアップがローカルでDroboに時間外に持ち込まれます。

このタイプのプランの理由は、私が作業しているAzure環境のHDDサイズ制限によるものです。それを踏まえて、これは適切な戦略ですか、それともどこに改善を求めればよいですか？次に、前週の完全なデータベースバックアップを保持し、差分は保持しない方法を教えてください。これまでに読んだ記事は、この種の回転バックアップでは完全バックアップと差分の両方が削除されることを示しているようです。

これは、Windows Server 2012上のSQL Server 2012インスタンスですVM。このタイプのプランの影響を受ける6GBから10GBまでの範囲の5つのデータベースがあります。

ご協力ありがとうございます。

sql-serverbackupmaintenance
3
PicoDeGallo

あなたが述べたように、あなたのバックアップ戦略は以下のように見ることができます：

enter image description here

このタイプのプランの理由は、私が作業しているAzure環境のHDDサイズ制限によるものです。

できる2つの重要なこと

  1. インスタントファイルの初期化を有効にする （Azure VMでSQL Serverを実行するときは その他のベストプラクティス に従ってください）
  2. バックアップ圧縮 を有効にし、WITH COMPRESSIONでバックアップを取得します

それを踏まえて、これは適切な戦略ですか、それともどこに改善を求めればよいですか？

上図から明らかな改善の余地があります。 Satで差分バックアップを行う必要があります（災害が発生した場合に備えて）。また、読むことは重要です バックアップが失敗しました：差分の危険性 。バックアップ戦略の途中でフルバックアップを行う必要がある場合は、COPY_ONLYバックアップを使用してください。

次に、前週の完全なデータベースバックアップを保持し、差分は保持しない方法を教えてください。

顕著な欠点があるため、メンテナンスプラン は使用しないでください。 Olaのバックアップソリューション を使用することを強くお勧めします（そして インデックスメンテナンスソリューション も同様です）。

編集：コメントどおり：

フルバックアップが途中で発生した場合、ベースが変更され、最後のフルバックアップを誰が行ったか分からないため、差分は役に立ちません。差分は、最後の完全バックアップに依存しています。人々がアドホックフルバックアップを実行して差分をめちゃくちゃにすることがわかっている場合は、バックアップの権限を拒否し、COPY_ONLYオプションを使用してフルバックアップを実行するストアドプロシージャを作成し、そのSPへの実行権限を付与します。さらに、データベースの復旧モデルに集中してください-完全復旧モデルにはログバックアップが必要です。

msdb.dbo.backupsetwhere is_copy_only = 0をクエリして、user_nameバックアップを取っているユーザーのCOPY_ONLYを確認することもできます

完全を期すためにこれを追加するだけ ユーザーをCOPY ONLY LOGバックアップに制限する

1
Kin Shah