Skip to main content
NetApp Backup and Recovery

Discover Microsoft SQL Server workloads in NetApp Backup and Recovery

Contributors netapp-mwallis

Discover Microsoft SQL Server workloads in NetApp Backup and Recovery so that you can protect and restore them. If you already use SnapCenter, you can also import existing backup data and policies.

Required NetApp Console role
Backup and Recovery super admin. If you are protecting data stored on a Cloud Volumes ONTAP cluster, the Cloud Volumes ONTAP Admin role is also required. 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 need to temporarily modify the internal RKE2 CoreDNS configuration. This enables 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 both the existing CoreDNS configuration and the existing rke2-coredns-config.yaml HelmChartConfig to avoid overriding any existing customizations. On most NetApp Console local deployment nodes, this file already exists and already contains resource requests. If the file already exists, do not recreate it; instead, append only the servers: block to the existing valuesContent. Apply this change using RKE2 manifests so that it continues to be 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. Verify that the HelmChartConfig file exists:

    sudo cat /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml
    If the file exists
    1. Run the following script to append the servers: block to the existing HelmChartConfig file:

      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"
    2. Verify that the only change to the HelmChartConfig file is the addition of the servers: block.

    If the file does not exist
    1. Edit the configBlock area of the following script and 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
    2. Copy and run the script.

  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:

    If you appended to an existing file
    1. Restore the backed up file or delete only the servers: block from within the file:

      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

      Do not delete the file, because it contains the existing RKE2 resource tuning.

    2. After restoring the file, remove the host entries. Stale entries can cause host discovery and scheduled backup issues.

    3. Restart the CoreDNS deployment:

      kubectl -n kube-system rollout restart deploy/rke2-coredns-rke2-coredns
    If you created a new file
    1. Delete the HelmChartConfig file from the manifests folder:

      sudo rm /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml
    2. After deleting the file, remove the host entries. Stale entries can cause host discovery and scheduled backup issues.

    3. Restart the CoreDNS deployment:

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

Discover Microsoft SQL Server workloads and optionally import SnapCenter resources

During discovery, NetApp Backup and Recovery analyzes Microsoft SQL Server instances and databases across systems in your organization.

The service assesses existing protection levels, including current backup policies, snapshots, and backup and recovery options.

Discovery occurs in the following ways:

  • If you already have SnapCenter, import SnapCenter resources into NetApp Backup and Recovery by using the NetApp Backup and Recovery UI.

    Note If you already have SnapCenter, first check to be sure you've met the prerequisites before importing from SnapCenter. For example, you should add on-premises SnapCenter cluster storage systems to NetApp Console before importing from SnapCenter. See Prerequisites for importing resources from SnapCenter.
  • If you don't already have SnapCenter, you can still discover workloads by adding a vCenter manually and perform discovery.

If SnapCenter is already installed, import SnapCenter resources into NetApp Backup and Recovery

If you already have SnapCenter installed, import SnapCenter resources into NetApp Backup and Recovery using these steps. NetApp Console discovers resources, hosts, credentials, and schedules from SnapCenter; you don't have to recreate all that information.

You can do this in the following ways:

  • During discovery, select an option to import resources from SnapCenter.

  • After discovery, from the Inventory page, select an option to import SnapCenter resources.

  • After discovery, from the Settings menu, select an option to import SnapCenter resources. For details, see Configure NetApp Backup and Recovery.

This is a two-part process:

  • Import SnapCenter Server application and host resources

  • Manage selected SnapCenter host resources

Import SnapCenter Server application and host resources

This first step imports host resources from SnapCenter and displays those resources in the NetApp Backup and Recovery Inventory page. At that point, the resources are not yet managed by NetApp Backup and Recovery.

Tip After you import SnapCenter host resources, NetApp Backup and Recovery does not take over protection management automatically. To do so, you must explicitly select to manage the imported resources in NetApp Backup and Recovery. This ensures that you are ready to have those resources backed up by NetApp Backup and Recovery.
Steps
  1. From the NetApp Console left navigation, select Protection > Backup and Recovery.

  2. Select Inventory.

  3. Select Discover resources.

  4. From the NetApp Backup and Recovery Discover workload resources page, select Import from SnapCenter.

  5. Enter SnapCenter application credentials:

    1. SnapCenter FQDN or IP address: Enter the FQDN or IP address of the SnapCenter application itself.

    2. Port: Enter the port number for the SnapCenter Server.

    3. Username and Password: Enter the username and password for the SnapCenter Server.

    4. Console agent: Select the Console agent for SnapCenter.

  6. Enter SnapCenter server host credentials:

    1. Existing credentials: If you select this option, you can use the existing credentials that you have already added. Choose the credentials name.

    2. Add new credentials: If you don't have existing SnapCenter host credentials, you can add new credentials. Enter the credentials name, authentication mode, user name, and password.

  7. Select Import to validate your entries and register the SnapCenter Server.

    Note If the SnapCenter Server is already registered, you can update the existing registration details.
