Azure Backup for Windows Serverは、同じサーバー上の通常のSQL Serverバックアップに影響しますか？
SQL Server 2016可用性グループノードが実行されているフェールオーバークラスターノードとして構成された仮想化Windows Server 2019インスタンスがあります。通常の完全/差分/ログバックアップスケジュールで「従来の」SQLサーバーバックアップをすでに設定しています。
現在、ランサムウェア攻撃の可能性からさらに保護するために、Azure Backupを使用してWindows Serverインスタンス全体をバックアップできるかどうか疑問に思っています（ドキュメント here を参照）。
通常のバックアップ戦略に取って代わるのではなく、既存の設定を壊すことなくバックアップ方法を追加します。これはWindows Server向けAzure Backupで機能しますか、それとも現在のバックアップ戦略に影響しますか？
編集：最初にこの質問をした理由を明確にするために：両方のバックアップ方法でVSSを使用している可能性があるため、Azure Backupをセットアップすると既存の完全/差分/ログバックアップチェーンが壊れるかどうかを知りたいです。
質問でリンクした投稿に従って明確にしたかったのですが、「をランサムウェア攻撃の可能性からさらに保護することを求めています "具体的には、 。 。
本質的にAzure Backupは、使用したい3つのレベルのバックアップテクノロジを提供します。 。 。
- ファイルとフォルダー
- システム状態
- フルボリュームのポイントインタイムおよびイメージバックアップ
- ベアメタル（オンプレミス）
- VMレベルのバックアップ（OSおよびその他のボリューム）
他の種類の Azureバックアップ エージェントを追加して、SQL Serverバックアップを処理することができますが、既存のSQL Serverバックアップ戦略や既存のSQL Serverバックアップのバックアップログチェーンに影響を与えたくないので、そのエージェントは使用しないでください。
- SQL Server固有のAzure Backupエージェントまたは機能を使用しないでください
完全なシステム回復と関連する復元操作に関しては、何かが必要な場合（これは全体です）開始するバックアップの目的、Azure Backupレベルのバックアップをバックアップと復元の戦略に追加すると、保護が強化され、このような場合にシステムを迅速にバックアップして実行できるようになりますアクションが必要です。
システムを適切なタイミングで復旧させて完全に機能させることが重要である場合は、Azureバックアップ戦略を追加すると、システムの運用/可用性/復元力をより適切に保護できます。
今日のSQL Serverバックアップだけで、システム全体がクラッシュし、リカバリが必要な場合は、Windows Serverをインストールする必要があります、SQL Serverをインストールして構成し、SQLバックアップファイルとトランザクションログをバックアップメディアからコピーして、SQL Serverデータベースレベルのものの復元を開始します。
完全なシステム回復の観点からバックアップ戦略を考えてください。システムを復旧して実行するために必要なデータについて考え、そこから出発点として使用します。
Azure Backup Recoveryの理解
何らかの準備ができたら、Azureバックアップのデータとテクノロジーを将来参照できるように、復元/回復プロセスをテストして文書化します。既存のSQLバックアップジョブを中断することなく動作を確認することが重要であるため、この重要なステップを見落とさないでください。
Azure Backup for Windows Serverは、同じサーバー上の通常のSQL Serverバックアップに影響しますか？
明らかに、AzureバックアップジョブとSQL Serverバックアップジョブの両方が同時に実行されている場合、SQLデータベースの通常のバックアップジョブに影響を与える可能性があります。同じWindowsオペレーティングシステムのCPU、メモリ、ディスクリソースを共有する必要があるため、このレベルで互いに影響し合う可能性があります。
同じOSの共有リソースを同時に使用すると、SQL Serverデータベースのバックアップジョブの完了に時間がかかる場合があります。あなたがそれをやるまで、あなたは特定の詳細を知りません。現在の復元戦略では、バックアップジョブが中断し、実行する必要のあるアクションがわかっている場合に、バックアップジョブを簡単に同期させることが重要です。
SQL Serverデータベースのバックアップチェーンを切断するという観点から、SQL Serverデータベース固有のジョブタイプを実行していて、トランザクションログが失われたり変更されたりする場合を除きます- SQL Serverデータベース復旧モデル Azureバックアップテクノロジーを使用する場合、SQL Serverデータベースログバックアップチェーンに影響を与えることはありません。
私は SQL Server High Availability の経験はあまりありませんが、ログシッピングなどのプライマリDBからトランザクションを適用するデータベースがスタンバイ状態にある場合、チェーンが非常に重要であり、プライマリデータベースの最新のログバックアップからトランザクションをコミットできないため、ログ配布プロセスも壊れます。
安全オプション（懸念事項と要件ごと）
Azure Backup がSQL Serverデータベースのバックアップ操作を実行せず、SQL Server固有の操作に使用しないか、選択しない場合は、問題ありません。
Azure Backupを使用してファイルとフォルダー、、VM全体、システム状態、またはベアメタルリカバリ、SQL Serverデータベースのバックアップでログチェーンが壊れることはありません。
サポートリソース
システム状態をバックアップし、Azureバックアップサーバーでベアメタルに復元
システム状態のバックアップ：オペレーティングシステムファイルをバックアップするため、コンピューターの起動時に回復できますが、システムファイルとレジストリは失われます。システム状態のバックアップには、次のものが含まれます。
- ドメインメンバー：ブートファイル、COM +クラス登録データベース、レジストリ
- ドメインコントローラー：Windows Server Active Directory（NTDS）、ブートファイル、COM +クラス登録データベース、レジストリ、システムボリューム（SYSVOL）
- クラスターサービスを実行するコンピューター：クラスターサーバーのメタデータ
- 証明書サービスを実行するコンピューター：証明書データ
ベアメタルバックアップ：オペレーティングシステムファイルと重要なボリューム上のすべてのデータ（ユーザーデータを除く）をバックアップします。定義により、BMRバックアップにはシステム状態のバックアップが含まれます。コンピュータが起動せず、すべてを回復する必要がある場合に保護を提供します
あなたの主な心配は、2つの異なるバックアップセットを生成するために両方が同時に Shadow Copy を使用する2つのバックアップジョブが何らかの方法で競合し、どちらか一方または両方に障害が発生するかどうかです。
答えは、そのような対立は起こり得ないということです。
Microsoftの記事 プロバイダーのシャドウコピーの作成 には、あなたの質問に答える次のような引用があります。
元のボリュームのシャドウコピーセットの数またはシャドウコピーセットの数に制限はありません。
「シャドウコピーセット」という用語をよりよく理解するには、記事 シャドウコピーとシャドウコピーセット から：
シャドウコピーセットは、さまざまなボリュームのシャドウコピーのコレクションであり、すべて同時に作成されます。 VSSは、永続的なGUIDによって各シャドウコピーセットを識別します。
「シャドウコピーセット」は、1つ以上のディスクボリュームと、シャドウコピー操作に含まれるその他のソースのスナップショットです。これには、この操作に参加できる容量がある限り、ハードディスクだけではないプロバイダーも含まれます。
上記から、各シャドウスナップショットはスタンドアロンであり、他のそのような操作と競合しないことは明らかです。それぞれに独自の [〜＃〜] guid [〜＃〜] があり、これによりWindowsは安全かつ明確にそれらすべてを並行して処理できるため、すべてのバックアップが一貫して正しくなります。