Paul Randalは、SharePoint SQLデータベースのベストプラクティスについていくつかの素晴らしい質問をしました。今日、顧客がSharePointのインストールを維持するのを支援しながら、SharePointデータベースの最適なSQL復旧モデルについて質問しました。
シンプルなリカバリモデルを使用するのが私の習慣です（私はDB管理者ではありません:)）））。SharePointデータベースが定期的にバックアップされ、サードパーティツールのバックアップもアイテムレベルで行う場合、ログ全体を保持する必要はありません。
ここで何か不足していますか？これは正しいアプローチですか？SharePoint DBログを使用してデータを回復したことがありますか？
回答:
それは、必要な管理作業量に対するデータ量の損失に完全に依存します。単純な復旧モデルを使用していて、日曜日に週に1回バックアップを取る場合...土曜日の11:59にクラッシュした場合、1週間分の作業が失われます。バックアップの頻度を増やす（または差分を取る）と、データ損失の量が減ります。
定期的な完全/差分バックアップをとるが、トランザクションログで完全復旧モデルを使用することにより、最後のバックアップを復元し、クラッシュ直前の時点までトランザクションログを再生し、データをほとんどまたはまったく失うことはありません。
ポールランダルと言えば...彼は今月TechNet Magazineでこのトピックについての素晴らしい記事を書いたところです:) http://technet.microsoft.com/en-us/magazine/dd822915.aspx
データベースだけをバックアップしても、Sharepoint情報がすべて取得されるわけではありません。確かにデータベース内のすべてを取得しますが、すべてのカスタマイズとルックアンドフィールは失われます。これは管理者には関係ないかもしれませんが、ユーザーが不満を感じることは間違いありません。
オプションには、バックアップソフトウェアのSharePointデータベースを読み取ることができるバックアップエージェントを取得するか、構成情報を取得するスクリプトバックアップを実行して、SQLデータベースバックアップと同様に安全な場所に配置することが含まれます。
http://technet.microsoft.com/en-us/library/cc288330.aspx いくつかの情報があります。
バックアップをテストします。それらを復元します。何が変化し、何が機能し、何が機能しないかを確認します。私たちの最初の復元は、それができたであろうほど良くはありませんでした。幸い、失われたデータや破壊されたデータを回復するのではなく、運用サーバーの複製であるテストサーバーを作成するプロセスの一部にすぎませんでした。
関連性のために編集された これをもう一度読んだとき、気が散って、回答の回答ポイントを逃したことに気づきました。トランザクションログを使用して完全バックアップを実行すると、より細かい時点までロールバックできます。これにはDBAとしてのスキルが必要ですが、それほど難しくはありません。大量の更新がなく、1日の作業を失うことが世界の終わりではない場合は、おそらく問題ありません。その他のオプションには、単純なバックアップをより頻繁に実行することが含まれます。真夜中、午前10時、午後2時、午後6時、または組織のワークサイクルに有効なものを言います。これにより多くのディスクが消費されますが、データ損失のリスクは軽減されます。すべてのバックアップと同様に、それはユーザーが許容するものと管理者が提供できるものの間のバランスです。
SharePointはSQLデータベースなので、SharepointはSQLデータベースのように扱う必要があります。そのため、通常のSQLセットアップの予防策をすべて講じてください。バックアップについては、データベースを定期的にバックアップするだけでなく、すべてのSP情報を保持する12ハイブをバックアップする必要があります。
詳細については、このスレッドを確認してください：http : //social.technet.microsoft.com/Forums/en-US/sharepointgeneral/thread/102c5c71-38a3-4360-b5cb-9b8b7c07bfea