Result

The Inventory page shows the imported SnapCenter resources that include Microsoft SQL Server hosts, instances, and databases.

To see the details of the imported SnapCenter resources, select the View details option from the Actions menu.

Manage SnapCenter host resources

After you import SnapCenter resources, manage the host resources in NetApp Backup and Recovery. After you choose to manage them, NetApp Backup and Recovery can back up and recover the imported resources. You no longer manage those resources in SnapCenter Server.

Steps
  1. After you import the SnapCenter resources, from the Backup and Recovery menu, select Inventory.

  2. From the Inventory page, select the imported SnapCenter host that you want NetApp Backup and Recovery to manage.

  3. Select the Actions icon Actions option > View details to display the workload details.

  4. From the Inventory > workload page, select the Actions icon Actions option > Manage to display the Manage host page.

  5. Select Manage.

  6. In the Manage host page, select either to use an existing vCenter or add a new vCenter.

  7. Select Manage.

    The Inventory page shows the newly managed SnapCenter resources.

You can optionally create a report of the managed resources by selecting the Generate reports option from the Actions menu.

Import SnapCenter resources after discovery from the Inventory page

If you have already discovered resources, you can import SnapCenter resources from the Inventory page.

Steps
  1. From the Console left navigation, select Protection > Backup and Recovery.

  2. Select Inventory.

  3. From the Inventory page, select Import SnapCenter resources.

  4. Follow the steps in the Import SnapCenter resources section above to import SnapCenter resources.

If you don't have SnapCenter installed, add a vCenter and discover resources

If you don't already have SnapCenter installed, you can add vCenter information and have NetApp Backup and Recovery discover workloads. Within each Console agent, select the systems where you want to discover workloads.

This step is optional if you have a VMware environment.

Steps
  1. From the Console left navigation, select Protection > Backup and Recovery.

    If you are logging in to Backup and Recovery for the first time and have a system in the Console but no discovered resources, the Welcome to the new NetApp Backup and Recovery page appears with an option to Discover resources.

  2. Select Discover resources.

  3. Enter the following information:

    1. Workload type: For this version, only Microsoft SQL Server is available.

    2. vCenter settings: Select an existing vCenter or add a new one. To add a new vCenter, enter the vCenter FQDN or IP address, user name, password, port, and protocol.

      Tip If you are entering vCenter information, enter information for both vCenter settings and Host registration. If you added or entered vCenter information here, you also need to add plug-in information in Advanced Settings next.
    3. Host registration: Select Add credentials and enter information about the hosts containing the workloads you want to discover.

      Tip If you are adding a standalone server and not a vCenter server, enter only the host information.
  4. Select Discover.

    Tip This process might take a few minutes.
  5. Continue with Advanced Settings.

Set Advanced settings options during discovery and install the plug-in

With Advanced Settings, you can manually install the plug-in agent on all servers being registered. This enables you to import all SnapCenter workloads into NetApp Backup and Recovery so you can manage backups and restores there. NetApp Backup and Recovery shows the steps needed to install the plug-in.

Steps
  1. From the Discover resources page, continue to Advanced Settings by selecting the down arrow on the right.

  2. In the Discover workload resources page, enter the following information.

    • Enter plug-in port number: Enter the port number that the plug-in uses.

    • Installation path: Enter the path where the plug-in will be installed.

  3. If you want to install the SnapCenter agent manually, select the following options:

    • Use manual installation: Select this option to install the plug-in manually.

    • Add all hosts in the cluster: Select this option to add all hosts in the cluster to NetApp Backup and Recovery during discovery.

    • Skip optional preinstall checks: Select this option to skip optional preinstall checks. You might want to do this, for example, if you know that memory or space considerations will be changed in the near future and you want to install the plug-in now.

  4. Select Discover.

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, Microsoft SQL Server).

  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.