masterデータベースをバックアップする頻度は？

BOLの提案はかなりあいまいです。

必要に応じてマスターをバックアップし、ビジネスニーズに合わせてデータを十分に保護します。定期的なバックアップスケジュールをお勧めします。これは、大幅な更新後に追加のバックアップで補完できます。

あなたはベンチャー場合はさらに、あなたはこれらの詳細を見つけます：

マスターを更新し、バックアップを実行する必要がある操作の種類には、次のものがあります。

• ユーザーデータベースの作成または削除。
• ユーザーデータベースが新しいデータに対応するために自動的に成長する場合、
  マスターは影響を受けません。
• ファイルとファイルグループの追加または削除。
• ログインまたはログインセキュリティに関連するその他の操作を追加します。
• データベースへのユーザーの追加などのデータベースセキュリティ操作は、マスターに影響しません。
• サーバー全体またはデータベース構成オプションの変更。
• 論理バックアップデバイスの作成または削除。
• リンクサーバーやリモートログインの追加など、分散クエリとリモートプロシージャコール（RPC）用のサーバーの構成。

すべてのログインがWindowsグループを介して追加され、データベースに他の変更を加えない場合、それはマスターの1回限りのバックアップで十分であることを意味しますか？

そうでない場合、masterデータベースの標準バックアップ間隔はどのくらいですか？

通常、マスターDBは非常に小さいです。少なくとも毎日、残りのデータベースでバックアップしてください。それは重要ですか？

個人的には、SHTFの場合、400日前に400個の同じバックアップがあったとしても、数時間前のマスターデータベースバックアップが必要です。私はそれを復元しなければならない場合にあまり考えたくない...

1. はい、サーバーへの変更（更新、ログインの追加、新しいデータベースの追加など）が最後のバックアップから行われなかった場合、実際に新しいバックアップを行う必要はありません。しかし、これの問題点を理解することはできません。マスターのバックアップは高速で、バックアップファイルは小さいです。
2. 私の会社では、マスターバックアップは3つのグループに分かれています。
   • 12時間に1回（勤務時間中に10〜50のログインを追加できるサーバーの場合）
   • 1日1回（ほとんどのサーバー）
   • 1週間に1回（変更の頻度が少ないサーバーの一部について）

これは標準ではなく、会社のルールです。

すべての本番データベースは、遅い時間に毎日バックアップされます。24時間年中無休で運用されている場合、最初の回答のように12時間に1回お勧めします。

本当に問題は、どれだけのデータとデータ構造を失う余裕があるかということです。met石がマスターデータベースを破壊したために、地面に喫煙ピットが1つしかなかった場合、その場所を取るためにバックアップをどれだけ速く起動できましたか？データベースを取り出すイベントが不可能であることを笑うことはできますが、ビジネスラインがそれを使用する場合、ダウンタイムに対する許容度はほとんどありません。

毎日バックアップする場合、1日にどれだけの新しい情報を失うことができますか？これらの変更を置き換え/やり直すのにどれくらいの時間がかかりますか？バックアップされなかった変更をやり直すことはできますか？どうやって知る....

他の誰かのポリシーに焦点を合わせるのではなく、データの損失とダウンタイムに対する彼らの許容範囲を管理者に尋ねる必要があります。