0

To determine when database has been backed up the last time usually is enough to look into backup tables in msdb database.

However, it doesn't work well with Availability Groups - after the failover new active replica doesn't know when the last FULL\DIFF backup was taken because local msdb database doesn't have those records.

It is a bit easier with log backups - DBCC DBINFO (@DBName) WITH TABLERESULTS gives you the last LOG backup data no matter where it was taken.

My question is - is there an easy way to say on the new active replica, right after failover, when the last data backup was taken? There is always an option to query each replicas through OPENROWSET (or anything like this), but this introduces unwanted complexity.

The goal is to make sure that code like this works stable even after the failover:

IF dbo.lastBackupWasTakenMoreThanSevenDaysAgo(@DatabaseName) = 1
   < full backup >
ELSE
   < diff backup >

Probably I'm missing something very simple.

Thanks!

3
  • 3
    There is no out-of-the-box solution for this. There are other posts indicating that some DBAs centralize the backup info as a solution. If you would keep a copy of that data on each node then you could query it instead of the msdb data. dba.stackexchange.com/questions/263972/… Commented May 1, 2020 at 16:06
  • But. You just had a failover. Wouldn't you normally want a new full backup? Commented May 1, 2020 at 20:22
  • 1
    If failover was caused by actual outage - probably yes, it is a good idea to take a new full backup. I'm not sure I want to take the full backup after the failover that was a part of the scheduled maintenance (which are the absolute majority of failovers in our case). Commented May 1, 2020 at 20:31

1 Answer 1

1

The differential_base_time and lsn columns in sys.database_files indicate the point in time and in the log stream when the last non-copyonly backup was taken. So:

select min(differential_base_time) last_full_backup_utc, 
       datediff(second,min(differential_base_time),SYSUTCDATETIME())/( 24*60*60.) days_since_last_full_backup
from sys.database_files
where type_desc = 'ROWS'
and is_read_only = 0

If you have read-only filegroups a backup will not update the differential_base_time, so ignore those.

2
  • 1
    It worked! (by the way, differential_base_time has time in UTC) This time pretty close to what's recorded in msdb.dbo.backupset.backup_start_date for the FULL backup - the difference is ~1 second. Commented May 1, 2020 at 21:29
  • 1
    That's actually helpful in this scenario, as you don't care what the TZ on the other server was. Commented May 1, 2020 at 21:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.