Skip to main content
Version: v2.0

SQL Server Backup in Kubernetes Using NFS Volumes

This guide explains how to create backups of a SQL Server Availability Group using the DxSqlAg custom resource. The recommended method is to attach a volume backed by NFS to the SQL Server container and direct SQL Server backups to write data to this mounted volume.

Overview​

SQL Server can write backups to any filesystem path available inside the container. In Kubernetes, you expose that path via a volumeMount backed by an NFS share.

DH2i recommends mounting the NFS export at:

  • /var/opt/mssql/backup (the standard backup directory for SQL Server on Linux)

Prerequisites​

  • A working Kubernetes cluster (Minikube, AKS, EKS, GKE, etc.).
  • DxOperator installed and running (Create a SQL Server Availability Group in Kubernetes).
  • An accessible NFS server exporting a directory for backups.
  • Network connectivity from each Kubernetes node to the NFS server (TCP 2049 at minimum).
caution

Due to NFS limitations with Minikube's WSL2 driver, DH2i recommends running Minikube in PowerShell for testing NFS mounts.

minikube start --driver=hyperv --memory=16000 --cpus=2

Configure the NFS Server for the Custom Resource​

Edit your DxSqlAg manifest​

Add an NFS volume under spec.statefulSetSpec.podSpec.volumes and mount it into the SQL container under spec.statefulSetSpec.podSpec.mssqlServerContainer.volumeMounts.

Example snippet (merge into your existing DxSqlAg YAML):

note

Use the actual NFS server IP and exports path for your environment.

apiVersion: dh2i.com/v1
kind: DxSqlAg
metadata:
  name: dxsqlag
  namespace: default
spec:
  sqlAgConfiguration:
    synchronousReplicas: 2
    asynchronousReplicas: 0
    configurationOnlyReplicas: 0
    availabilityGroupName: AG1

  statefulSetSpec:
    podSpec:
      volumes:
        # Existing volumes...
        - name: mssql-system
          emptyDir: {}
        # NEW: NFS backup volume
        - name: nfs-backup-volume
          nfs:
            server: <NFS_SERVER_IP>          # example: 10.1.200.52
            path:  <NFS_EXPORT_PATH>         # example: /exports/sqlbackups

      mssqlServerContainer:
        # Existing fields...
        volumeMounts:
          - name: mssql-system
            mountPath: /.system
          # NEW: mount NFS to the SQL Server backup dir
          - name: nfs-backup-volume
            mountPath: /var/opt/mssql/backup

  1. Make sure you replace <NFS_SERVER_IP> with your real NFS server IP (example: 10.1.200.52) and <NFS_EXPORT_PATH> with your actual path.

  2. Apply:

kubectl apply -f DxSqlAg.yaml
note

If the pod cannot mount NFS, init containers will remain in PodInitializing and you will see mount failures in Events:

kubectl describe pod <pod> | sed -n '/Events/,$p'

Generally, deleting the pod so that it can be recreated fixes this issue:

kubectl delete pod <pod-name>

Verify the NFS Backup Mount Inside SQL Server Pods​

  1. Check that the DxSqlAg pods are all running:
kubectl get pods -o wide

Each should show 2/2 Running:

NAME         READY   STATUS    RESTARTS   AGE
dxsqlag-0   2/2     Running   0          10m
dxsqlag-1   2/2     Running   0          10m
dxsqlag-2   2/2     Running   0          10m
  1. Check the mount in each SQL container:
kubectl exec -it dxsqlag-0 -c mssql -- df -h /var/opt/mssql/backup
kubectl exec -it dxsqlag-1 -c mssql -- df -h /var/opt/mssql/backup
kubectl exec -it dxsqlag-2 -c mssql -- df -h /var/opt/mssql/backup

Expected output (example):

Filesystem                       Size  Used Avail Use% Mounted on
10.1.200.52:/exports/sqlbackups   70G  8.3G   62G  12% /var/opt/mssql/backup
  1. Test write access from the pods:
kubectl exec -it dxsqlag-0 -c mssql -- bash -lc "echo from-0 > /var/opt/mssql/backup/0-test.txt"
kubectl exec -it dxsqlag-1 -c mssql -- bash -lc "echo from-1 > /var/opt/mssql/backup/1-test.txt"
kubectl exec -it dxsqlag-2 -c mssql -- bash -lc "echo from-2 > /var/opt/mssql/backup/2-test.txt"

You should see the files in the same directory listing, confirming shared storage.

Perform a SQL backup to NFS​

note

Some SQL Server container images do not include tools, or include them at a different path. For this guide, sqlcmd is located at:

  • /opt/mssql-tools18/bin/sqlcmd

Backup Example​

kubectl exec -it dxsqlag-0 -c mssql -- /opt/mssql-tools18/bin/sqlcmd   -S localhost -U sa -P '<YourSAPassword>' -C   -Q "BACKUP DATABASE [master] TO DISK='/var/opt/mssql/backup/master_test.bak' WITH INIT"
  1. Verify the backup exists from one of the pods:
kubectl exec -it dxsqlag-1 -c mssql -- ls -lh /var/opt/mssql/backup/master_test.bak

Troubleshooting​

Because NFS server configuration, export policy, firewall rules, and service behavior vary by operating system, DH2i recommends consulting your OS vendor’s documentation for distribution-specific troubleshooting guidance.

Use the following vendor-maintained references for troubleshooting and administration:

Typical NFS issues such as export permission problems, firewall blocking, rpcbind/mountd access restrictions, client mount configuration, and service startup behavior should be diagnosed and resolved according to the applicable OS documentation above.

References​