Skip to main content
NetApp Backup and Recovery

Discover Oracle Database workloads in NetApp Backup and Recovery

Contributors netapp-mwallis
PDFs

Discover Oracle Database workloads in NetApp Backup and Recovery so that you can protect them with backups and snapshots.

Required NetApp Console role
Backup and Recovery super admin. Learn about Backup and Recovery roles and privileges. Learn about NetApp Console access roles for all services.

Configure DNS for air-gapped host discovery in NetApp Console local deployment

If you are using NetApp Console local deployment in an air-gapped environment where database hosts are not reachable through standard DNS, you must temporarily modify the internal RKE2 CoreDNS configuration. This allows pods to resolve specific hostnames to IP addresses within the cluster, similar to adding entries to /etc/hosts on a node.

Important Before making changes, check the existing CoreDNS configuration to avoid overriding any existing customizations. Use RKE2 manifests to apply this change, ensuring it is managed consistently by the RKE2 operator and runtime.
Before you begin

  • Keep the HelmChartConfig file under change control where possible.

  • Use a clear filename so the purpose of the CoreDNS override is obvious.

  • If the expected DNS record is not visible in the Corefile, check the RKE2 server logs and confirm the manifest file syntax.

Steps

  1. Check the existing CoreDNS configuration to ensure that you are not overriding an existing change:

    kubectl -n kube-system get cm rke2-coredns-rke2-coredns -o jsonpath='{.data.Corefile}'

  2. Copy the following command block and edit the configBlock area to add your static DNS records. This creates a HelmChartConfig YAML file in the RKE2 manifests folder, which RKE2 automatically applies to override the CoreDNS configuration:

    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

  3. Verify that CoreDNS picked up the change:

    kubectl -n kube-system get cm rke2-coredns-rke2-coredns -o jsonpath='{.data.Corefile}'

    If the change is not visible after a few minutes, restart the CoreDNS deployment and then verify the Corefile again:

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

  4. If you need to remove the entries after you discover the database hosts, do the following:

    1. Delete the HelmChartConfig file from the manifests folder.

    2. Restart the CoreDNS deployment:

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

Add an Oracle Database host and discover resources

Add Oracle Database host information and let NetApp Backup and Recovery discover workloads. For each Console agent, select the systems to discover.

Steps

  1. From the NetApp Console menu, select Protection > Backup and Recovery.

  2. Under Workloads, select the Oracle tile.

  3. Select Discover resources.

  4. Select Oracle for the Workload type field.

  5. If you haven't yet stored credentials for this Oracle Database host, select Add credentials.

    1. Select the Console agent to use with this host.

    2. Enter a name for this credential.

    3. Enter the user name and password for the account.

    4. Select Done.

  6. Host registration: Add a new Oracle Database host. In the Host FQDN or IP address field, enter the host's FQDN or IP address. For clustered databases, you can enter the FQDN or IP address of any node in the cluster. Then provide credentials, the Console agent, and the port number.

  7. (Optional) If you choose credentials for a non-root user, do the following:

    1. For instructions on adding the selected non-root user to the sudoers file on the Oracle Database host, select Configure sudoers.

    2. Follow the instructions in the dialog, enable the checkbox when complete, and select Done.

  8. Advanced settings: Do the following:

    1. Enter the port and installation path to use for the NetApp plug-in. The plug-in enables communication between the Oracle Database host and NetApp Backup and Recovery.

    2. Choose whether to allow NetApp Backup and Recovery to install the plug-in automatically on each host or skip the automatic plug-in installation for all hosts. Select Show me how for manual installation instructions.

      Note

      NetApp Backup and Recovery connects to each host via SSH to install the plug-in automatically. Enable Use manual installation when any of the following apply:

      • One or more hosts are not running the SSH service.

      • Any host already has the NetApp plug-in (including if only some cluster members do).

      • You prefer to install the plug-in on each host manually.

    3. If the database host is clustered, enable the Add all hosts in the cluster option to discover all hosts in the cluster.

    4. Choose whether to run pre-installation checks on each host before automatically installing the plug-in. If checks fail, automatic plug-in installation stops. To bypass the checks and install anyway, enable Skip optional preinstall checks (enabled automatically if you choose manual installation).

  9. Select Discover.

    Tip Adding resources can take several minutes. To see the progress, select Track progress in the status dialog at the bottom of the Inventory page or select Monitoring from the left navigation.
Result

The Oracle Database workload appears in the workload list on the Inventory page.

Continue to the NetApp Backup and Recovery Dashboard

  1. From the NetApp Console menu, select Protection > Backup and Recovery.

  2. Select a workload tile (for example, Oracle Database).

  3. From the Backup and Recovery menu, select Dashboard.

  4. Review the health of data protection. The number of at-risk or protected workloads increases based on the newly discovered, protected, and backed up workloads.