どのくらいの頻度でマスターデータベースをバックアップしますか？
[〜＃〜] bol [〜＃〜] の提案はかなり曖昧です：
ビジネスニーズに対してデータを十分に保護するために、必要な頻度でマスターをバックアップします。定期的なバックアップスケジュールをお勧めします。大幅な更新後に追加のバックアップを追加できます。
さらに に挑戦すると、次の詳細が表示されます。
マスターの更新を引き起こし、バックアップを実行する必要がある操作のタイプには、次のものがあります。
- ユーザーデータベースの作成または削除。
- ユーザーデータベースが自動的に拡大して新しいデータに対応する場合、
マスターは影響を受けません。- ファイルおよびファイルグループの追加または削除。
- ログインのセキュリティに関連するログインまたはその他の操作の追加。
- データベースへのユーザーの追加などのデータベースセキュリティ操作は、マスターには影響しません。
- サーバー全体またはデータベースの構成オプションの変更。
- 論理バックアップデバイスの作成または削除。
- リンクされたサーバーやリモートログインの追加など、分散クエリおよびリモートプロシージャコール（RPC）用にサーバーを構成する。
したがって、すべてのログインがWindowsグループを介して追加され、データベースに他の変更を加えない場合、それはマスターの1回限りのバックアップで十分であることを意味しますか？
そうでない場合、masterデータベースの標準のバックアップ間隔はどのくらいですか？
通常、マスターDBは非常に小さいです。少なくとも毎日、残りのデータベースと一緒にバックアップしてください。それは重要ですか？
個人的には、SHTFの場合、400日前に他の400個の同一のバックアップがある場合でも、数時間前のマスターdbバックアップが必要です。復元したくない場合はthinkをやりすぎないようにしたい...
- はい、前回のバックアップからサーバーへの変更（更新、ログインの追加、新しいデータベースの追加など）が行われなかった場合、実際には新しいバックアップを実行する必要はありません。しかし、これの何が問題なのか理解できません。マスターのバックアップは高速で、バックアップファイルは小さいです。
- 私の会社では、マスターバックアップは3つのグループに分かれています。
- 12時間に1回（平日に10から50のログインを追加できるサーバーの場合）
- 1日1回（ほとんどのサーバー）
- 週に1回（変更頻度の低いサーバーのごく一部）
それは標準ではなく、会社のルールです。
すべての本番データベースは、遅い時間帯に毎日バックアップされます。運用が24時間年中無休で実行されている場合、最初の回答のように12時間に1回をお勧めします。
本当に問題は、どれだけのデータとデータ構造を失う余裕があるかということです。隕石がマスターデータベースを破壊したので、地面にたった1つしか喫煙ピットがなかったとしたら、バックアップをどこまで速くバックアップできるのでしょうか。データベースを削除するイベントの不可能性を笑うことができますが、ビジネスラインがそれを使用する場合、ダウンタイムの許容度はほとんどありません。
毎日バックアップする場合、1日にどれだけの新しい情報を失う可能性がありますか？これらの変更を交換/やり直すにはどのくらいの時間がかかりますか？バックアップされなかった変更をやり直すことはできますか？どうやって知る....
他の誰かのポリシーに焦点を当てるのではなく、データ損失とダウンタイムに対する彼らの許容度を経営陣に尋ねる必要があります。