SQL SERVER – Availability Group Missing or Deleted Automatically?

An availability group missing from SSMS does not by itself prove that someone deleted it. In the original 2017 case, my friend John reported a network incident. Afterward, two availability groups were absent from one SQL Server instance, while their cluster roles still appeared in a failed state. The databases on that node showed RESTORING.

John had already tried SQL Server restarts and server reboots without resolving the issue. I asked for the SQL Server error log. If you need its location, see ways to find ERRORLOG.

What the Log Established

Error: 19435, Severity: 16, State: 1.
AlwaysOn: WSFC AG integrity check failed for AG 'PROD_AG'
with error 41041, severity 16, state 0.
The local replica of availability group 'PROD_AG' is being removed.

The longer message said that SQL Server could not validate the availability-group configuration in the Windows Server Failover Clustering store. It also noted that local removal is expected when the group has been removed from another instance. A later line recorded the local replica changing from SECONDARY_NORMAL to NOT_AVAILABLE.

This establishes a local configuration-validation failure and replica-state change. It does not, on its own, identify the original cause or prove that the latest committed data exists on another copy. The earlier conclusion that there was automatically no data loss was too broad.

Check the Instance and Local Metadata

Connect directly to each expected SQL Server instance and confirm that SSMS is using the intended instance and login. Refresh Object Explorer, then compare the results below with the AG dashboard and cluster resources. Run these diagnostic queries with appropriate server visibility. The state DMVs require VIEW SERVER STATE on SQL Server 2019 and earlier, or VIEW SERVER PERFORMANCE STATE on SQL Server 2022 and later. Catalog metadata is also limited by the permissions of the login.

SELECT @@SERVERNAME AS registered_server_name,
       CONVERT(sysname, SERVERPROPERTY('ServerName')) AS current_server_name,
       SERVERPROPERTY('IsHadrEnabled') AS is_hadr_enabled;

SELECT ag.name AS availability_group, ar.replica_server_name,
       rs.is_local, rs.role_desc, rs.operational_state_desc,
       rs.connected_state_desc
FROM sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar ON ar.group_id = ag.group_id
LEFT JOIN sys.dm_hadr_availability_replica_states AS rs
    ON rs.group_id = ar.group_id AND rs.replica_id = ar.replica_id
ORDER BY ag.name, ar.replica_server_name;

SELECT name, state_desc, group_database_id, replica_id
FROM sys.databases
WHERE group_database_id IS NOT NULL
   OR state_desc = N'RESTORING'
ORDER BY name;

On a secondary, the replica-state DMV reports local information; missing state columns for remote replicas do not establish a remote failure. Catalog visibility also depends on permissions and cluster communication. An empty result on one connection is evidence to investigate, not permission to rebuild the whole configuration.

A database in RESTORING is another observation, not a repair instruction. Do not run RESTORE WITH RECOVERY merely to make that label disappear. First establish the database’s intended role, synchronization history and the recovery plan.

Collect the Cluster and SQL Evidence Together

• Preserve SQL Server error logs from every replica around the incident time.
• Collect the Windows System events and WSFC logs, including quorum, resource and network changes.
• Record which instance still has the AG metadata, the current primary if one exists, and the state of every database copy.
• Check recent configuration work, host renames, patches and administrative actions alongside the network incident.
• Confirm backup availability and the business recovery-point requirement before selecting a repair.

Errors 19435 and 41041 are not unique to one cause. For example, Microsoft documents a hostname mismatch scenario on particular SQL Server 2017 and 2019 update levels. That is a separate documented scenario, not evidence that John’s earlier case involved a rename.

Choose Recovery Only After Comparing the Copies

Do not use Failover Cluster Manager to force an AG move or delete cluster resources as an exploratory step. Likewise, dropping and recreating the AG is not the default response to this message. A repair may involve configuration correction or rejoining a replica, but the surviving topology and data state determine the supported procedure.

If the primary is unavailable, planned failover, forced failover and restoring from backups have different prerequisites and data-loss implications. Use the documented recovery procedure for the verified situation and involve the cluster or support team when configuration integrity remains uncertain.

The saved case shows the diagnostic message, but it does not contain a verified end-to-end recovery record. The useful lesson is to correlate the local SQL view with the cluster state and preserve evidence before changing either.

A missing availability group is not proof of a safe rebuild, it is a reason to establish the state of every copy.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.