日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

NetApp Backup and RecoveryでMicrosoft SQL Serverワークロードを検出します

09/02/2026 共同作成者

NetApp Backup and Recovery で Microsoft SQL Server ワークロードを検出し、保護およびリストアを実行できます。すでに SnapCenter を使用している場合は、既存のバックアップデータとポリシーをインポートすることもできます。

必須 NetApp コンソールロール バックアップおよびリカバリのスーパー管理者。Cloud Volumes ONTAP クラスターに保存されているデータを保護する場合は、Cloud Volumes ONTAP 管理者ロールも必要です。"バックアップとリカバリの役割と権限" について学ぶ。 "すべてのサービスに対するNetApp Consoleのアクセスロールについて学習します"。

NetApp Console ローカル展開におけるエアギャップホスト検出のための DNS の設定

NetApp Console のローカル展開をエアギャップ環境で使用していて、標準の DNS を介してデータベースホストに到達できない場合は、RKE2 CoreDNS の内部構成を一時的に変更する必要があります。これにより、ポッドはクラスター内の特定のホスト名を IP アドレスに解決できるようになります。これは、ノード上の `/etc/hosts`にエントリを追加するのと同様です。

変更を加える前に、既存のカスタマイズ設定を上書きしないよう、既存の CoreDNS 設定と既存の rke2-coredns-config.yaml HelmChartConfig の両方を確認してください。ほとんどの NetApp Console ローカルデプロイメントノードでは、このファイルはすでに存在し、リソースリクエストもすでに含まれています。ファイルがすでに存在する場合は、再作成せず、代わりに servers: ブロックのみを既存の valuesContent に追記してください。RKE2 マニフェストを使用してこの変更を適用することで、RKE2 オペレーターとランタイムによって継続的かつ一貫して管理されます。

開始する前に

可能な限り、HelmChartConfig ファイルを変更管理下に置いてください。
CoreDNSの上書きの目的が明確になるように、分かりやすいファイル名を使用してください。
想定される DNS レコードが Corefile に表示されない場合は、RKE2 サーバーのログを確認し、マニフェストファイルの構文を確認してください。

手順

既存の CoreDNS 設定を確認して、既存の変更を上書きしていないことを確認してください：
```
kubectl -n kube-system get cm rke2-coredns-rke2-coredns -o jsonpath='{.data.Corefile}'
```

HelmChartConfig ファイルが存在することを確認します：

sudo cat /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml

ファイルが存在する場合

次のスクリプトを実行して、 `servers:`ブロックを既存のHelmChartConfigファイルに追加します：

MANIFEST=/var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml

# 1. Back up first
sudo cp -a "$MANIFEST" "$MANIFEST.bak.$(date +%Y%m%d-%H%M%S)"

# 2. Safety checks: valuesContent must be the last key, no servers: block yet
grep -n 'servers:' "$MANIFEST"        # must return nothing
tail -c 1 "$MANIFEST" | od -c | head  # file must end with a newline

# 3. Append ONLY the servers block (nothing above it changes)
sudo tee -a "$MANIFEST" >/dev/null <<'YAML'
    servers:
    - zones:
      - zone: .
      port: 53
      plugins:
      - name: errors
      - name: health
        configBlock: |-
          lameduck 10s
      - name: ready
      - name: kubernetes
        parameters: cluster.local in-addr.arpa ip6.arpa
        configBlock: |-
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
          ttl 30
      # ───────────────────────── EDIT BELOW ─────────────────────────
      # Static DNS records for hosts the corporate DNS cannot resolve.
      # Format:  <IP>  <FQDN>  [optional aliases...]
      # `fallthrough` MUST stay as the last line -- it lets every other
      # name go to the upstream resolver via the `forward` plugin below.
      - name: hosts
        configBlock: |-
          1.2.3.4 example.domain.com exampleshortname
          fallthrough
      # ───────────────────────── EDIT ABOVE ─────────────────────────
      - name: prometheus
        parameters: 0.0.0.0:9153
      - name: forward
        parameters: . /etc/resolv.conf
      - name: cache
        parameters: 30
      - name: loop
      - name: reload
      - name: loadbalance
YAML

# 4. Confirm the merged result
sudo cat "$MANIFEST"

HelmChartConfigファイルへの唯一の変更が `servers:`ブロックの追加であることを確認します。

ファイルが存在しない場合

以下のスクリプトの `configBlock`エリアを編集して、静的DNSレコードを追加してください。これにより、RKE2のマニフェストフォルダにHelmChartConfigのYAMLファイルが作成され、RKE2はこれを自動的に適用してCoreDNSの設定を上書きします。

