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

NetApp Backup and RecoveryでOracle Databaseワークロードを検出

09/02/2026 共同作成者

PDF

NetApp Backup and Recovery で Oracle Database ワークロードを検出し、バックアップやスナップショットで保護できます。

必須 NetApp コンソールロール バックアップおよびリカバリのスーパー管理者。"バックアップとリカバリの役割と権限" について学ぶ。 "すべてのサービスに対する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

Oracle Databaseホストを追加してリソースを検出する

Oracle Database ホスト情報を追加して、NetApp Backup and Recovery がワークロードを検出できるようにします。各コンソールエージェントについて、検出するシステムを選択します。

手順

NetApp Console メニューから、Protection > Backup and Recovery を選択します。
*ワークロード*の下で、*Oracle*タイルを選択します。
*リソースの検出*を選択します。
ワークロードタイプ フィールドで Oracle を選択します。
この Oracle Database ホストの資格情報をまだ保存していない場合は、*資格情報の追加*を選択します。
1. このホストで使用するコンソールエージェントを選択します。
2. この資格情報の名前を入力します。
3. アカウントのユーザー名とパスワードを入力します。
4. *完了*を選択します。
ホスト登録：新しい Oracle データベースホストを追加します。*ホストの FQDN または IP アドレス*フィールドに、ホストの FQDN または IP アドレスを入力します。クラスタ化されたデータベースの場合、クラスタ内の任意のノードの FQDN または IP アドレスを入力できます。次に、認証情報、Console エージェント、およびポート番号を入力します。
（オプション）非ルートユーザーの資格情報を選択する場合は、次の手順を実行します：
1. Oracle Databaseホスト上のsudoersファイルに選択した非rootユーザーを追加する手順については、*sudoersの設定*を選択してください。
2. ダイアログの指示に従い、完了したらチェックボックスを有効にして、Done を選択します。

詳細設定：次の操作を行います。

使用するポートとインストールパスを入力しますNetAppプラグイン。このプラグインは、Oracle Database ホストとNetApp Backup and Recovery 間の通信を可能にします。

NetApp Backup and Recoveryで各ホストにプラグインを自動的にインストールするか、すべてのホストで自動プラグインインストールをスキップするかを選択します。手動インストール手順については、*手順を表示*を選択してください。

NetApp Backup and Recovery は、SSH を介して各ホストに接続し、プラグインを自動的にインストールします。以下のいずれかに該当する場合は、手動インストールを使用する を有効にしてください。

1つ以上のホストでSSHサービスが実行されていません。
どのホストにも既にNetAppプラグインがインストールされている（一部のクラスタメンバーのみにインストールされている場合を含む）。
各ホストにプラグインを手動でインストールすることを希望します。

データベースホストがクラスタ化されている場合は、*クラスタ内のすべてのホストを追加*オプションを有効にして、クラスタ内のすべてのホストを検出します。
プラグインを自動的にインストールする前に、各ホストでインストール前のチェックを実行するかどうかを選択します。チェックが失敗した場合、プラグインの自動インストールが停止します。チェックをバイパスしてインストールするには、*Skip optional preinstall checks*を有効にします（手動インストールを選択した場合は自動的に有効になります）。

*Discover*を選択します。

リソースの追加には数分かかる場合があります。進捗状況を確認するには、インベントリページ下部のステータスダイアログで「Track progress」を選択するか、左側のナビゲーションから「Monitoring」を選択してください。

結果

Oracle Databaseワークロードは、インベントリページのワークロード一覧に表示されます。

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

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

NetApp Backup and RecoveryでOracle Databaseワークロードを検出

Creating your file...

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

Oracle Databaseホストを追加してリソースを検出する

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