Add Database to Availability Group Failure � This BACKUP or RESTORE Command is Not

Supported on a Database Mirror or Secondary Replica

June 28, 2019
Pinal Dave
SQL
No Comments
I always recommend my client to go with the latest and great version of tools like
SQL Server Management Studio (SSMS). In this blog, we would learn about a situation
where an older version of SSMS was giving an error while adding a new database to
existing availability group � This BACKUP or RESTORE command is not supported on a
database mirror or secondary replica.

SQL SERVER - Add Database to Availability Group Failure - This BACKUP or RESTORE
Command is Not Supported on a Database Mirror or Secondary Replica
availabilitygroup-800x242

THE SITUATION
My client had an existing availability group which was set up and deployed by a
vendor. Now, they wanted to add a new database to an existing availability group.
They were using the wizard to add the database. They selected the option to do a
fresh backup/restore. Due to old SSMS version, automatic seeding option was not
available. Here was the error which they were getting in the UI.

SQL SERVER - Add Database to Availability Group Failure - This BACKUP or RESTORE
Command is Not Supported on a Database Mirror or Secondary Replica restore-err-
seed-01

Here is the text of error message:

Restoring database log resulted in an error.

(Microsoft.SqlServer.Management.HadrTasks)
����������
ADDITIONAL INFORMATION:
Restore failed for Server �SQLSERVER-1�. (Microsoft.SqlServer.SmoExtended)
����������
System.Data.SqlClient.SqlError: This BACKUP or RESTORE command is not supported on
a database mirror or secondary replica. (Microsoft.SqlServer.Smo)

Solarwinds
The surprising part was that even after the error came, the database was added to
the availability group successfully. This means the error was a benign error and
can be ignored but I want to know what error was appearing. To dig further I
generated the script of Always On and executed it manually. It failed with the
exact same error.

WORKAROUND/SOLUTION for RESTORE command

It was clear that the database was getting added successfully due to automatic
seeding. We can see below in ERRORLOG.

Primary Replica:

� Database backed up. Database: OneMoreDatabase, creation date(time):

2019/06/11(13:21:51), pages dumped: 355, first LSN: 38:2800:1, last LSN: 38:2824:1,
number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {�\\sqlserver-
0\Share\OneMoreDatabase.bak�}). This is an informational message only. No user
action is required.
� Database backed up. Database: OneMoreDatabase, creation date(time):
2019/06/11(13:21:51), pages dumped: 522, first LSN: 38:2712:1, last LSN: 38:2824:1,
number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE:
{�{3AFC5950-4E79-4225-B572-0A70AD876E45}�}). This is an informational message only.
No user action is required.
� Log was backed up. Database: OneMoreDatabase, creation date(time):
2019/06/11(13:21:51), first LSN: 38:2712:1, last LSN: 38:2824:1, number of dump
devices: 1, device information: (FILE=1, TYPE=DISK: {�\\sqlserver-
0\Share\OneMoreDatabase_20190626054651.trn�}). This is an informational message
only. No user action is required.

Secondary Replica:

� Database was restored: Database: OneMoreDatabase, creation date(time):

2019/06/11(13:21:51), first LSN: 38:2712:1, last LSN: 38:2824:1, number of dump
devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {�{E9D35CEB-D6FD-
40D6-A73C-06560EFD95D9}�}). Informational message. No user action required.
� Database was restored: Database: OneMoreDatabase, creation date(time):
2019/06/11(13:21:51), first LSN: 38:2800:1, last LSN: 38:2824:1, number of dump
devices: 1, device information: (FILE=1, TYPE=DISK: {�\\sqlserver-
0\Share\OneMoreDatabase.bak�}). Informational message. No user action required.

If we look at the backup and restore commands, there are two backups. Once on
TYPE=DISK and another on TYPE=VIRTUAL_DEVICE. The second backup comes when there is
an automatic seeding happening for the database.

Running script manually fails with below (on secondary). This is the same what we
get from the UI.

Connecting to sqlserver-1�
Msg 3059, Level 16, State 2, Line 29
This BACKUP or RESTORE command is not supported on a database mirror or secondary
replica.
Msg 3013, Level 16, State 1, Line 29
RESTORE LOG is terminating abnormally.
Disconnecting connection from sqlserver-1�
Connecting to sqlserver-1�
Msg 41145, Level 16, State 1, Line 67
Cannot join database �DWConfiguration� to availability group �XAG�. The database
has already joined the availability group. This is an informational message. No
user action is required.
Disconnecting connection from sqlserver-1�

When I compared the script generated from SSMS for an old and new version, I found
the difference which explained the issue clearly. This was the extra command in the
new version of SSMS.

1
2
ALTER AVAILABILITY GROUP [XAG]
MODIFY REPLICA ON N'sqlserver-1' WITH (SEEDING_MODE = MANUAL)
This means that SSMS is smart enough to change the mode to MANUAL when below option
is selected.

SQL SERVER - Add Database to Availability Group Failure - This BACKUP or RESTORE
Command is Not Supported on a Database Mirror or Secondary Replica restore-err-
seed-02

So, to conclude, the seeding was set to AUTOMATIC for the replica. When we were
using an older version of SSMS, it was doing both automatic seeding and
backup/restore. This was causing restore to fail because it was seeded already and
added successfully.
You can use below query to find replica seeding mode.

1
2
3
4
5
6
7
SELECT ag.name
,replica_server_name
,seeding_mode_desc
FROM sys.availability_replicas ar
,sys.availability_groups ag
WHERE ag.group_id = ar.group_id
AND name = 'AGSQLAGDB'
Have you seen such errors of SSMS? Please comment and let me know.