少数のテーブルと大量の不変データを含む大規模なDBに最適なSQLサーバーバックアップ戦略は何ですか？
大容量のDB（500GB以上）があります。データの95％以上は3つのテーブルに保存されます（1つのテーブルには20億以上の行があります）。データはほとんど不変です。つまり、一度追加されると、後で読み取られます。古いデータはアーカイブできません。
圧縮バックアップを可能にするSQL Server 2017を使用していますが、それでもバックアップとバックアップサーバーへのネットワーク経由のコピーには長い時間がかかります。
このプロセスを高速化したい（そしてDRの目的でクラウドにバックアップを持っている-おそらくAzure）-差分バックアップは十分に小さいが、それでも定期的にフルバックアップ（たとえば、毎週フル）を実行する必要があると思う毎晩の差分はまだ問題です）
私の感覚では、パーティションを使用して、（ID IDでクラスター化された）いくつかの賢明な列で大きなテーブルを分割し、古いパーティションを一度だけバックアップして、読み取り専用としてマークすることができ、すべてを再度バックアップする必要はありません。
これは、今後もパーティションを追加し続ける必要があるため、理想的な状況ではありません。また、DBを数分以上停止することはできないため、パーティションを使用してデータのシャドウバージョンを作成し、いくつかの切り替えを行って、ダウンタイムを短縮する必要があると思います。これは少し危険で複雑です。
誰かがこの種類のDB構成のバックアップ戦略を持っている場合、彼らはよりうまく機能すると考えます（または、私が持っている制約を考えると、これは良いアイデアのように思えることを確認できます）。
追加情報：
現在のバックアップスケジュール：
完全バックアップ（毎晩）-圧縮バックアップは約100 GB（非圧縮500 GB）で、約40分（圧縮あり）
ログのバックアップ（10分ごと）-ほぼ瞬時に、それぞれ約20 MBのみ。
40分はそれほど長くなく、100 GBはそれほど大きなファイルではないこともありますが、95％以上のデータは不変であり、安全に1回だけバックアップできることもわかっています。 、バックアップcould数分もかからず、数ギガバイトになります（そしてそれは控えめです）。
私は partitioning がバックアップの管理に役立つツールの1つであり、特にこのタイプのシナリオであると信じています。これを実際に経験した人（またはSQLサーバーベースの代替案私のシナリオの場合）、何が機能するかについていくつかの光を当てます。
log shipping を確認すると、10分のログをサーバーに送信できるため、変更のみが更新されます。
ログ配布先もバックアップを保持する場所であると想定すると、そこでバックアップを実行できます。初期バックアップ以外の場合は、何年も実行でき、ログのみを出荷できます。
プライマリとログ配布先の両方で完全バックアップを取ることができます。そうすれば、両方の場所にバックアップがあり、毎日移動する唯一のデータは、発送されるログです。
あるいは、同じ効果を得るために、ログ配布の代わりに AlwaysOn を使用できます。
ライセンス：私はライセンスの専門家ではありませんが、ログ配布（またはAlwaysOn）宛先インスタンスがDRのみの場合、追加のコストは発生しないことを理解しています。
回答をお送りしますが、実際には、ご利用のインフラストラクチャに応じて異なります。
- 読み取り専用のデータとトランザクションデータを1つのデータベースに保持する理由おそらく、読み取り専用のデータは、別個のファイル/データベース/ディスク/サーバーのセットにある必要があります。 500 GBのデータファイルを常に継続的に読んでいるとは思いません。分離により、変更されたこの部分のみをバックアップできます。別のデータベースサーバーへのレプリケーションとしてバックアップすることができます
- データブーストプロトコルに関連してデータの重複排除を研究することができます。これは、バックアップ中に何か（ソフトウェアエージェント）が変更されたデータを比較し、変更された部分のみを移動することを意味します（差分バックアップの場合など）。違いは、重複排除されたストレージでは、このようなシステムはオフラインで構築される可能性があるということです合成完全バックアップ。従来の完全バックアップを実行するrdbmsが必要な場合でも、データの転送は単なる違いです。さまざまな要因に応じて、結果としてはるかに高速な完全バックアップを取得できます。
- さまざまなベンダーのスナップショットテクノロジーを研究できます。このようなソリューションのいくつかは、さまざまなデータベースrdbmsに対して一貫したスナップショットを実行できます。完全に認定されたソリューションである可能性があります。
最後に、パーティショニングオプションに行きました：
メインの「データ」テーブル（95％のデータ）を分割し、6か月前に「アーカイブ/読み取り専用」の線を描画しました。
副産物は、3次テーブル（5％データ）が独自のパーティションにあり、個別に復元できることでした（これらのメタデータの混乱に役立ちます）。
また、DRにログ配布を使用しますが、バックアップをセカンダリから取得できるようにするには追加のライセンスが必要なため、ローカルバックアップはそのまま残されます。
また、Microsoft Azure Backup Serverを試して、オフサイトのメリットを追加します。
最良の戦略は、RPO-復旧ポイント目標とRTO-復旧時間目標によってどれだけ速く復元する必要があるか、およびどれだけのデータを失うことができるかに依存します。
実際には、1つのテーブルが他のテーブルよりも頻繁にバックアップされるSLAが異なるファイルグループにデータベースを分割する場合があります。また、大規模なデータベース（数TBのデータベースもある）を使用している場合、データベース全体をバックアップすることはできません。バックアップ自体は、インフラストラクチャが対応できるよりも時間がかかるためです。バックアップすると、毎日のバックアップが失敗します。アップには1日以上かかります…
組織のすべてのデータベースとそれらのRTOおよびSLAを備えた制御サーバーを生成し、変更されたデータの量と最後に認識されたサーバーIOに基づいてバックアップを実行します_データ。
私たちがしていることは、指定されたサーバー上のSQLジョブに復元スクリプトをスクリプト化し、ジョブプールにトランザクションログと変更を測定させることです。バックアップを実行するときに（ローカルおよびリモートで）復元スクリプトを生成し、RTO/RPO/SLAに変更があるたびにサーバーを更新します。 wenが回復する必要がある場合（インプレースまたはホットスワップ/回復サーバー）、適切なバックアップを取得する回復スクリプトを実行します。特定の時点または単純な回復のために、完全、差分、トランザクションです。
他のアプローチでは、多くのデータベースが必要です。また、「手動で」行う場合は、財務上のリスクを高くする必要があります。 DBA 1とDBA 2は異なる方法で処理を行う可能性があります。また、セキュリティ更新またはそれより悪い場合に「すべての」サーバーに一貫して何かを実装するにはどうすればよいでしょうか。managemntの新しいアイデア…
私は...ずっと前に コンセプトを書いた これに対処しますが、パスを変更するときにも機能する可能性のあるスクリプトがいくつか含まれていますが、バックアップを保護するパスワードを想定しているため、削除する必要があるかもしれませんそれ以降のバージョンのSQLサーバーではサポートが廃止されました。
ドキュメントの最後に.SQLファイルとして埋め込まれたスクリプト。