sudo tee /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml >/dev/null <<'YAML'
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: rke2-coredns
  namespace: kube-system
spec:
  # NOTE: This is a HelmChartConfig that *overlays* values onto the rke2-coredns
  # HelmChart already managed by RKE2. RKE2 watches /var/lib/rancher/rke2/server/manifests
  # and will re-render the rke2-coredns Helm release whenever this file changes.
  #
  # The `servers:` list below REPLACES the chart's default server definition,
  # so every plugin that was in the stock Corefile must be present here.
  # Do NOT delete plugins you don't recognize -- they are required for cluster DNS.
  valuesContent: |-
    servers:
    - zones:
      - zone: .
      port: 53
      plugins:
      - name: errors
      - name: health
        configBlock: |-
          lameduck 10s
      - name: ready
      - name: kubernetes
        parameters: cluster.local in-addr.arpa ip6.arpa
        configBlock: |-
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
          ttl 30
      # ───────────────────────── EDIT BELOW ─────────────────────────
      # Static DNS records for hosts the corporate DNS cannot resolve.
      # Format:  <IP>  <FQDN>  [optional aliases...]
      # `fallthrough` MUST stay as the last line -- it lets every other
      # name go to the upstream resolver via the `forward` plugin below.
      - name: hosts
        configBlock: |-
          1.2.3.4 example.domain.com exampleshortname
          fallthrough
      # ───────────────────────── EDIT ABOVE ─────────────────────────
      - name: prometheus
        parameters: 0.0.0.0:9153
      - name: forward
        parameters: . /etc/resolv.conf
      - name: cache
        parameters: 30
      - name: loop
      - name: reload
      - name: loadbalance
YAML
sudo chmod 600 /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml

スクリプトをコピーして実行してください。

CoreDNS が変更を認識したことを確認します。
```
kubectl -n kube-system get cm rke2-coredns-rke2-coredns -o jsonpath='{.data.Corefile}'
```
数分経っても変更が反映されない場合は、CoreDNS のデプロイメントを再起動し、Corefile を再度確認してください：
```
kubectl -n kube-system rollout restart deploy/rke2-coredns-rke2-coredns
```
データベースホストを検出した後にエントリを削除する必要がある場合は、次の手順を実行してください。
既存のファイルに追記した場合
バックアップしたファイルを復元するか、ファイル内から `servers:`ブロックのみを削除します：

sudo cp -a /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml.bak.<timestamp> \ /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml

このファイルには既存のRKE2リソースチューニング情報が含まれているため、削除しないでください。

ファイルを復元した後、ホストエントリを削除してください。古いエントリは、ホストの検出やスケジュールされたバックアップに問題を引き起こす可能性があります。

CoreDNS のデプロイメントを再起動します。

kubectl -n kube-system rollout restart deploy/rke2-coredns-rke2-coredns
新しいファイルを作成した場合
マニフェストフォルダから HelmChartConfig ファイルを削除します：

sudo rm /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml

ファイルを削除した後、ホストエントリを削除してください。古いエントリは、ホストの検出やスケジュールされたバックアップに問題を引き起こす可能性があります。

CoreDNS のデプロイメントを再起動します。

kubectl -n kube-system rollout restart deploy/rke2-coredns-rke2-coredns

Microsoft SQL Server ワークロードを検出し、オプションでSnapCenterリソースをインポートします

検出の過程で、NetApp Backup and Recovery は、組織内のシステム全体にわたる Microsoft SQL Server インスタンスとデータベースを分析します。

このサービスは、現在のバックアップポリシー、スナップショット、バックアップおよびリカバリオプションなど、既存の保護レベルを評価します。

検出は次のように行われます。

SnapCenterがすでにある場合は、 NetApp Backup and Recovery UI を使用してSnapCenterリソースをNetApp Backup and Recoveryにインポートします。

すでにSnapCenterをお使いの場合は、SnapCenterからインポートする前に、前提条件を満たしていることを確認してください。たとえば、SnapCenterからインポートする前に、オンプレミスのSnapCenterクラスタストレージシステムをNetApp Consoleに追加しておく必要があります。"SnapCenterからリソースをインポートするための前提条件"を参照してください。

まだ SnapCenter をお持ちでない場合でも、vCenter を手動で追加してワークロードを検出することができます。

SnapCenterがすでにインストールされている場合は、 SnapCenterリソースをNetApp Backup and Recoveryにインポートします。

