標準のデータベースバックアップ手順
私は、データベースが1日に数回バックアップされている（そしてバックアップの最後の週は常に利用可能である）ホストされたクライアント用に実装したセットアップを見てきました。バックアップには20GBが必要であり、バックアップがホストされているドライブ（実際にはパーティション）は30GBであるとします。ドライブには、SQL 2000のインストール、OS、その他のさまざまなものにまたがって10 GBを超える他の「もの」があります。つまり、ドライブを完全にいっぱいに保つのに絶えず苦労しています。
SCSIドライブに1週間のバックアップを保存する必要はないと思いますが、私はこの分野の専門家ではなく、他のDBAがこの種のバックアップスキームをどのように管理しているかについてアドバイスを求めていますか？
注目に値するのは、現在3台のドライブ、ミラー化されたRAIDセットアップ、およびいつでもスワップインできるスペアを使用していることです。したがって、コストを最小限に抑えながら、ディザスタリカバリが問題の中心になります。
どんな入力も歓迎します...
よろしくお願いします。
標準のSQLServerセットアップ/バックアップ手順（SQL 2000-2008）として以前に実装したものは、次のとおりです。
データ分割OS/SQLバイナリ、データファイルおよびログファイルを3つの別々の物理ボリューム（RAID1上のOS/SQL、RAID 1上のデータ）に分割します（ Paul Randall（ http://www.sqlskills.com/ ）、Logs on RAID 1からのコメントに続くこの更新。また、1〜2個のホットスペアをお勧めします。少なくともある程度のRAIDをお勧めします。可能な限りすべてですが、スペース/コストが問題になる場合は、RAID 1を使用して、それらをすべて1セットのドライブに配置しても、RAID 5と同じレベルの冗長性（最大1台のドライブ障害）があります（2台とそれぞれ3台のドライブ）
データベースのセットアップデータベースごとに3つのデータファイルを実装します。デフォルトのMDFおよびデータとログのLDF、およびNDF、データベースプロパティでデフォルトのデータファイルとしてNDFを設定し、MDFのままにします。ミラーリングを行うため、すべてのデータベースを完全復旧モデルに設定しました。ポイントインタイムの復元を行うには、とにかくこれを行うことをお勧めしますが、警告が表示されます（以下）
[〜＃〜] backups [〜＃〜]データベース設定の最も重要な部分は、バックアップ（および関連する復元）を正しく取得することです。私の標準化されたセットアップは、データベースを使用していない人のウィンドウが狭い場合の午前2時の完全バックアップ（シンガポールからニューヨークまでの複数のタイムゾーンのスタッフによるグローバルオペレーション）であり、午前8時（0800、1300）から5時間ごとのトランザクションログバックアップです。 、1600、2100）。 免責事項データベースを完全復旧モデルに設定している場合は、トランザクションログのバックアップを行っていることを確認してください。 そうしないと、巨大なログファイルができてしまい、切り捨ててから縮小する必要があるかもしれません。これは、Paul Randall（Hi Paul！）によると、私は信頼しています。暗黙的にSQLに関連しているのは、aVeryBadThing（tm）です。毎日のバックアップ（それらに関連するトランザクションログを含む）は、マシンにローカルに保持され、バックアップサービスによって毎晩すくい上げられ、当直の管理者によってオフサイトに持ち出されます。このようにして、マシンが失われた場合、最後の完全バックアップからのデータのみが失われ、誰かがデータを台無しにした場合、最後のT-Logバックアップとその時点の間に入力された情報のみが失われます（現在のログと他のトランザクションの再生ですが、SLAはこれに対応するように構築されているため、通常は行いません）もちろん、作成時にトランザクションログのバックアップをマシン外またはオフサイトに送信することもできますが、それはあなたが行う決定です。
データファイルの縮小それをしないでください（それを避けられない状況に陥らない限り）確かにそれをスケジュールしないでください！
インデックス作成とフラグメンテーションこれは、必要な場合にのみ実行される手動の（ただしスクリプト化された）操作である必要があります。定期的なメンテナンスを実行し、インデックスの断片化を行う必要があります。このリストにあります。月次計画では、データファイルのサイズ、インデックスの断片化、データベースの数を確認します（開発者にデータベースを追加してもらわない場合があります。メンテナンス計画がバックアップを処理しますが、データファイルのレイアウトを台無しにする場合があります）および命名規則）、新しいデータベースが検出された場合、それらのサイズ、データファイルのレイアウト、およびバックアップに関して監査されます（バックアップをチェックして再チェックすることを損なうことはありません）
上記の穴を選ぶか、少なくとも私がナンセンスな話をしていることを教えてください。
「バックアップ」の観点からではなく、「復元」の観点から考えてください。座って、物事を取り戻すために必要なものを定義し、いくつかのリカバリをテストして、リストが正しく完全であることを確認してから、バックアップ戦略の検討を開始します。
一般に、サーバーアプリケーションでは、OS、プログラムファイル、構成、およびその他すべてのdoo-dahをバックアップすることが不可欠だと思います。生データの回復は簡単ですが、構成の回復は簡単ではありません。また、現在のパッチレベル、OSとアプリケーションの構成、サービスで使用するために作成したローカルユーザーアカウントなどがあります。
だから、すべてをバックアップすれば、あなたは何も見逃していないと確信しています。それが私の信条です。
これで、OSと同じストレージに1週間、1日あたり数回のバックアップを保持します。誤って一部のデータを失った場合、これは問題ありません。 OSを紛失したり、ハードウェアに障害が発生したりした場合でも、間違いなくEFF-YOU-SEE-KAYされます。
私が以前に使用したアプローチの1つは、日中は定期的にデータ（のみ）をディスクにダンプすることですが、夜間はすべてをテープに完全にバックアップします。これにより、日中のダンプのストレージ要件が削減され、誤って失われたデータの回復ウィンドウが長くなる可能性があります（1週間以上の価値を維持することにより）。フルをテープに保持するということは、必要に応じて、代替サーバーに対してもすべてを完全に回復できることを意味します。私はさらに先に進むことができますが、今のところ私のビジネス要件は私を必要としません-あなたの力です。
説明したように、現在のバックアップ計画は、ディザスタリカバリが必要となる多くのシナリオを実際にはカバーしていません。
電源の誤動作などの重大な問題によってすべてのドライブが一度に停止した場合に備えて、少なくともサーバーを収容している建物に何かが起こった場合に備えて、別のサイトでバックアップをとっておく必要があります。
あなたが提案するように、新しいより大きなドライブなど、簡単にアクセスできるように、バックアップのローカルコピーをサーバー自体に保持することに何の問題もありませんが、これらが唯一のバックアップではありません。
現在のスペースに制約のある位置から、最新のバックアップをマシンのローカルに保持し、残りを別のマシンのより大きなドライブに、できればオフサイトに保持することをお勧めします（rsyncなどのプロトコルはオフに必要な帯域幅を減らすことができます-サイトのバックアップはかなり）。マシンに物理的にアクセスできる場所にある場合は、代わりに（または同様に）オフラインバックアップを外部ドライブにコピーし、他の時間にマシンから遠ざけることで（またはさらに良いことに、2つ以上の外部バックアップを）保持できます。ドライブとそれらのサイクル-USBケージ内の大型ドライブは最近非常に安価です）。物理的にアクセスできる場合は、サイクル内に多数のテープがあるテープドライブの方が適している場合があります。
つまり、ドライブが3つあるのに、実際には1ドライブ分のスペースを使用しているだけですよね。ミラー内の2つのドライブ+スペアとしての3番目のドライブ.。
RAID 5への移行により、ある程度のスペースを確保できます。
そうは言っても、質問で提案したように、バックアップを保持するために別の大きなドライブを追加することができます。