SQL restore to Always on Availability groups

[backupquestions]

I've posted something similar before, but it was just databases with replication enabled and not Always on Availability groups.

So, I have a SQL 2016 cluster with no shared storage between them. Instead they use always on groups. This is a form of replication/synchronization between the two servers of the databases.

What I've found so far in testing is the below... (this is with image level agentless backup which is supported according to documentation I've found by googling "veeam always on sql support")

1. In the backups, when I go to restore, it correctly has shown the databases are members of always on groups and it shows which server is the primary and which is secondary. So this is great.

2. When I first just try to restore a database without any manual actions, I get a result of "unable to drop database x because it has replication enabled" logged at the end of the attempt and it leaves the database in unusable state on the sql server until dba takes actions to fix.

3. As a test, we suspended sync for one database and took it out of the availability group. Then, we attempted veeam restore of this database, and it worked fine, and it even added the database back into the availability group that it was originally in to start with and sync resumed. All automatic and spiffy!

So it seems like we are there on the back end, but the beginning end is broken. It should be possible for Veeam to take the database you want to restore, out of the always on group first and then initiate restore I would think? This way it is fully seamless and automatic experience.

If I have to log into my sql servers and manually drop from groups first to restore it is a negative experience.

So I have been answered before on "non availability group setups" that this is a known bug and is fixed in v10 or soon after? Is this true and the same deal? Or will we always be expected to have to drop database from group first before restoring?

[HannesK]

Hello,
I don't have the issue you mention in 2. with my SQL Always ON cluster (SQL 2016 on Server 2019). I tested with restore to same location and to different database name. Just "next, next, finish"

Do you have a case number for that issue? And the link to the thread for non-availability groups databases?

Best regards,
Hannes

[foggy]

Right, it should work seamlessly, the database should be dropped fine on all replicas upon restore. Please contact technical support for a closer look. Thanks!

[backupquestions]

HannesK,

Here is a link to my older thread in the past. Regarding non-availability. foggy listed it as known issue but this is for replication enabled databases. That still the same deal then that that would work in the future? veeam-backup-replication-f2/sql-restore ... 60283.html

Foggy/HannesK,

Thank you. This was a test sql cluster and out of all the databases, the one I tested restore actually did have replication job enabled on it. Tests with it and others work just fine back to the Availability groups. Awesome.

[foggy]

That still the same deal then that that would work in the future?

If it is the same issue I'm thinking about, then it is addressed in v10.