SnapCenterがすでにインストールされている場合は、次の手順に従ってSnapCenterリソースをNetApp Backup and Recoveryにインポートします。 NetApp Consoleは、 SnapCenterからリソース、ホスト、資格情報、スケジュールを検出するため、すべての情報を再作成する必要はありません。

これは次の方法で実行できます。

検出中に、 SnapCenterからリソースをインポートするオプションを選択します。
検出後、インベントリページからSnapCenterリソースをインポートするオプションを選択します。
検出後、[設定] メニューからSnapCenterリソースをインポートするオプションを選択します。詳細については、"NetApp Backup and Recoveryを構成する" 。

これは 2 つの部分から成るプロセスです。

SnapCenter Server アプリケーションとホストリソースをインポートする
選択したSnapCenterホストリソースを管理する

SnapCenter Server アプリケーションとホストリソースをインポートする

この最初のステップでは、 SnapCenterからホストリソースをインポートし、それらのリソースをNetApp Backup and Recoveryインベントリページに表示されます。その時点では、リソースはまだNetApp Backup and Recoveryによって管理されていません。

SnapCenterホストリソースをインポートした後、 NetApp Backup and Recovery は保護管理を自動的に引き継ぎません。そのためには、 NetApp Backup and Recoveryでインポートされたリソースを管理することを明示的に選択する必要があります。これにより、 NetApp Backup and Recoveryによってそれらのリソースをバックアップする準備が整います。

手順

NetApp Consoleの左側のナビゲーションから、保護 > バックアップとリカバリ を選択します。
*在庫*を選択します。
*リソースの検出*を選択します。
NetApp Backup and Recovery のワークロードリソースの検出ページで、* SnapCenterからのインポート*を選択します。
* SnapCenterアプリケーションの資格情報*を入力してください:
1. * SnapCenter FQDN または IP アドレス*: SnapCenterアプリケーション自体の FQDN または IP アドレスを入力します。
2. ポート: SnapCenterサーバーのポート番号を入力します。
3. ユーザー名 と パスワード: SnapCenterサーバーのユーザー名とパスワードを入力します。
4. コンソールエージェント: SnapCenterのコンソールエージェントを選択します。
* SnapCenterサーバーホストの資格情報* を入力してください:
1. 既存の資格情報: このオプションを選択すると、すでに追加されている既存の資格情報を使用できます。資格情報の名前を選択します。
2. 新しい資格情報の追加: 既存のSnapCenterホスト資格情報がない場合は、新しい資格情報を追加できます。資格情報名、認証モード、ユーザー名、およびパスワードを入力します。
インポート を選択してエントリを検証し、 SnapCenterサーバーを登録します。

SnapCenter Server がすでに登録されている場合は、既存の登録情報を更新できます。

結果

インベントリページには、インポートされた SnapCenter リソース（Microsoft SQL Server のホスト、インスタンス、およびデータベースを含む）が表示されます。

インポートされたSnapCenterリソースの詳細を表示するには、[アクション] メニューから [詳細の表示] オプションを選択します。

SnapCenterホストリソースの管理

SnapCenter リソースをインポートした後、NetApp Backup and Recovery でホストリソースを管理します。管理することを選択すると、NetApp Backup and Recovery を使用して、インポートしたリソースをバックアップおよびリカバリできます。これらのリソースは、SnapCenter Server では管理されなくなります。

手順

SnapCenterリソースをインポートした後、[バックアップとリカバリ] メニューから [インベントリ] を選択します。
「インベントリ」ページから、NetApp Backup and Recoveryで管理する、インポートされたSnapCenterホストを選択します。
アクションアイコンを選択します> 詳細を表示 をクリックして、ワークロードの詳細を表示します。
インベントリ > ワークロードページから、アクションアイコンを選択します> 管理をクリックして、ホストの管理ページを表示します。
*管理*を選択します。
[ホストの管理] ページで、既存の vCenter を使用するか、新しい vCenter を追加するかを選択します。
*管理*を選択します。

インベントリページには、新しく管理されたSnapCenterリソースが表示されます。

オプションで、[アクション] メニューから [レポートの生成] オプションを選択して、管理対象リソースのレポートを作成することもできます。

インベントリページから検出後にSnapCenterリソースをインポートする

すでにリソースを検出している場合は、インベントリページからSnapCenterリソースをインポートできます。

手順

