How to fix Error 3059 on Windows Server 2025 / Windows 11

by

Troubleshooting Guide: Error 3059 – Backup/Restore Not Supported on Database Mirror or Secondary Replica

Why This Error Happens

Error 3059 occurs because SQL Server 2025 blocks direct BACKUP and certain RESTORE commands against databases that are functioning as a mirror or a secondary replica in an Always On Availability Group. This restriction exists because secondary/mirror databases are in a continuous restoring state, synchronized from the principal/primary, and are read-only or inaccessible for standard transaction log backups. Attempting to run these commands on the wrong node—rather than the primary replica—triggers this specific error.

Step-by-Step Resolution Guide

Step 1: Identify the Current Primary Replica

  • Open SQL Server Management Studio (SSMS) and connect to one of the nodes in the Availability Group.
  • Run the following query to check the role of the server:
  SELECT 
      ar.replica_server_name, 
      ars.role_desc 
  FROM sys.dm_hadr_availability_replica_states ars
  JOIN sys.availability_replicas ar 
      ON ars.replica_id = ar.replica_id;
  • Confirm that role_desc shows SECONDARY for the server you were originally targeting.

Step 2: Redirect the Backup Command to the Primary Node

  • Update your backup scripts, SQL Agent Jobs, or third-party backup tools (e.g., Veeam, CommVault) to point to the active Primary Replica hostname/IP instead of the secondary.
  • If using an Availability Group Listener, ensure your connection string includes ApplicationIntent=ReadWrite to force the connection to the writable primary node.

Step 3: Configure Backup Preferences (If Secondary Backups Are Required)

  • If you specifically need to offload backups to a secondary node to save resources on the primary, you must configure the Availability Group’s Backup Preferences.
  • In SSMS, navigate to Availability Group Properties > Backup Preferences.
  • Select Prefer Secondary or Secondary Only, and ensure the specific secondary replica has “Readable Secondary” enabled (not “No”).
  • Note: Even with this preference set, only Full Copy-Only and Log backups are permitted on secondaries; standard differential backups are still restricted.

Step 4: Verify Readable Secondary Configuration

  • Check the readable_secondary setting using:
  SELECT replica_server_name, secondary_role_allow_connections_desc 
  FROM sys.availability_replicas;
  • If this is set to NO, update it via PowerShell or T-SQL to ALL or READ_ONLY to allow the connection necessary for copy-only backups.

Alternative or Verification Steps

  • Verification: Run sys.dm_hadr_database_replica_states to check the is_local and is_primary_replica columns ensuring your backup job targets a node where is_primary_replica = 1 (or a correctly configured secondary if using copy-only backups).
  • Alternative: If the application logic cannot be changed to detect the primary dynamically, use the Listener Name in your connection strings rather than hardcoded server names; this automatically redirects write/backup traffic to the current primary during failovers.