SQL SERVER – Backup Error: 3636 – An Error Occurred While Processing BackupMetadata

Backup error 3636 while processing BackupMetadata needs the surrounding errors and replica state to explain it. In one client availability group, a log backup on the secondary failed after a new log file was added on the primary. The secondary had not yet replayed that change.

What happened in this case

I had helped this client deploy an Always On availability group. Log backups ran on the secondary and had been working. A large business transaction then drove substantial log growth, and the team added another drive and log file on the primary.

The secondary backup started reporting error 3636 for BackupMetadata along with error 3046 about inconsistent metadata. Comparing sys.master_files showed that the added file was not yet present on the secondary. Its redo queue was around 500 GB.

The secondary was still replaying earlier log records. Once redo applied the file-add change and the file metadata agreed, the log backup succeeded. That was the resolution for this specific case, not a repair command for every 3636 error.

Compare the file metadata on both replicas

Run this read-only query separately on the primary and affected secondary, replacing YourDatabase. Record the server role and collection time with each result.

DECLARE @DatabaseName sysname = N'YourDatabase';
SELECT file_id, name, type_desc, state_desc, physical_name
FROM sys.master_files
WHERE database_id = DB_ID(@DatabaseName)
ORDER BY file_id;

Compare logical file IDs, names and types. Physical paths can legitimately differ between replicas, so do not require identical paths. Missing rows can also reflect the wrong database name or limited metadata visibility.

Inspect redo progress

This read-only query shows the local HADR setting and the database replica rows visible to that instance:

SELECT SERVERPROPERTY('IsHadrEnabled') AS IsHadrEnabled,
       SERVERPROPERTY('ProductVersion') AS ProductVersion;
SELECT DB_NAME(database_id) AS database_name,
       is_local,
       is_primary_replica,
       synchronization_state_desc,
       is_suspended,
       suspend_reason_desc,
       redo_queue_size AS redo_queue_kb,
       redo_rate AS redo_kb_per_second,
       last_redone_time
FROM sys.dm_hadr_database_replica_states
WHERE database_id = DB_ID(N'YourDatabase');

Check is_local and is_primary_replica before interpreting a row. On a primary, reported secondary values reflect the latest information received and can lag. The queue size is in KB. Collect more than one sample to see whether replay progresses; a single redo rate is not a reliable completion estimate.

The DMV requires VIEW SERVER STATE on SQL Server 2019 and earlier, or VIEW SERVER PERFORMANCE STATE on SQL Server 2022 and later. A server without HADR enabled cannot demonstrate the original availability-group situation.

Protect the backup chain while investigating

Check the SQL Server build, replica health, suspension reason, storage and corresponding logs. If redo is suspended or not progressing, investigate the cause rather than simply waiting indefinitely.

The accompanying error text mentions CONTINUE_AFTER_ERROR and NO_TRUNCATE for a tail-log operation. Those options are not a routine fix for a secondary-backup metadata problem. Do not add them solely because they appear in the message.

Coordinate any temporary backup-location change with the responsible DBA. Use a suitable healthy replica and a backup operation supported by the exact version and role, preserving the complete restore chain. This diagnosis does not call for a forced failover or data-loss repair.

The queries were checked locally with HADR disabled. They validate syntax and accessible metadata, not the 500 GB redo scenario or a successful secondary log backup. Confirm the actual replica behavior before choosing a recovery action.

BackupMetadata is not a reason to force a repair, it is a prompt to compare the database and replica evidence.

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