SQL Serverバックアップは、WAN経由で毎日出荷されます。これらのバックアップのサイズを最小限に抑えて、時間がかからないようにする必要があります。
バックアッププロセスがもう少し長くてもかまいません。現状では、WANは10時間以上かかる)間で30ギグの圧縮バックアップを移動する必要があります。
毎日のバックアップを小さくする必要がある2つのオプションがあります。
どちらも私たちの側からかなりの量の作業を伴います。私たちはSQL Server 2008 proを使用しています。すべてのバックアップは圧縮されています。
オプション(2)と同様のバックアップサイズを提供できる市販製品はありますか?
(2)を実行できるcomprehensiveスクリプトがありますか? (インデックス付きビュー、フィルターされたインデックス、外部キーなどの処理)
コメントに基づいて最初に考えた...
たとえば6時間ごとに差分バックアップを使用して、バックアップ+ FTPのサイズ/時間を削減します。次に、完全バックアップ+ FTPを週末のみに減らします。これにより、ログ配布の複雑さが回避され、実行が簡単で、DRにわずかな複雑さが追加されるだけです
差分バックアップは見落とされているように感じます...以前にそれらを使用することをお勧めしました:
障害発生時に失われるデータの量を最小限に抑えながら、回復の観点からすべてをできるだけ単純にしたい
編集:jcolebrandのコメントの後で、私はもっと説明しようとします
差分バックアップは、変更されたページのみを取得します。インデックスのメンテナンス(データベースの多くに影響を与える可能性があります)を除いて、1日に変更されるのはページの数%だけです。したがって、差分バックアップは、圧縮前の完全バックアップよりもはるかに小さくなります。
完全バックアップ(毎週など)がある場合は、日次差分を実行してサイト外に発送できます。差分を含む毎日の完全バックアップでは、両方のファイルがオフサイトで必要になります。
これにより、AからB、C、Dにデータをすばやく取得するという問題が解決されます。
最新のデータを取得するには、完全と最新の差分の両方を復元する必要がありますが、NORECOVERYとSTANDBYファイルを使用してこれを回避できる場合があります(純粋なDBAを最後に使用して以来、私は何年もdiff復元で試していません)ジョブ)。
追加のボーナスは、差分バックアップが進行中のログバックアップとは無関係であるため、高可用性/ DR要件を「データをコードモンキーに取得する」要件から分離できることです。
ポリシーまたは監査による毎日の完全バックアップがある場合にいくつかの問題が発生しますが、ログ復元の前に差分復元を適用して、復旧時間を短縮できます。バックアップとは異なり、差分とログの復元は相互作用します。
ほとんどの拠点をカバーしたと思います...
ネイティブの2008圧縮よりも優れたバックアップの圧縮に役立つ商用製品があります。例は RedGateバックアップ 、 Hyperbac 、 Idera SQLバックアップ 、 Litespeedバックアップ です。
それらは、MSが出荷したもの以外のツールで処理する必要がある高いCPUとファイルタイプの追加コストを伴います。これは Hyperbac (現在Redgateが取得)圧縮を除いて、ファイルを透過的に処理し、Zip互換ファイルを作成することができます(サードパーティのツールも必要ありません)。
ただし、手動でクリーンアップすることで取得できるサイズのファイルを提供するツールはありません。ブレントオザーの記事をご覧ください: SQL Serverバックアップを実際に圧縮する方法 、彼はあなたが持っているのと同じ手順を実行することをアドバイスしますポイントなしで。 2。
質問1:データベースからインデックスなどの非必須データを削除するのと同様のバックアップサイズを提供する市販のバックアップ製品はありますか?
いいえ。バックアップ圧縮製品は数多くありますが(Quest LiteSpeed、Red Gate SQLバックアップ、Idera SQLSafe、Hyperbacなど)、SQL Serverの通常のバックアッププロセスの出力を圧縮するだけで機能します。それらのいくつかはトリッキーな方法でそれを行います-HyperBacとLiteSpeedのエンジンオプションはファイルシステムフィルタードライバーです。
質問2.この余分なデータをすべてダンプする包括的なスクリプトはありますか?
時間の経過とともに、データベースの履歴が増えるほど(4、5、8、10年)、すべてのインデックスデータを取り除き、WANの反対側で再構築する必要はなくなります。代わりに、変更されたデータを転送するだけで、ログ配布が行われます。
これを行うべきではありません。
しかし、本当にこれを実行したい場合(そして、いいえ、私はあなたを助けません)、ファイルグループのバックアップでそれを行うことができます。次のようにデータベースファイルグループを設定します。
最初の2つだけの圧縮ファイルグループバックアップを開始し、それらの小さいバックアップをDRサーバーにコピーします。 SQL Server 2008の ファイルグループのバックアップと復元機能 を使用して、プライマリファイルグループとClusteredIndexファイルグループを復元するだけで、すぐにクエリに使用できるようになります。それらは、ExtraneousCrapファイルグループをオンラインにするまで実際には機能しませんが、それについても厄介なトリックがあります- MVP Deep Divesの本 には、システムテーブルの編集に関する章がありますExtraneousCrapファイルグループと関連するすべてのインデックスを非表示にします。このトリックは危険であり、完全にサポートされておらず、ひどい考えです-しかし、あなたはそれを要求しました。
ログ配布などに切り替えることをお勧めします。基本的に、24時間で30ギグを送信するのか、より短い時間枠で1日の終わりに送信するのかを選択する場合、ネットワーク速度の問題は少なくなります。
低速ネットワーク上の開発者は、FTPまたは適切なプロセスを介して、より便利なサイズのファイルをダウンロードすることもできます。また、終日ダウンロードするジョブをセットアップすることもできます。
SQLサーバー圧縮に加えて、litespeedやredgate sqlbackupなどのより高い圧縮を持つサードパーティツールを実装することもできます。
さらに、ネットワーク側では、DRサイトへのスループットを最適化できるネットワークデバイスをインストールできます。以前は、Riverbed Applianceを使用してFLから90GBのバックアップを3時間以内にVAに正常に取得しました。
別のオプションは、インデックスなどを除いて、特定のファイルグループをバックアップすることですが、それでもクラスター化インデックスに悩まされており、db構造によっては、そのアプローチのメリットよりもコスト/手間がかかる場合があります。
ありがとう
あなたがそれのためのお金を持っていて、あなたのアーキテクチャがそれを可能にするなら、Riverbedテクノロジー(http://www.riverbed.com/us/)のようなものをチェックしてください。このようなアプライアンスをレプリケーションまたはログ配布のシナリオと組み合わせて使用するのが最善の方法です。
そうでない場合は、いくつかの質問。数か月ごとに更新を行う必要があるだけなのに、なぜ帯域幅に懸念があるのでしょうか。転送について心配する必要があるのは1回だけです。ローカルで復元を行うためにそこにフルバックアップを取得しますか、それともセットアップが間違っているのですか?
もう1つの可能性は、それらのデータをすべて取得することを心配する代わりに、Citrix環境をセットアップして、リモートでそれらを使用できるようにすることです。 Citrixを使用すると、クライアント/ホスト間の最小限の帯域幅要件があり、ローカルで必要なことを実行でき、他の場所にそれらの変更を複製する必要がないか心配する必要がありません。たったの0.02ドル
SQLトランザクションレプリケーションを使用します。最初の読み込みには少し時間がかかりますが、起動して実行すると、必要な情報のみを送信できます。たとえば、更新されるテーブルが3つまたは4つしかない場合、送信できるのは3つまたは4つのテーブルのみです。
発送したいものを選択することもできます。 FK、クラスター化/非クラスター化インデックス、テーブルパーティションスキーム、ストアドプロシージャ、およびTONSなど。
http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/
これがオプションでない場合は、REDGATE SQL BACKUP- http://www.red-gate.com/products/dba/sql-backup/ を使用できます。私は以前これを使用し、最大90%の圧縮レベルを得ました。 SQLよりもずっと小さい。