コンソールの左側のナビゲーションから、保護 > *バックアップとリカバリ*を選択します。
*在庫*を選択します。
インベントリページで、* SnapCenterリソースのインポート*を選択します。
SnapCenterリソースをインポートするには、上記の * SnapCenterリソースのインポート* セクションの手順に従います。

SnapCenterがインストールされていない場合は、vCenterを追加してリソースを検出します。

まだSnapCenterをインストールしていない場合は、vCenter情報を追加して、NetApp Backup and Recoveryでワークロードを検出できます。各コンソールエージェント内で、ワークロードを検出するシステムを選択します。

VMware環境をご利用の場合は、この手順は省略可能です。

手順

コンソールの左側のナビゲーションから、保護 > *バックアップとリカバリ*を選択します。

初めて Backup and Recovery にログインし、コンソールにシステムがあるがリソースが検出されていない場合は、[新しいNetApp Backup and Recovery へようこそ] ページが表示され、[リソースの検出] オプションが表示されます。
*リソースの検出*を選択します。

次の情報を入力してください。

ワークロードタイプ: このバージョンでは、Microsoft SQL Server のみが利用可能です。

vCenter 設定: 既存の vCenter を選択するか、新しい vCenter を追加します。新しい vCenter を追加するには、vCenter FQDN または IP アドレス、ユーザー名、パスワード、ポート、プロトコルを入力します。

vCenter 情報を入力する場合は、vCenter 設定とホスト登録の両方の情報を入力してください。ここで vCenter 情報を追加または入力した場合は、次に詳細設定でプラグイン情報も追加する必要があります。

ホスト登録: 資格情報の追加 を選択し、検出するワークロードを含むホストに関する情報を入力します。

vCenter サーバーではなくスタンドアロンサーバーを追加する場合は、ホスト情報のみを入力します。

*Discover*を選択します。

このプロセスには数分かかる場合があります。
詳細設定に進みます。

検出中に詳細設定オプションを設定し、プラグインをインストールする

詳細設定では、登録されているすべてのサーバーにプラグインエージェントを手動でインストールできます。これにより、すべての SnapCenter ワークロードを NetApp Backup and Recovery にインポートし、バックアップと復元を管理できます。NetApp Backup and Recovery には、プラグインのインストールに必要な手順が表示されます。

手順

「リソースを探す」ページから、右側の下向き矢印を選択して「詳細設定」に進みます。
「ワークロードリソースの検出」ページで、次の情報を入力します。
- プラグインポート番号を入力：プラグインが使用するポート番号を入力してください。
- インストールパス：プラグインをインストールするパスを入力してください。
SnapCenter エージェントを手動でインストールする場合は、次のオプションを選択してください。
- 手動インストールを使用する：このオプションを選択して、プラグインを手動でインストールします。
- クラスタ内のすべてのホストを追加：このオプションを選択すると、検出時にクラスタ内のすべてのホストが NetApp Backup and Recovery に追加されます。
- オプションの事前インストールチェックをスキップ：このオプションを選択すると、オプションの事前インストールチェックがスキップされます。たとえば、メモリやスペースに関する考慮事項が近い将来変更されることがわかっており、今すぐプラグインをインストールしたい場合などに、このオプションを使用することができます。
*Discover*を選択します。

NetApp Backup and Recoveryダッシュボードに進みます

NetApp Console メニューから、Protection > Backup and Recovery を選択します。
ワークロードタイル (Microsoft SQL Server など) を選択します。
「バックアップとリカバリ」メニューから、「ダッシュボード」を選択します。
データ保護の健全性を確認します。新たに検出、保護、バックアップされたワークロードに基づいて、リスクにさらされているワークロードまたは保護されているワークロードの数が増加します。

"ダッシュボードに表示される内容を学ぶ"。

NetApp Backup and RecoveryでMicrosoft SQL Serverワークロードを検出します

Creating your file...

NetApp Console ローカル展開におけるエアギャップホスト検出のための DNS の設定

Microsoft SQL Server ワークロードを検出し、オプションでSnapCenterリソースをインポートします

SnapCenterがすでにインストールされている場合は、 SnapCenterリソースをNetApp Backup and Recoveryにインポートします。

SnapCenter Server アプリケーションとホスト リソースをインポートする

SnapCenterホストリソースの管理

インベントリページから検出後にSnapCenterリソースをインポートする

SnapCenterがインストールされていない場合は、vCenterを追加してリソースを検出します。

検出中に詳細設定オプションを設定し、プラグインをインストールする

NetApp Backup and Recoveryダッシュボードに進みます

SnapCenter Server アプリケーションとホストリソースをインポートする